1、测试需求分析
需求到手后首先要进行需求分析,理解需求,会用软件系统,分解功能点,在依照功能点提取测试点(使用不同的测试方法,例如:等价类,边界值,因果图,错误推断法。。。。)
2、测试点提取(xmind)
在需求说明书通过评审后,这时候开发、产品、测试有统一的需求文档,基于需求说明书,测试根据需求说明书中的内容,提取测试点,测点提取的准则一般是:一个测试点对应一条测试用例!以确保需求的覆盖率!一般测试人员根据需求说明书,直接进行编写测试用,这样容易造成需求覆盖的不全面!测试点不仅包括需求说明书中指示出的需求点,还包括一些隐性的需求,确保提取的测试点能尽可能多的覆盖需求!
3、编写测试计划及评审
目的,背景,进度计划,人力资源,软硬件资源,策略(方法,工具,测试类型),风险
4、编写测试用例及评审
测试用例是软件测试最小颗粒单元也是测试的关键点之一。不管是测试的菜鸟还是从事测试多年的老鸟,测试用例测试中必不可以的一环!根据公司业务,每个公司的测试用例都不一样,通用的模板核心参数主要有以下几点:用例ID、用例名称、用例描述、执行步骤、预期结果、实际结果、所属功能模块、用例状态、所属版本号、作者、创建日期。有的公司还有优先级、前置条件等,这些属性根据自己公司业务,自己用于完善。测试用例设计要点就是:简单明了、条理清晰!
(1) 明确测试要点,统一对需求的理解,确保测试的完备性用例设计完成后,不是就要开始进行测试的下一步,而是要经过用例评审。虽然需求说明书已经给定了,但是产品、开发、测试对统一需求点理解上可能存在差异,那么在实现和测试上就会出现不同的结果,这一部分的目的主要有如下几点:
(2) 评审测试用例设计是否充分覆盖功能需求;
(3) 确定测试时间节点。
这个阶段参与人员主要是:产品、开发、测试,在大型公司项目负责人也会参与用例评审。
5、执行测试用例(开发提交测试后)
6、发现缺陷通过禅道提交
主要要素(标题,严重级别,环境,输入数据,操作步骤,实际结果,预期结果,指定修改人,优先级别,附件【图片,小视频】
(1) 缺陷的生命周期流程图:
7、回归测试及bug验证(开发提测新的版本)
回归测试根据时间安排,选着合适的回归策略,如果时间充分,那就执行所有的测试用例,如果时间不充足,选着执行核心的测试用例以及bug修复的测试用例。
验收测试,需要产品或者用户根据需求说明书来检查产品功能实现、页面展示、性能是否与需求说明书要求的一致,如果一致,这说明产品符合需求通过验收。
bug验证通过,关闭;验证不通过,重新打开;
回归测试就是把之前测试的功能再测试一遍(主要以正向用例为主)
8、测试报告编写及评审
目的,背景,分析 用例编写和执行情况(用例总数,执行数量,通过率),缺陷的统计分析(缺陷的严重级别分布,缺陷的状态分布,缺陷的模块分布,缺陷的类型,缺陷的提交人,缺陷的负责人。。。)
测试结束后,需要给出各个阶段的测试产物。如测试需求文档、测试用例、自动化脚本、性能测试脚本、性能测试报告、自动化执行报告、接口脚本及报告等。
下面是软件测试的基本流程图: