我们来说一下用例评审，首先了解什么情况下会用例评审，之后再具体清楚怎么进行用例的评审。
用例评审通常会先在小组内进行评审，大概就是将写好的用例合起来，看看有没有需要修正的地方，接着会拿到项目经理那里进行评审，接着就是三方会谈了，参与的人员有产品经理、测试人员、开发人员，共同来进行。
接下来就进行详细的了解：
时机：
两个时间点：
第一：是在用例的初步设计完成之后进行评审
第二：在整个详细用例全部完成之后进行二次评审
原因：
软件测试的准则。由于用例开发人员的设计经验和对需求理解的深度各不相同，所以用例的质量难免会有不同程度的差异。
目的：
1、能够使用例的结构更清晰
2、覆盖的用户场景更全面
3、对于测试工程师来说也是一个快速提高用例设计能力的过程
形式：
1、部门评审，测试部门全体人员参与的评审
2、公司评审，这里包括了项目经理、需求分析人员、架构设计人员、开发人员和测试人员。
3、客户评审，包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
评审内容：
（注：最好内化为自己的知识体系，这样你在写用例的时候，就会写出更接近于没有问题的测试用例。）
1、测试用例是否按照公司定义的模板进行编写的
2、测试用例的本身的描述是否清晰，是否存在二义性
3、测试用例内容是否正确，是否与需求目标相一致
4、测试用例的期望结果是否确定、唯一的
5、操作步骤与描述是否相一致
6、测试用例是否覆盖了所有的需求
7、测试设计是否存在冗余性
8、测试用例是否具有可执行性
9、是否从用户层面来设计用户使用场景和业务流程的测试用例
10、场景测试用例是否覆盖了所有的需求
11、用例设计是否包含了正面、反面的用例
12、对于由系统自动生成的输出项是否注明了生成规则
13、测试用例应包含对中间和后台数据的检查
14、测试用例应有正确的名称、编号、执行的优先级
15、测试用例包含相关的配置信息：测试环境、数据、前置测试用例、用户授权等
16、每个测试用例步骤应 <= 15步 Step
17、非功能测试需求或不可测试需求是否在用例中并列说明
分享一个群号给小伙伴：861268173，软件测试进阶之路，群主会为大家整理一些资料放在群文件，某些疑惑的问题，也会尽心解答，希望共同成长以及进步。
我知道很多的小伙伴，都非常急于求成，但事实上，做任何事情一定需要耐心、恒心，也许才会获得想要的结果。我也在慢慢的探索。
