前言
新手测试评审的总结分析
一、评审的目的
为用例评审提供一个参考标准,保证评审的覆盖率和有效性
- 为了避免三方需求理解不一致
- 保证测试人员的质量标准与项目标准一致
- 为了减少测试人员执行阶段无效工作
- 保证相关人员对即将要上线的需求有了解
二、评审的分类
测试组内部的评审:测试部门成员参与
项目组内部的评审:项目经理、架构设计人员、开发人员和测试人员参与
二、评审的内容
需求评审、需求实现流程图评审、测试大纲评审、测试用例检查
- 需求评审
A 检查讲解的内容无丢失
B 检查需求理解无偏差
C 检查需求讲解思路清晰
D 检查需求讨论会议提出需求建议、需求讨论的问题都有体现,并且记录的详细
E 检查需求讲解时存在问题的记录,跟进结论
- 需求实现流程图评审
A 检查需求以及实现逻辑内容正确
B 检查需求以及实现逻辑内容齐全,补充流程缺失部分
C 检查实现逻辑的深度与仔细程度
例如:软件升级实现逻辑–什么时候获取服务器版本信息?版本信息有什么?
版本信息获取失败的处理?获取的版本信息版本比对策略是什么?比对后的下载逻辑策略是什么?下载的文件保存在哪里?下载过程的失败处理?下载成功后的安装策略是什么?安装失败的处理逻辑是什么?安装成功后的数据加载时机以及加载哪些数据?
- 测试大纲评审
A 检查用例大纲结构、思路清晰 B 检查用例大纲内容齐全–对象齐全\影响因素齐全:
1.需求逻辑功能
2.UI(静态+动态)
3.用户行为(用户常用场景, 常用数据)
4.黑盒用例设计方法
5.平台系统的特点(windows,ios,android,web)
6.开发语言特点
7.发现过的历史bug
8.自身的版本兼容性
9.功能之间相互影响
10.开发实现逻辑和建议 C 检查用例大纲语言描述清晰 D 检查用例去除冗余用例 E 检查用例进行集成,为测试执行的高效做准备
- 测试用例检查
检查每条测试用例都有明确的预期结果
根据正规化用例的各个字段要求对应的细节
总结内容:
用例设计的结构安排是否清晰、合理,是否利于高效对需求进行覆盖。
优先级安排是否合理。
是否覆盖测试需求上的所有功能点
用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确;期待结果是否有明显的验证方法
是否已经删除了冗余的用例
是否包含充分的负面测试用例。充分的定义,如果在这里使用2&8法则,那就是4倍于正面用例的量,毕竟一个健壮的软件,其中80%的代码都是在“保护”20%的功能实现
是否从用户层面来设计用户使用场景和使用流程的测试用例
是否简洁,复用性强。例如,可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤
评审结束要求标准
1)评审过程中收集相关人员的反馈信息(即问题记录清单),并在此基础上进行测试用例更新,直到评审通过;
2)评审结束后,测试负责人出测试用例评审报告给到相关人员;
3)评审结果经项目经理同意确认
测试用例评审检查项:
1)测试用例是否按照公司定义的模板进行编写的;
2)测试用例的本身的描述是否清晰,是否存在二义性;
3)测试用例内容是否正确,是否与需求目标相一致;
4)测试用例的期望结果是否确定、唯一的;
5)操作步骤应与描述是否相一致;
6)测试用例是否覆盖了所有的需求;
7)测试设计是否存在冗余性;
8)测试用例是否具有可执行性;
9)是否从用户层面来设计用户使用场景和业务流程的测试用例; 10)场景测试用例是否覆盖最复杂的业务流程;
11)用例设计是否包含了正面、反面的用例;
12)对于由系统自动生成的输出项是否注明了生成规则;
13)测试用例应包含对中间和后台数据的检查;
14)测试用例应有正确的名称和编号;
15)测试用例应标注有执行的优先级;
16)测试用例包含相关的配置信息:测试环境、数据、前置测试用例、用户授权等;
17)每个测试用例步骤应<=15 Step;
18)自动化测试脚本必须带有注释(注释应包括:目的、输入、期望结果等);
19)非功能测试需求或不可测试需求是否在用例中列出并说明?
参考评审学习资料:
https://www.cnblogs.com/hyzhou/archive/2011/10/27/2226437.html
https://www.cnblogs.com/wxinyu/p/8568931.html
https://recomm.cnblogs.com/blogpost/5666053?page=2