测试评审规范
测试评审规范
测试评审规范
一、目的和价值
目的： 测试用例评审流程规范的首要目的是为了有效组织和引导测试用例评审工作，确保测试用例的质量和准确性，从而提高整体软件质量。
价值： 测试用例是软件测试的关键组成部分，通过评审流程的规范制定，旨在确保测试用例经过开发和产品等相关团队的审查后，能够成为可靠的准则和规范。这不仅有助于在测试阶段更好地指导测试活动，也是产品、研发和测试团队达成一致需求认知的重要途径。通过规范的测试用例评审，我们能够降低后续测试工作的错误率，提高测试效率，最终为软件交付提供坚实的基础。
二、评审流程
1）评审前的准备
- 确定需要评审的原因
- 确定进行评审的时间
- 确定参与评审人员
- 明确评审的内容
- 确定评审结束标准
- 提前至少一天将需要将评审的测试用例邮件或是群通知的方式通知评审会议参与的相关人员，并注明评审时间、地点及参与人员等。
- 在通知中需提醒评审会议相关人员至少简过一遍测试用例，并记录相关的疑问，以便在评审会议上提出。
- 会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
2）评审流程
评审会议： 安排测试用例评审会议，明确会议的时间、地点和议程，以有序地进行测试用例的逐条评审。
逐条评审： 在评审过程中逐条评审测试用例，关注测试步骤的清晰度、正确性，以及是否涵盖了所有的测试场景。
问题记录与解决： 在评审过程中发现的问题应及时记录，并通过合适的渠道追踪和解决，以确保问题不会流入到后续的测试阶段或生产环境。
文档更新： 根据评审结果，及时更新测试用例文档，确保其与实际需求和系统功能的一致性。
三、检查清单（测试用例评审准则）
1）测试用例是否按照公司定义的模板进行编写的；
2）测试用例的本身的描述是否清晰，是否存在二义性；
3）测试用例内容是否正确，是否与需求目标相一致；
4）测试用例的期望结果是否确定、唯一的；
5）操作步骤应与描述是否相一致；
6）测试用例是否覆盖了所有的需求；
7）测试设计是否存在冗余性；
8）测试用例是否具有可执行性；
9）是否从用户层面来设计用户使用场景和业务流程的测试用例；
10）场景测试用例是否覆盖最复杂的业务流程；
11）用例设计是否包含了正面、反面的用例；
12）对于由系统自动生成的输出项是否注明了生成规则；
13）测试用例应包含对中间和后台数据的检查；
14）测试用例应有正确的名称和编号；
15）测试用例应标注有执行的优先级；
16）测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等；
17）每个测试用例步骤应<=15 Step；
18）自动化测试脚本必须带有注释（注释应包括：目的、输入、期望结果等）；
19）非功能测试需求或不可测试需求是否在用例中列出并说明？
20）测试用例的结构是否清晰、合理、是否利于高效对需求进行覆盖？
21）测试用例优先级安排是否合理？
22）测试用例的设计思路合理吗？与 PRD 相符号？技术方案里涉及的重要关注点都覆盖到了吗？
23）测试用例是否具有很好的可执行性？例用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
24）是否已经删除了冗余的用例？
25）是否都能包含正常或包含充分的负面（异常）测试用例？充分的定义，如果在这里使用 2&8 法则，那就是 4 倍于正面用例的数量，毕竟一个健状的软件，其中 80%的代码都是在“保护”20%的功能实现。
26）是否从用户层面来设计用户使用场景和使用流程的测试用例？
27）是否简洁、复用性强？例：可将重复度高的步骤或过程抽取来定义为一些可复用标准步骤。
28）测试用例是否覆盖了所以已知的边界值或无效值？
29）测试用例是否覆盖了安全性问题及性能问题？
30）若存在接口变更，那么变更是否考虑了新老接口的兼容性，是否关注到位？
31）是否考虑了上下游服或者其他模块的关联功能测试用例？
32）关注的核心用例是否能够实现自动化，如果能够自动化的生成用例，那么其与评审手动编写的用例验证点是否能 100%吻合？
33）是否所有的接口数据都有对应的测试用例？
34）是否考虑了新数据和老数据的兼容性？
提醒
以上细则，需要根据团队和项目的具体情况选择性的制定规范。
四、合格用例的特点
需求覆盖完全
- 能够根据 PRD（产品需求文档）覆盖所有的内容，结合用户的实际使用场景，根据交互、上下游服务依赖分析出测试的重点和难点，并生成测试用例。
异常覆盖，使考虑相对比较全面
- 第一，除了正向逻辑和 PRD 上列出的逻辑之外，能够根据条件组合出不同的逻辑和测试边界。
- 第二，能够根据研发的技术方案和技术实现逻辑列举出异常的验收场景。
可读性高
- 设计思路清晰，用例一目了然，组织结构合理，执行比较顺畅，连贯性比较好。
易维护性
- 应该以最少的时间完成测试用例的维护。