摘要：
关于用例评审，你是否了解用例评审前的准备工作有哪些 ？
需要几轮评审 ？
需要哪些人参加 ？
评审时长 ？
评审形式 ？
评审结束后，还需要做哪些 ？
-
什么是用例评审？
用例评审主要是产品、开发和测试人员，针对测试用例能否用于项目的测试而做的工作。
-
用例评审的目的
为了减少测试人员执行阶段做无效工作（执行无效case，提交无效问题） 为了避免三方需求理解不一致； 为了每个测试人员的质量标准与项目要求标准达成一致。
一、评审前需要做哪些准备工作
1、需求评审结束后，就可以着手把需求拆分为功能点 。
工具：建议用XMind，需包含预期结果和测试结果，Android和iOS测试结果可用标签区分标注。
2、把功能点再分解为具体的测试用例 。（待定）
这里需在思维导图上补全预期结果和实际测试结果，便于测试结果跟进。
3、用例写完后，自己先做好自检，自检中，针对有疑问的点罗列出来，可事先跟产品开发讨论，确定结果后完善用例，仍有疑问的可先做标记，评审会上抛出一起讨论。
4、和评审人员（开发和产品）确定好具体的评审时间并提前把测试用例以邮件的形式发给参会人员查看。
二、用例评审参加人员
主要是产品、开发（客户端和后端）、测试、项目负责人。
注：以上人员为必须参加人员，其他和项目质量、进度有关人员，根据实际情况可邀请参加。
三、用例评审时间
对于敏捷开发项目，建议控制在半小时以内。
如果你认为需求复杂，功能点太多，半小时讲不完，那么建议你对功能点划分优先级，优先评审优先级高的用例，再针对疑问多的用例评审，最后对于功能简单的用例可简单带过。时刻记住我们用例的评审目标，不能流于形式。
四、用例评审的形式
1、评审要按用例的优先级，功能的复杂程度进行；先对功能复杂，优先级高，疑问多的用例进行评审，再评审功能简单，优先级低的功能点。
2、评审过程中尽量做到，思路清晰，用最简洁的语言阐述每一个功能点；
3、超过5分钟无法确定结果的问题留作会后讨论跟进。对于评审过程中，一时半会没有结论的问题，可以记录下来，作为会后讨论跟进的重点。
五、评审结束后需要做些什么事？
评审结束后，第一时间整理测试用例，把修正的内容重新整理补全。修改的功能点用黄色标记。
会上未确定的内容，会后继续跟进，直到确定结果。如果有遗漏的功能点，新增后用绿色标记。
没有任何有疑问的地方了，再做个简单的用例评审会议总结（如修正了哪些功能点（黄色），补全了哪些（绿色）？哪些模块功能有变动（紫色）？哪些功能推迟到下一期做（红色）？等）
这个总结是给自己整个用例评审工作总结，同时需同步给项目组其他成员，做好信息共享。