第二十三章 为什么测试计划和测试用例也需要评审？

第二十三章 为什么测试计划和测试用例也需要评审？

我把大家这几天陆陆续续完成的测试用例和我自己完成的测试计划都通过邮件发给了老大，并告诉他我已经仔仔细细地看过好几遍了，没什么问题，请他也抽空审阅一下，看看有没有什么我没有发现的问题。

没过多久，我就收到老大的回复，让我计划组织一下测试设计评审，我不太明白这么做的原因，于是，就跑去问他：“为什么测试计划和测试用例也需要组织评审？产品需求需要评审，是因为产品经理需要让开发和测试都能明白且理解这一期的需求要做什么。但测试计划和测试用例都是测试人员自己去执行的，还有评审的必要吗？”

老大让我别着急，坐下来听他说，“你刚才说到需求评审的目的是让开发和测试都能明白且理解这一期的需求要做什么，这只是需求评审的目的之一，还有一个目的其实你们都做到了，但可能并未真正意识到，那就是从开发和测试的视角去审视产品的需求是否有问题，帮助产品经理去完善需求，你说是不是？”

我想了想，“是的，的确是有这样一个目的在里面。”

老大问我，“那你现在是不是能理解为什么测试设计的产物也需要评审了？”

我说，“有些理解了，但还不是特别的清楚，你再跟我具体说说吧。”

老大说，“好吧，不管是测试计划，还是测试用例，都是我们测试人员基于对这一期的产品需求范围和内容而设计的，换句话说，就是基于一个还没有做出来的东西在做测试设计，而是否有遗漏，或者是否有冗余都不能确定。所以我们需要产品经理、开发，甚至于最终的使用者来参加评审，就是希望从他们不同角色的视角来帮我们查漏补缺。

• 产品经理：可以从他的需求背景、需求目的、商业价值，包括业务，来检查是否缺少了某种场景的测试，比如在某个时间段会存在大量用户的并发操作。
• 开发：可以从具体的代码设计和实现角度，可以发现有些测试用例是冗余的，或者说有些代码逻辑分支并未被测试用例所覆盖到。
• 最终的使用者：可以从易用性和操作习惯角度来完善测试场景的设计，也可以帮助我们减少一些实际不存在的操作场景。”

我说，“这下都明白了，那我就参照需求评审的模式，来组织测试设计评审吧。

第一步：选定需要参加设计评审的各个角色的人员，将测试计划和测试用例提前发送给他们；
第二步：在评审会上，我会先介绍整体背景和测试计划，再由相应负责人自上而下地介绍用例场景，不需要细到最后一个层级的用例；
第三步：评审会后，将评审会上记录的问题逐一修正补充后，再次发给参加评审的人员确认；

这么做可以吧？”

“可以，都交给你了。”老大说到。