如何有效的评审功能测试用例？

---

前言

新手测试评审的总结分析

---

一、评审的目的

为用例评审提供一个参考标准，保证评审的覆盖率和有效性

• 为了避免三方需求理解不一致
• 保证测试人员的质量标准与项目标准一致
• 为了减少测试人员执行阶段无效工作
• 保证相关人员对即将要上线的需求有了解

二、评审的分类

测试组内部的评审：测试部门成员参与 
项目组内部的评审：项目经理、架构设计人员、开发人员和测试人员参与

二、评审的内容

需求评审、需求实现流程图评审、测试大纲评审、测试用例检查

1. 需求评审

A 检查讲解的内容无丢失
B 检查需求理解无偏差
C 检查需求讲解思路清晰
D 检查需求讨论会议提出需求建议、需求讨论的问题都有体现，并且记录的详细
E 检查需求讲解时存在问题的记录，跟进结论

2. 需求实现流程图评审

A 检查需求以及实现逻辑内容正确
B 检查需求以及实现逻辑内容齐全,补充流程缺失部分
C 检查实现逻辑的深度与仔细程度
例如：软件升级实现逻辑–什么时候获取服务器版本信息？版本信息有什么？
版本信息获取失败的处理？获取的版本信息版本比对策略是什么？比对后的下载逻辑策略是什么？下载的文件保存在哪里？下载过程的失败处理？下载成功后的安装策略是什么？安装失败的处理逻辑是什么？安装成功后的数据加载时机以及加载哪些数据？

3. 测试大纲评审

A 检查用例大纲结构、思路清晰 B 检查用例大纲内容齐全–对象齐全\影响因素齐全：
1.需求逻辑功能
2.UI（静态+动态）
3.用户行为（用户常用场景， 常用数据）
4.黑盒用例设计方法
5.平台系统的特点（windows，ios，android，web）
6.开发语言特点
7.发现过的历史bug
8.自身的版本兼容性
9.功能之间相互影响
10.开发实现逻辑和建议 C 检查用例大纲语言描述清晰 D 检查用例去除冗余用例 E 检查用例进行集成，为测试执行的高效做准备

5. 测试用例检查

检查每条测试用例都有明确的预期结果
根据正规化用例的各个字段要求对应的细节

总结内容：

用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 
 优先级安排是否合理。  
 是否覆盖测试需求上的所有功能点 
 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法 
 是否已经删除了冗余的用例
 是否包含充分的负面测试用例。充分的定义，如果在这里使用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