摘自http://www.51testing.com/html/47/n-3725947.html
一、需要评审的原因
测试用例是软件测试的准则，但它并不是编制完成后就直接成为准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。
二、用例评审内容
1.用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。
2.优先极安排是否合理。
3.是否覆盖测试需求上的所有功能点。
4. 用例是否具有很好可执行性。例如用例的前提条件、执行步骤、输入数据和期待结果是否清晰、正确；期待结果是否有明显的验证方法。
5. 是否已经删除了冗余的用例。
6.是否包含充分的负面测试用例。充分的定义，如果在这里使用2&8法则，那就是4倍于正面用例的数量，毕竟一个健壮的软件，其中80%的代码都是在“保护”20%的功能实现。
7. 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8. 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。
三、用例评审过程
1.提前发出用例初稿，并确定参与用例评审人员，目前我们是只包含测试工程师和测试经理参与；
2.先做简单的业务流程介绍，这个是在评审开始尤为重要的一个过程，刚开始评审，参与人员会比较蒙圈，其他测测试工程师可能都不知道测试的思路，或者半途加入的新
的测试，对需求和业务都不够熟悉，如何让评审快速进入状态，先做简单的需求业务流程介绍，说明白打算如何去做评审。
3.按模块进行，有些模块，业务性不是特别强的，可以简单说下有哪些模块，每个模块评审的时候，按测试项分类，UI、核心功能、基础功能、边界测试、兼容测试和异常
测试等，预期结果类似的，主要讲清楚用例主题，让参与人员知道每条用例是做什么的。
4.按业务流程进行，业务流程性较强的需求，需要有业务场景和逻辑，按一定的顺序来；
5.按测试数据进行，涉及到计算逻辑、收益、报表等需求的，用例编写时会先规划好测试数据，尽管测试数据也是按不同的业务场景来设计的，但直接用测试数据来评审你
的测试点，会更清晰，跟上你思路的开发和产品会对应上自己的产品设计和代码设计去评审你的测试点是否不合理或覆盖率不全的地方，从而有效的评审测试用例。
四、用例评审需要避免
1.测试点含糊用语，每个用例评审都应该确定最终版，稍有矛盾或疑惑的需求点，都应该确认下来，不能含糊不清。
2.杂乱无章的评审，有顺序有逻辑的进行评审是很重要的一点；
目前我们是测试组内部的评审，我们着重于：
（1）测试用例本身的描述是否清晰，是否存在二义性；
（2）是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；
（3）是否针对需求变更进行跟着，覆盖了所有的软件需求；
（4）是否尽可能多的覆盖了异常流程和异常测试点。
