一.评审的价值
测试用例是软件测试的核心，是测试和研发验收活动的准则，但它并不是编写出来就立即变成准则，而是要经过开发和产品等相关团队评审后才能成为准则规范。也可以认为，测试用例的评审是产品、研发和测试统一需求认知的最后一道关。
二.评审前的准备
1.确定需要评审的原因
2.确定进行评审的时间
3.确定参与评审人员
4.明确评审的内容
5.确定评审结束标准
6.提前至少一天将需要将评审的测试用例邮件或是群通知的方式通知评审会议参与的相关人员，并注明评审时间、地点及参与人员等。
7.在通知中需提醒评审会议相关人员至少简过一遍测试用例，并记录相关的疑问，以便在评审会议上提出。
8.会议主持者(一般为用例编写人员)应在会议前整理相关疑问，以便在会议上提出。
三.合格用例的特点
1.需求覆盖完全
能够根据PRD（产品需求文档）覆盖所有的内容，结合用户的实际使用场景，根据交到、上下游服务依赖分析出测试的重点和难点，并生成测试用例。
2.异常覆盖，使考虑相对比较全面
第一，除了正向逻辑和PRD上列出的逻辑之外，能够根据条件组合出不同的逻辑和测试边界。
第二，能够根据研发的技术方案和技术实现逻辑列举出异常的验收场景。
3.可读性高
设计思路清晰，用例一目了然，组织结构合理，执行比较顺畅，连贯性比较好。
4.易维护性
应该以最少的时间完成测试用例的维护。
四.测试用例评审准则
序号 |
准则 |
是/否 |
序号 |
准则 |
是/否 |
1 |
测试用例的结构是否清晰、合理、是否利于高效对需求进行覆盖？ |
|
2 |
测试用例优先级安排是否合理？ |
|
3 |
测试用例的设计思路合理吗？与PRD相符号？技术方案里涉及的重要关注点都覆盖到了吗？ |
|
4 |
测试用例是否具有很好的可执行性？例用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。 |
|
5 |
是否已经删除了冗余的用例？ |
|
6 |
是否都能包含正常或包含充分的负面（异常）测试用例？充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健状的软件，其中80%的代码都是在“保护”20%的功能实现。 |
|
7 |
是否从用户层面来设计用户使用场景和使用流程的测试用例？ |
|
8 |
是否简洁、复用性强？例：可将重复度高的步骤或过程抽取来定义为一些可复用标准步骤。 |
|
9 |
测试用例是否覆盖了所以已知的边界值或无效值？ |
|
10 |
测试用例是否覆盖了安全性问题及性能问题？ |
|
11 |
若存在接口变更，那么变更是否考虑了新老接口的兼容性，是否关注到位？ |
|
12 |
是否考虑了上下游服或者其他模块的关联功能测试用例？ |
|
13 |
关注的核心用例是否能够实现自动化，如果能够自动化的生成用例，那么其与评审手动编写的用例验证点是否能100%吻合？ |
|
14 |
是否所有的接口数据都有对应的测试用例？ |
|
15 |
是否考虑了新数据和老数据的兼容性？ |
五.评审结束后工作
1.评审完，会议记录者(主持者/用例编写人)统计会议中的修改点（意见/建议/遗漏点）。
2.用例编写人根据评审会议记录点，整理修改测试用例。修改完成后并以邮件或是群通知的方式通知评审会议参与的相关人员知悉。
