在做测试用例评审的时候，常常都能听得到各位对测试用例评审的吐槽：

“测试用例设计是测试的事情，为什么评审要我们参加?"

“测试用例已经很多了，不知道需要评审什么，我能提供什么?"

“用例评审太枯燥了，200个用例case用一条条评吗?"

“这个是别人的开发的功能，跟我没关系。”

相信以上几句话是评审时常听到的话，那么为什么要进行测试用例评审?

测试用例评审的目的有以下几个方面：

(1)提高测试覆盖率 

通过对测试用例评审，完善测试的覆盖率。因为在评审过程中，不同评审专家看待问题的角度不完全一致，所以可以更充分地考虑测试的方法，扩充测试用例的全面性，这样可以更好地确保基本功能和核心功能的测试覆盖率，进而提高软件质量。

(2)确保需求的可追溯性，复审需求 

通过测试用例的评审，可以确定每个需求是否都有测试用例与之对应，只有每个需求都是相应的测试用例与之对应才能保证测试的全面性，同时也相当于对需求进行了一次复审，通过评审测试用例可以反过来验证需求设计是否合理、是否存在遗漏等情况。

(3)开发工程师可带入新的测试角度 

由于开发工程师对业务的处理流程很清楚，这样在评审测试用例时，可以对设置的参数和流程提出新的测试用例，进而从逻辑角度来改善测试用例覆盖的情况。

(4)预防缺陷，改善开发质量

在对测试用例的评审过程中，可以开拓开发工程师对代码逻辑的思维，弥补以前设计过程中存在的缺陷，将潜在的缺陷挖掘出来，这样可以进一步预防缺陷的发生，进而改善软件质量。

在评审测试用例时主要关注规范性规则、内容符合性、质量目标和其他方面。

通过用例评审不但可以评审测试用例是否足够覆盖所有需求逻辑，还可以通过评审的的手段来评估测试的工作量。

如果100个用例可以用2个人1天进行，那么可以根据测试用例的数量可以安排测试的时间。当然不同的用例执行的时间可能不同，但是用例的多少确实某种程度上可以衡量人力消耗的成本。

所以项目经理在这个评审的过程中，需要评审测试用例的覆盖度以及冗余性。

1、进行评审的时机 

首先，我们要说用例设计的时间，一定要在需求评审后就需要进行初步的用例设计， 无论用例设计时经过多少深思熟虑，过一-两天都会忘掉一部分当时的思路 ,所以先做好整理和记录。

在参与开发的技术评审后，根据开发对需求的实现方式，进行修正和补充。用例评审最好的时间是在开发中期阶段:

如果开发前期阶段发起用例评审，可能开发的技术评审还没开始，测试也没有足够的时间去整理测试设计的思路，导致用例质量不高。

如果开发完毕阶段发起用例评审，在用例评审过程中暴露的问题很可能是产品经理和开发考虑不充分或者理解不一样导致的，会导致返工或者版本延期。

2、评审的流程

在评审前2日，测试用例发给所有评审人员，评审会议结束后，修改用例，邮件输出。

3、评审内容

1、描述是否清晰

2、内容是否完整

3、是否覆盖了所有场景，逻辑分支，限制条件等

4、是否哪些需求不可测试

5、是否考虑到测试用例的执行效率