最近的用例评审让我感受颇深，以下是我对于测试用例评审的一些感受，发出来供大家讨论学习。

听听大家对测试用例评审的吐槽？

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

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

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

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

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

这里从参与用例评审几个角色来（测试、开发、产品经理、项目经理）分析下进行用例评审的目的以及意义。

测试：

由于不同测试同学对于需求的理解和用例设计都不同，为了提升用例的完整性、合理性、高效性，可以通过评审的方式，收敛不同人以及不同专业的意见，丰富测试用例。测试是无穷尽的，没有人能保证自己的设计用例覆盖完全。

开发：

测试和开发对于需求理解未达成一致，通过评审与开发对需求进行double check，保证在测试前对需求理解的一致性，以免执行测试过程中产生争议和扯皮。

暴漏出开发在实现过程中代码逻辑考虑不充分的地方，提前预警，避免逻辑处理考虑不充分导致的缺陷。

开发可以从实现层面评审用例，补充测试用例中，由于测试人员不了解实现过程导致的测试用例缺失的情况。

产品经理：

经常在测试用例设计的阶段，有些细节是无法从需求文档上得知的，需要频繁来和产品经理进行沟通；有些没有沟通到就存在理解不一致或者考虑不充分的地方。产品经理参与用例评审，他们能帮助你找出更多的问题，同时在评审的过程中，你也能帮助产品经理发现一些他在产品设计过程中考虑不充分的地方。好的测试用例会比需求文档要更具体。

项目经理：

通过用例评审不但可以评审测试用例是否足够覆盖所有需求逻辑，还可以通过评审的的手段来评估测试的工作量。如果100个用例可以用2个人1天进行，那么可以根据测试用例的数量可以安排测试的时间。当然不同的用例执行的时间可能不同，但是用例的多少确实某种程度上可以衡量人力消耗的成本。

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

1、进行评审的时机

首先，我们要说用例设计的时间，一定要在需求评审后就需要进行初步的用例设计，无论用例设计时经过多少深思熟虑，过一两天都会忘掉一部分当时的思路，所以先做好整理和记录。在参与开发的技术评审后，根据开发对需求的实现方式，进行修正和补充。

用例评审最好的时间是在开发中期阶段：

如果开发前期阶段发起用例评审，可能开发的技术评审还没开始，测试也没有足够的时间去整理测试设计的思路，导致用例质量不高。如果开发完毕阶段发起用例评审，在用例评审过程中暴漏的问题很可能是产品经理和开发考虑不充分或者理解不一致造成的，问题暴漏较晚，会导致返工或者版本延期。

2、评审的流程

测试人员确定评审日期和参与评审人员

评审前2天，测试用例发给所有评审人员

评审人员记录测试用例问题

评审会议，测试用例编写人员讲解用例，参与人员提出评审

会议结束，修改用例，并邮件输出

3、评审的内容

1、描述是否清晰，是否存在二义性

2、内容是否完整,是否清楚包含输入条件和预期输出结果并无争议点

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

4、是否哪些需求不可测：无法准备环境、可测试性达不到等等原因

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

4、最后啰嗦几句

在用例评审过程中往往出现一个现象，参与评审用例的评审人员参与度不高，用例评审的效果较差。

通常，在用例评审中，测试人员不是先阐述自己的用例的设计思路，而是直接就说具体执行的案例。通常一个输入条件，不同的场景、不同的操作步骤，可能生成很多用例case;如果一条一条的评审确实很枯燥；而且很多用例case都是正常逻辑的，评审的意义不到。

当测试问：“还有什么需要补充的吗？”，估计开发也看得晕菜啦。如果测试人员能调整下，评审的时候先阐述设计的思路，可以通过流程图、用例图、时序图、状态图等辅助手段来帮助清晰用例设计的思路以及明确测试要点；开发在评审的过程中也容易参与进来，加强互动性；然后在评审用例case，并以异常case为主，正常逻辑的用例case尽量一语带过,提高用例评审的效率，相信这样评审人员参与度会提高。