1- 前言
有一天，你坐在工位上悄悄瞄着手机，看着隔壁村小花给你发来的信息。突然肩膀被人拍了一下，你赶紧藏起手机，抬头看到了你们测试主管深情的眼神，你知道，他有事儿找你了。不错，组长告诉你，他最近要请个假，让你帮忙组织下个版本新增功能的用例评审会议。于是，你在稀里糊涂中接下了这口锅。
2- 为何要做评审
遇事儿不要慌，逮着还要装。我们首先来看看为什么测试工作中，我们要进行需求评审呢？进行试用例评审工作对测试人员的测试技术，测试效率和业务知识的提高都有很好的作用，并且可以更快的了解需求与设计，用集体的智慧尽早发现潜在的问题和纠正缺陷。那么如何进行测试用例评审呢？
3- 组织会议
首先我们看评审的内容，一般我们常参与的评审包括需求报告、可行性报告、立项报告和解决方案。项目管理计划、质量管理计划、配置管理计划、测试计划和风险计划。业务、系统和软件。概念、架构、概要和详细设计。代码走查、单元、功能和系统测试用例。验收报告和总结报告。比如针对本次的用例评审会议，准备好本次需要评审的用例文档及相关资料。
内容确定好了，再确定会议参与人员，会议参与的一般有项目经理，产品经理，开发，测试人员。会议议题和人员确定好后，记得提前发会议邀约，和各方参与人员确定会议时间并达成一致，然后发会议相关文档，让各方人员提前了解会议内容以便更有效率的进行会议。
会议开始后，首先可以简单的做一个业务流程或者计划的介绍，以便会议更快的进入状态。
4- 会议内容
评审的内容有以下几个方面：
1) 用例设计的结构是否清晰、合理及对需求的有效覆盖。
2) 用例优先极是否合适。
3) 用例是否覆盖测试需求的范围。
4) 用例是否具有良好可执行性。如用例的前置条件、执行步骤、数据输入和预期结果是否合理，输出结果是否有有效的验证。
5) 删除冗余的用例。
6) 用例是否包含充分的异常，正反及边界值测试用例。
7) 是否从用户层面来设计用户使用场景和使用流程的测试用例。
8) 是否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。与会者在之后给出意见和建议，同时进行详细的评审会议记录。
5- 会议结束
为了节约时间成本，第一次评审尽量对用例设计全面考虑，提前发现其中的不足之处。但是第一次评审难免会有遗漏的地方。在评审时尽快的修复，不能快速修复的，记录下来，在会议结束后进行修改。如果改动不是很多的，可以发出邮件，标明修改部分，再最后确认最终版。如果需要进行二次评审，那么重新开始邀约会议做二次评审。
6- 注意事项
评审会议中，一定注意如下问题：
准备不充分，导致会议时间不足，资料不充分，人员不齐等情况。
会议状态不好，会议人员的技能或者对评审的必要性认识不足。
评审范围盲目扩大，合理安排评审的优先级和时间。
