总结：测试用例评审

目的

测试用例评审流程规范主要为开展测试用例评审工作提供指引，规范测试用例评审管理工作。

测试用例评审流程内容

前提：

测试人员编写完一个完整的功能模块的测试用例或已完成所有测试用例的编写；

流程输入：

A.测试用例； B.需求规格说明；

流程输出：

A.问题记录清单； B.测试用例评审报告；

参与评审人员：

项目经理、测试负责人、测试人员、需求分析人员、架构设计人员、开发人员；

评审方式：

1. 召开评审会议。与会者在测试用例编写人员讲解之后给出意见或建议，同时记录下评审会议记录；
2. 通过邮件、及时通讯工具与相关人员沟通。

无论采用哪种方式，都应该在评审之前事先把需要评审的测试用例相关文档以邮件的形式发给参与评审的相关人员，同时在邮件中提醒参与评审的相关人员在评审前查阅一遍评审内容，并记录相关问题，以便在评审会议上提出，以节省沟通成本。

　### 评审用例检查清单：

1. 测试用例是否按照公司定义的模板进行编写的；
2. 测试用例的本身的描述是否清晰，是否存在二义性；
3. 测试用例内容是否正确，是否与需求目标相一致；
4. 测试用例的期望结果是否确定、唯一的；
5. 操作步骤应与描述是否相一致；
6. 测试用例是否覆盖了所有的需求；
7. 测试设计是否存在冗余性；
8. 测试用例是否具有可执行性；
9. 是否从用户层面来设计用户使用场景和业务流程的测试用例；
10. 场景测试用例是否覆盖最复杂的业务流程；
11. 用例设计是否包含了正面、反面的用例；
12. 对于由系统自动生成的输出项是否注明了生成规则；
13. 测试用例应包含对中间和后台数据的检查；
14. 测试用例应有正确的名称和编号；
15. 测试用例应标注有执行的优先级；
16. 测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17. 每个测试用例步骤应<=15 Step；
18. 自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
19. 非功能测试需求或不可测试需求是否在用例中列出并说明？

退出标准：

1. 评审过程中收集相关人员的反馈信息（即问题记录清单），并在此基础上进行测试用例更新，直到评审通过；
2. 评审结束后，测试负责人出测试用例评审报告给到相关人员；
3. 评审结果经项目经理同意确认。

控制机制：

采用评审会议时，主持人应尽量把握会议进度，尽量按时有效的完成评审工作；

附件1：问题记录清单　　　　附件2：测试用例评审报告

转载：https://blog.csdn.net/zhupopo/article/details/53908461