测试---测试的流程

测试开始之前必须要先进性测试需求分析,测试策略的定制,测试计划的制定,测试的风险分析,测试环境的搭建,测试的执行,测试测结果分析,测试提交报告的提交

为什么要进行需求测试?

  • 需求,是软件设计与测试的来源,但是需求除了终端用户的功能需求外,还有设计性需求、可靠性需求、可测试性需求、性能需求、安全性需求等。而且测试需求的识别是后续的测试工作的基础,也是起点。
  • 总结的所有需求最后都需转化为测试点。之后分析这些测试点,并以此为根据来制定测试策略,合理选择各种测试技术。比如是否需要自动化测试?是否需要性能测试?回归测试的范围是什么?是否需要专项测试?黑盒测试能否满足,要不要白盒测试或者灰盒测试?
  • 50%以上的错误来源于需求的错误,所以尽早的发现需求错误,就会尽早的解需求问题,防止编写出来的代码不符合需求。
  • 需求一旦确定,后期进行修改会给我们带来很大的成本。 项目组成员要积极参与需求评审,在评审会议上发现更多的需求缺陷。
  • 测试需求主要来源于业务需求。我们在拿到需求后,要能识别测试需求,接着是分析此测试需求,最后确定并提取出测试对象。
1.提取需求,分析测试点
分析需求的具体方法
  1. 快速理解需求的捷径:需求串讲
    解决的问题:防止开发和测试等人员对需求理解不一致
    串讲方法:产品经理会把需求进行讲解,让测试以及开发人员进行理解,一周之后让负责该模块的人进行需求的讲解,如果理解不一致,会对其进行纠正。保证需求达成一致。

  2. 需求验证(在需求编写好才进行)
    需求测试:在编写测试用例的时间进行测试时进行,和在需求分析的时候进行
    目标:要保证各种需求文档的正确性,必要性,完整性,一致性。
    原因:需求规格说明书是测试和开发的工作依据。

3.从设计需求中提取测试需求
软件需求是软件测试需求的主要来源,但不是全部来源,软件设计需求、软件概要设计、详细设计也都是测试需求的分析对象,是对测试需求的一种有力的补充。

总之,一定要尽量保证需求都被覆盖到。

2.需求分析注意事项:
  • 测试应该尽早的介入,可以尽早的发现错误。
  • 不断变化的需求需要及时的收集和整理 。防止测试和开发的需求不一致。
  • 没有需求文档时,需要测试人员不断的收集原始的客户需求。要以客户额需求为准。
  • 应有质疑、坚持精神,当需求不明确时,我们可以将需求追溯到原始的用户需求,以客户的需求为准。

思考案例:
一个全新上线的项目需要做哪些测试?

  • 全测,根据需求里面的测试点以及相关的测试类型进行测试。
    一个增加了新功能的app需要做哪些测试?
  • 新功能,和及其相关的业务都得测试(回归测试)
    一个只修改了页面广告的app需要做哪些测试?
  • 只需要对该广告页面进行测试。

测试策略的制定

在分析了需求之后,我们要确认测试业务涉及的测试类别。比如,功能测试 性能测试 安全性测试 兼容性测试 文档测试 安装卸载测试 其他专项测试

根据测试的需要,选择测试技术,

1.需不需要白盒测试?
2.自动化测试采用哪种工具?是针对接口测试还是UI测试?
3.性能测试采用哪种工具?jmeter还是loadrunner?
4.兼容性测试如何做?手工测试还是使用平台测试?

测试计划的制定

测试方案主要包括以下内容:
1.测试范围:由需求分析得到的
2.测试策略:包括针对不同部分的测试方法、测试用例,测试工具
3.测试控制:包括测试流程,测试执行,缺陷跟踪
4.其他:环境、版本管理等
5.测试风险

测试的风险分析

风险:是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。
风险来源:主要来源于需求、技术、成本和进度。人员风险,
人员风险:人员在请假,离职的情况下也能完成项目。计划变动,人员变化
技术风险:技术的不稳定,不成熟。框架设计不合理(无法扩容),代码质量不好
进度风险:未在规定的时间内能完成项目
成本风险:在预算的范围内完成项目
需求风险:需求定义不准确,增加额外的需求,客户在需求中参与度不够导致需求的错误
客户风险:客户对产品不满意

测试执行流程的设计

  1. 根据项目特性制定适合项目的测试执行流程。(瀑布模型,螺旋模型,渐进模型)
  2. 测试方案与用例的设计,是属于纯测试技术上的设计,但对于整个项目的测试过程,光有技术还不够,需要配合合适的测试流程,策划什么时候做什么事,达到什么要求。好的策划可以对项目的测试起到事半功倍的作用。
需求测试

基于需求的测试方法是基本的测试方法,而需求的质量直接影响到后续的开发和测试工作。
需求审核
需求测试
测试设计中进行需求测试
需求测试要素:正确性,必要性,完整性,一致性
需求测试应该尽早开始

内部发布版本测试(冒烟测试)(对主干进行测试)

冒烟测试:只有基本功能都通过测试之后才进行下一步测试
版本测试中信息传递:修改内容,风险分析,配置管理

系统测试(所有的都测试,所有压力都执行一遍)

根据测试用例一条一条的执行
缺陷管理

回归测试(对修改的地方进行测试)

确认回归内容:
确认回归的方式:手工、自动化
用例的回归:
bug的回归:先回归bug,,在进行系统的bug测试

回归测试是自动化测试最好的用处

交叉测试:多个测试人员交换测试内容,时间久了就会疲劳。这样做就会缓解测试疲劳。
测试的枯燥性、重复性,引起的惰性
不同的思维模式

探索性测试
也叫自由测试,可以发现意外的bug

测试的最终流程:

  • 需求分析(需求串讲、验证、从设计需求中提取)
  • 测试计划(测试方案、测试策略)
  • 测试用例编写(需求测试)
  • 测试执行(冒烟测试、系统测试、回归测试,交叉测试、自由测试)
  • 测试报告(缺陷分析、测试结论)

总结:
1.分析需求的范围,目的,背景,业务逻辑

2.测试计划:对需求测试的方位指定测试计划,还要编写测试计划和测试策略

3.测试用例的编写:根据测试的时间点介入测试用例的编写,然后对测试用例进行评审,保证测试用例的正确性。

4.测试执行:发开人员提交了测试的包,测试人员提交了测试的包,先进行冒烟测试保证基本概念通过才进行之后的测试,如果冒烟测试不通过就把项目打回给开发对项目进行修改。通过后尽早后边的测试,发现bug提交到缺陷管理平台,然后对bug进行追踪。如果需要可以进行回归测试。

5.编写测试报告:根据测试结果,分析是否达到了通过的标准,测试的计的结果通过不通过,缺陷的分析,分析来源以及解决方法

  • 1
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值