所有的软件测试用例需要评审

　　原因一：设计完成的测试用例要分配给每个人来设计具体数据，并实现自动测试。设计用例和实现用例、执行用例并非一人完成。设计用例的人并不知道用例在具体执行的时候是否有问题，或者哪些步骤不能实现自动测试。再者“测试是无穷尽的”，谁又能保证自己设计的用例能覆盖完全？

(b)R4xyn^'k/g0　　原因二：测试人员总是抱怨测试出来Bug后与开发扯皮太多，主要的原因之一是测试人员和开发人员对于被测试功能的理解未达成一致。因此用例需要提交给开发人员check，并在测试开始之前对于测试目标的功能需求理解达成一致。用例一般比需求文档更加具体，能更好的体现具体测试思路。如果在测试开始之前就提前和开发达成一致，那么在你发现争议的bug的时候，就不用费劲解释了，可以直接告诉他“用例评审的时候已经确认是这样了。”

Ke'V0z*D+[o0　　原因三：让需求人员参与评审，她们能帮助你找出更多的问题。经常在测试的时候，有些细节是无法送需求文档上得知的，需要频繁来和需求人员沟通，问东问西，如果他们在忙，也许会产生这样的心理“怎么连这个也不知道？”我们测试人员多委屈，吃苦不讨好。所以在评审的时候让需求人员明亮的眼睛多帮我们找出问题，解决疑问。51Testing软件测试网-K:fPd|;Q\7i;{

　　原因四：设计完成用例至少要让Leader评审下，让她理解你的思路，如果有问题也及早提出。不然当你测试的模块出现问题的时候，Leader绝不会说都怪她当时没review你的用例，责任还是在你身上。51Testing软件测试网g ^9|W[7d4}u:Sf

.Y,]
PH$cbY0　　原因五：现在有很多人是项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户前自己team先评审下最好，确保提交给客户高质量的成功。

　　原因六：如果严格按照用例数量来计算工作量，真正测试A模块需要200个用例，一周的时间，可是你却由于某些误差设计出100个case，那么评估出来3天的工作量，那么你就等着加班吐血吧。