两个时间点：

在设计初步完成之后就可以了

  用例写完了之后，不代表这份用例写的都是正确的，场景覆盖是全的，需要在多方人员进行查漏补缺，所以我的理解是：用例评审是产品、开发、测试一起对写好的用例进行一个review的过程。如果用例都没有评审，直接去执行，可能会存在一些问题。

  如果用例都没有评审，直接去执行，可能会存在一些问题。用例评审参会人员，产品、开发、测试。详细一点的话，就是 制定该需求的产品，实现该产品的前端开发、后端开发，负责该需求用例编写的测试人员，负责该需求用例执行的测试人员。

  用例评审在什么时候进行，开发提测前。一般我们会提前一天通知相关人员，并且预约好我们公司的会议室，看大家时间是否方便。

  用例评审的作用：

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

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

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

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

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

  用例评审前准备

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

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

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

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

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

  用例评审的建议

  1.时长 最好控制在1H，若东西太多，可以分多次review;

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

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

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

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

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

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

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

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

开发有自己的时间计划，测试也是； 经历过的几家公司都是在开发设计、编码阶段做用例评审，就是用例写完后，测试内审结束后，组织产品、开发、业务或者运营

越早越好，临界点再评审肯定有点晚，评审后还需要修改

如果有案例评审，开始执行测试之前一定要评审

进行评审的时机一般会有两个时间点。第一,是在用例的初步设计完成之后进行评审;第二是在整个详细用例全部完成之后进行二次评审。

项目没有完全做完，开发后面接其他项目忙不过来之前，或者完成了测试用例