测试用例评审的必要性

结论先行： 非常有必要

先说下测试用例没经过评审，测试阶段遇到过的坑吧：

第一个坑：项目周期比较短，开发测试时间都很紧张，导致测试用例写完，就赶着测试，测试在测了一半的情况下，在执行案例的时候，发现某个功能没实现，去问开发，开发才发现该功能漏掉了。#需求遗漏

第二个坑：在测试阶段，发现好几个功能被砍掉，需求变更未及时同步到测试同学，导致在测试阶段测试同学问了一圈，发现功能被砍了，前期的准备工作白做了 #需求范围变更，未及时同步的相关干系人

坑多了之后，就吸取经验，积极地寻找应对方案。那就是积极地找相关干系人去评审用例，确认范围、确认需求。

测试用例的评审时间：测试同学编写完用例后，组内进行互相review后，确认无疑问后，约着相关方-前后端开发、产品，由测试同学主导，逐一讲解编写好的测试用例。讲解的过程中关注 相关方提出的问题，及时做好记录及确认工作。三方对有疑问的地方进行确认，并在会后及时的更新或补充测试用例。

测试用例评审的时间节点：测试用例评审的时间节点，一般放在提测前，开发联调阶段，抽出半小时或1小时。

测试用例评审的有哪些人参加：测试用例评审，测试同学组织发起，前后端相关开发、产品，有必要的话一定要拉上技术经理，能及时对一些实现方案进行评估，并对实现方案进行确认。

测试用例评审的核心就是确认三方达成一致，并对需求的范围再次确认，确保无遗漏、确保理解一致、确保用例的完整性。

核心重点还是测试案例的编写，测试用例的编写除了显性需求【需求文档上明确要求实现的功能】外，还要覆盖一些隐性需求，如：异常场景、核心字段的边界值、跨平台、热门机型的兼容性、现有功能的扩展性，可复用性等等，多思考，多总结。

原文：软件测试面试题38-测试用例评审的必要性 - 知乎