越早越好，最好是完成了测试用例初稿甚至草稿的时候就有一次正式或非正式的评审。当然，如果重要的评审会议还是要用例的正式版。
理由一：无论用例设计时经过多少深思熟虑，过一两天都会忘掉一部分当时的思路。那么这时候评审自己讲解都费劲，别人听得更费劲。严重影响效率。
理由二：避免全盘否定，如果一开始的思路就是错的，那么等你辛辛苦苦设计完了，参加评审，这个时候发现从一开始就是错误的。需要推到重来，或者结构要重新布局设计，那么就晕了。所有，在最初完成的版本，哪怕是半成品时，就可以在小范围内评审，降低修改的时间成本。
理由三：为后面的工作留出时间，用例评审——>更新——>review——>构造数据、执行测试等。不要以为自己设计的用例问题很少。抛开漏测的内容，首先对于某一模块如何设计合理最精简用例，一千个人就有一千个想法。那么你很难说服参加评审的每一个人按照你已经设计的思路。因此，有时需要综合大家的思路做出整合修改。这样才能让大家都认同这个设计思路，并积极高效参与进来。
用例评审要尽早，测试过程同样要尽早参与到项目中来。
相关链接：
