前言
软件评审，IEEE定义为‘一种对软件元素所做的正式的、同行间的评审活动，其目的在于验证软件元素满足其规格说明，并能符合标准的要求’。CMMI中要求按照已文档化的规程在所选择的项目里程碑处（阶段成果物）进行正式评审，通过此活动评价软件项目的完成情况和结果。只有前一阶段的输出物通过验证评审无误后，才能开展后续活动。阶段评审活动可根据实际软件生产活动的需求定期或临时发起。阶段评审通常从项目的人力资源、物力资源、资金状况、风险、技术、规模、进度等因素评审项目的状态并确定软件生产活动是否可以进入下一阶段。在一般的公司中，最重要的是软件需求评审会议，根据需求规格说明书，开发需要了解和评估是否在技术上实现同时进行进一步的沟通具体细节，测试人员需要了解业务，以便尽早进入业务中，可以根据的工作经验和开发了解开发的思路以及其他细节，在这个沟通中非常重要，可以发现开发没有考虑的因素在里面。
除此之外还有一个是测试人员的用例评审，因为大一点的公司开发人员会拿测试人员的用例先进行自测，然后再交给测试人员进行测试，测试人员对用例评审主要加深业务的了解，同时可以知道测试用例的覆盖度等。
一、评审前需要做哪些准备工作
1、需求评审结束后，就可以着手把需求拆分为功能点 。
工具：建议用XMind，需包含预期结果和测试结果，Android和iOS测试结果可用标签区分标注。 优点：用画思维导图的方式，逻辑清楚，便于评审人员（产品和开发人员）快速查看，评审效率高。这里需要说明的是，很多测试者喜欢用Excel设计用例，我也不例外，但是根据一段时间的试验，和开发产品沟通后，大家都觉得用XMind写思维导图的方式更好，看起来更便捷。所以具体用什么工具方法，大家可依个人爱好而定，不过目标是一样的，让用例评审高效快捷的开展，并产生价值。
2、把功能点再分解为具体的测试用例 。
这里需在思维导图上补全预期结果和实际测试结果，便于测试结果跟进。
3、用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。
4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例发给参会人员查看。
二、用例评审参加人员
主要是产品、开发（客户端和后端）、测试、项目负责人、运营。注：以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加。
三、用例评审时间
对于敏捷开发项目，建议控制在半小时以内。如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。
四、用例评审的形式
1、对照测试用例，从上而下，从左到右，逐条念。
这是目前很多公司的做法，如果你也这么做过，相信你并不一定喜欢这种方式，因为它费时，不分主次，参会人员的热情与注意力逐渐降低，整个用例评审效率低，作为主持人也讲的口干舌燥，事倍功半。
2、先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。这种做法，有很多优点，评审刚开始的一段时间，大家注意力集中，参与激情高，这段时间讨论有难度有疑问的问题，效率高。最重要的事最先做。另外，整个评审会主次分明，有高潮有缓点，可以更高效的达到我们评审的目的。
