前言

不知道大家在测试流程中把 “用例评审”放在了什么样的“地位”。在我看来，用例评审是测试流程中不可或缺的一环。于是打算把 我司的用例评审写下来，我们的用例评审是怎么做的，也希望汲取一些其他公司优秀的经验，相互学习下~

用例评审是什么

自我理解：用例写完了之后，不代表这份用例写的都是正确的，场景覆盖是全的，需要在多方人员进行查漏补缺，所以我的理解是：用例评审是产品、开发、测试一起对写好的用例进行一个review的过程。

如果用例都没有评审，直接去执行，可能会存在一些问题。

用例评审参会人员

产品、开发、测试。

详细一点的话，就是 制定该需求的产品，实现该产品的前端开发、后端开发，负责该需求用例编写的测试人员，负责该需求用例执行的测试人员。

用例评审在什么时候进行

开发提测前。一般我们会提前一天通知相关人员，并且预约好我们公司的会议室，看大家时间是否方便。

用例评审的作用

一个开发、测试、产品碰撞自己理解需求是否正确的过程；

于开发来说：需查阅用例，是否有自己未考虑到的场景，自己未注意到的需求，或者发现自己对需求理解歧义的地方。

与测试而言：也是发现自己用例中是否存在场景欠缺，需求遗漏的过程

产品也是在其中查看测试的测试范围、测试场景、测试重点是否存在偏差与遗漏…

用例评审的作用最大化，就是在开发提测前评审。如若开发提测了再进行评审，用处大减！

用例评审前准备

1.首先我会在用例评审前先把用例给测试小组评审一遍，看看有没有什么问题

2.在用例评审前，会先把相关用例、需求页面、开发设计页面、原型图打开

3.用例较多时，用例评审前会标注好 前端用例、后端用例，方便在用例评审的时候，分开去review，前后端分开，省时

4.在用例评审前，将自己写好的用例发给相关人员，提前查阅

5.评审前五分钟，提前去会议室做好review的准备

用例评审的建议

1.时长 最好控制在1H

若东西太多，可以分多次review

2.设计时，表达要准确（尽量采用开发/标准的表述）

3.可视化结合：针对页面时，还是需先打开 对应的UI页面/原型/设计图

4.陈述时，要有主题和层级，若主题/层次 切换，要有对应的过渡~

5.对有歧义的问题，要提醒对应的开发（最好是在评审前找对应的开发/产品确认下）

6.评审过程中，参与人员会存在 视觉和听觉疲劳，主讲人要 抓住重点和重要人员

7.评审过程中的问题，要及时做好标记

8.用例评审后，需对用例评审中的问题，跟进/补充用例/告知大家已完善

9.用例修改后，需对用例进行管理