第10讲：缺陷发现的重要方法 — 评审（Review）

同学们已经了解了尽早发现缺陷的意义，那我们通过什么方法来发现缺陷呢。我想大部分同学都会说“测试”。其实只对了一部分，的确测试作为缺陷发现非常重要的一个手段，但不是全部，确切的说应该只是占了一小部分。因为还有一个非常重量级的选手 – 评审（Review）。

测试作为软件开发中必不可少的阶段，重要性不言而喻，而评审可以说无处不在，渗透到了我们软件开发的各个环节。可以说：只要是成果物我们都可以对它进行评审，从而发现并消除缺陷，提高成果物的质量。比如：需求文档，设计文档，代码，测试用例等等，甚至是测试计划，风险管理计划等计划书。测试会在后面的章节专门介绍。

记得大虾的导师曾经说过：做得好的项目，往往都是review做得好的项目。这里的“好的项目”指的是质量好的项目。可见review在软件质量中的作用。那么我们该怎样进行评审呢。

会议评审 OR 单人评审

首先一起来了解下评审的形式。大虾把评审分为两种形式：会议评审（多人一般都采用会议形式），单人评审。在选择评审的形式时，大虾会综合考虑成本，成果物影响大小及范围，以及所处阶段的不同时期等情况。

从成本角度，会议评审参加人数多，成本高。打个比方，有5个人参加评审会，1个小时的会议时长，等于总共消耗了团队5个人时数。因此，可以看出会议评审的成本远高于单人评审。相比单人评审，会议评审还有一个缺点就是沟通效率较低，会更加放大成本。试想一下一群人在那讨论，一人一句就要花费更多的时间，还经常有人跑题太远，把大家带偏，驴都拉不回来。因此，会议效率非常重要，应该事先将材料发送给相关人员，最好大家带着问题来参会。

从成果物影响大小及范围角度，需求文档能否反映用户的真实需求，将直接影响软件的质量，另外，需求文档也是后续设计，开发，测试的基础，因此需求文档影响非常大是不言而喻的；概要设计文档涉及模块间的交互，通常涉及多个人，甚至多个团队，影响范围广，需要一起评审发现问题；详细设计文档涉及具体模块的实现，影响范围相对可控，并且通常由一个人来负责。因此，需求文档，概要设计文档通常采用会议评审，而详细文档可以采用单人评审。

从所处阶段的不同时期角度，代码评审初期，大虾倾向于会议评审，让所有开发人员参与，中后期更倾向于单人评审。因为项目初期，开发人员对代码规约还不够熟悉，代码风格也存在较大的差异，如果不加以规范将影响软件质量以及今后的维护。此外，代码规约大都从组织或者外部渠道获取，并通过“剪刀手”裁剪而来，还没有经过项目实际检验。评审会议上很可能会对某个规范进行激烈的讨论，找出更适合项目的规范。然而到了项目中后期，开发人员已经适应了代码规范，代码与规范存在的差异很小，可以使用单人评审，提高效率。

以上讨论了评审的形式，接下来我们讨论对成果物进行全评审，还是抽检。

全评审 OR 抽检

全评审成本较高，往往我们对某些成果物采用抽检的方式。抽检不仅能提高被抽检成果物的质量，对未被抽检的成果物也能间接提高质量。怎么说呢，试想一下，如果自己的代码可能被抽到，在评审会上向大家展示并进行说明，有点廉耻之心的人都会按照代码规约尽全力写好代码。是全评审，还是抽检，大虾通常综合考虑以下两点：1. 成果物的影响大小及范围；2. 担当者是否靠谱。

从成果物影响大小及范围角度，大虾通常只考虑对详细设计文档，源代码，单元测试用例进行抽检，如果时间压力不大，最好仅对源代码进行抽检。

从担当者是否靠谱的角度，通常我们发现一个规律：靠谱的人提交的成果物质量明显高于其他人。那么我们怎么才是知道谁靠谱，谁不靠谱呢。其实项目刚开始我们也无法知道谁靠谱，谁不靠谱。先从全评审开始，如果一个人能持续产出高质量的成果物，那么信任感就会增加，就会逐步减少对他成果物的评审，直至不评审。反之，如果一个人经常被评审出很多缺陷，那么就要加强对他成果物的评审。信任的建立过程非常缓慢，崩塌却很快。大虾希望同学们能用心对待自己的每一篇文档，每一行代码，每一条注释，做个靠谱的人。

上面我们讨论了评审形式，以及评审成果物范围的选择。对于评审人员的选择我们就不详细谈了。比如：测试用例评审会，一般都会有产品经理，核心开发人员或者开发全员参加。只要综合考虑成本选择必要的人员参加即可。

评审的标准 – Checklist

接着，我们一起讨论下评审的标准。同学们是否有过这样的经历，当你把单元测试用例发给Leader评审后，他指出了一些问题，当你改完这些问题，他再次评审后，他又指出了新的一些问题，再次修改后，又来了其他的新问题。这种情况是不是很让人绝望，不仅内心备受打击，而且来来回回浪费了很多时间。这种情况就是没有确定评审标准带来的后果。如果使用会议形式，不好的效果还会被放大。

那么如何让大家用统一的标准进行评审呢。答案就是之前曾提到过的工具Checklist。比如：Checklist中列明：是否覆盖所有分支；是否覆盖边界值；是否考虑null等等。大家参照Checklist就可以以相同的标准一条一条的确认了。因此，评审的时候一定别忘了好搭档Checklist。Checklist工具非常强大，功能也不限于此，将在后面章节专门介绍。

其他

最后，我们一起讨论下内部评审，从团队的角度划分，可以分为内部评审和外部评审。举个例子，产品经理肯定不希望在PRD评审会上被指出一堆问题，尤其是一些简单的问题。比如：文档模版的一些必填项忘记填写，字体大小不统一等等。因此，将文档提交外部评审前，最好能进行下内部评审。大虾建议内部评审除了评审逻辑外，更应当重视格式规范的评审。要是外部评审出一堆简单的问题，肯定会质疑咱们的专业性，这也是大家最不想看到的，那么就请记得把这些规范都整理到内部评审的Checklist吧。