3.2.10　正式审查

正式审查（inspection）是IBM在20世纪70年代开发出来的。在超过35年中，正式审查通过度量被证明在所有的缺陷清除形式中拥有最高的缺陷清除效率。而由于审查的参与者会自然地避免犯在审查中发现的同一类错误，正式审查也是最好的缺陷预防方法之一。

考虑到关于审查技术成功的35年的经验数据，一个重要的问题是为什么直到2011年，审查还只有这么低的使用率。理想的情况是，正式审查应该在至关重要的软件项目中和其他软件项目的所有关键部分中被100%使用。但是即使是在2011年，审查的使用依然是很稀少的。

这个问题的答案打击了关于软件工程界如何学习新技能的社会评论。正式审查不属于任何一家公司，而且该方法是在公共域中的。因此，除了几位教别人审查的顾问外没有人能通过这门技术来挣钱。

尽管根据要求，有很多可用的关于审查的书籍和文章，但是并没有活跃的营销来推动审查。为了发现审查的价值，有必要找出关于有效质量方法的信息，而且只有非常少的人花时间来做这件事。

相反，大多数方法被采用是因为有由厂商提供较好的资金支持的营销方案，或者是社会学的原因。当诸如敏捷、RUP、TSP等方法的使用达到足够数量时（通常是由于营销），其他的公司将在不怎么进行分析的情况下采用同样的方法，因为这些方法已经变得流行起来。

审查还没有达到这个足够数量以变得自我维持或者快速扩展，主要是由于缺乏营销资金。因为没有人拥有审查，所以就没有人能从中赚大钱。相比之下，静态分析这个较新的方法拥有的用户比审查要多很多，因为很多工具厂商，如CAST、Coverity、Instantiations、KLOCwork等，都拥有有效的营销方案。

尽管正式的设计和编码审查出现至今已经超过了35年，但是就缺陷清除效率而言它们仍然是较好的方法论。（Michael Fagan，曾就职于IBM金斯顿，首次发布了审查方法。）更进一步，审查与其他缺陷清除方法（如测试）有相互促进的关系，而且作为缺陷预防方法也是很成功的。

Tom Gilb和他的同事们关于软件审查的最近工作继续支持了早期的发现，即人类的大脑仍然是一个选择的工具，该工具用来找到和消除起源于需求、设计和其他非代码可交付成果的复杂问题。实际上，在找到源代码中更深入的问题方面，正式的代码审查在缺陷清除效率上地位也是高于测试的。

在本书一位作者的客户中，600家企业中大约100家正在多多少少按照正式审查设计和计划的那样使用该方法。而另外125家正在使用半正式的审查、设计评审、结构化的走查，或者审查过程的一些本地化变种。

在该作者的客户中，对正式审查最有效的使用发生在一些生产系统和嵌入式软件的大型公司，例如计算机厂商、电信厂商、航天厂商、医疗设备厂商等。这些公司已经了解到，如果软件要控制复杂的实体设备，那么它就需要最高的质量等级，而只有审查可以达到所需的质量。

大多数形式的测试发现错误或bug的效率低于30%。正式设计审查和正式代码审查的度量的缺陷清除效率有时高于85%，即接近大多数形式的测试的3倍。

Tom Gilb（一位审查方面的著名作家）报告称一些记录下来的审查有效性高达90%。其他的一些作家（如Lew Priven和Roger Steward）报告称审查缺陷清除率最高能达到95%。就我们所能确定的，这个效率水平可能是一个通过测试大数据量Beta测试（涉及10000同时进行的Beta测试点的测试）的可能异常从未接近过的“世界记录”。

正式审查、静态分析、专员正式测试以及积极主动的质量保证组的组合是最常与项目联系在一起的方法，能达到超过99%的累积缺陷清除效率。

正式审查是手工的活动，这个活动中有4～6个同事一起使用具体的协议一页一页地检查需求和设计规格说明书。代码审查是同样的，不过是一行一行地检查清单或者是屏幕。为了能将该活动称为“审查”，需要满足一些标准，包括但不限于以下这些：

1）需要指定一个主持人来维持会议的进行；

2）要有一个记录员来记录；

3）每个会议前需要适当的准备时间；

4）发现的缺陷记录必须被保存下来；

5）缺陷数据不应该作为评估或者处罚的目的而使用。

审查最初的概念是以有现场参与人员的实际会议为基础的。高效的支持远程审查的Web在线交流和协作工具的出现，为位于不同地点的团队节省了出差的成本。

任何软件可交付成果都可以适用于正式审查，下面这些可交付成果现在已经开发出了足够的经验数据来表明审查过程通常是有益的：

●架构审查

●需求审查

●项目计划审查

●软件成本估算审查

●软件市场计划审查

●软件管理计划审查

●软件安全计划审查

●设计审查

●数据库设计审查

●代码审查

●测试计划审查

●测试用例审查

●用户文档审查

●违反合同的诉讼中的原告控诉

●违反合同的诉讼中的被告答复

软件制品的正式审查的缺陷清除效率的范围从小于50%到大于85%，平均清除效率水平约为75%。这是所有已知的错误消除形式中缺陷清除效率最高的。静态分析工具拥有相同的缺陷清除效率，但是它范围比较窄，只能处理编码相关的缺陷。

多亏人类大脑的灵活性及其处理归纳逻辑和演绎逻辑的能力，审查是最通用的缺陷清除形式，而且本质上可以应用到任何软件制品上。确实，审查已经被递归地应用到它们自己身上，以调整审查过程和消除瓶颈及障碍。

大多数软件开发组织并没有真正地研究或者收集有效工具和技术方面的数据。他们很大程度上根据工具和方法论厂商销售人员的说服能力来进行技术决策和采用。

销售人员将工具或方法说成“银弹”（silver bullet）是很容易的，说它能立即为开发带来神奇的结果，而且只需要很少的或者不需要培训、准备或额外的工作量。由于审查不是由工具厂商销售，而且也不需要几年的预先培训，它们不是“迷人的”技术。因此很多软件组织甚至听都没听说过审查，更不用说审查的多用性和有效性了。

最有可能使用审查的公司是这样一些公司，他们由于历史的或者业务的原因，有一定的研究能力，寻求“最佳实践”并且尝试采用它们。

在美国所有最优秀的软件质量公司甚至是行业都喜欢使用测试前的审查，这一点是很能说明问题的。例如，正式审查在计算机厂商、电信厂商、航天厂商、国防厂商、医疗设备厂商、系统软件和操作系统开发者中是很常见的。他们都需要高质量的软件来推广其主要产品的市场，由于审查在缺陷清除方法中的有效性是名列榜首的，因而审查应该是首选的方法。

说明正式审查有效性的最有效方式之一是生成一些图表，图表能将软件缺陷被发现的点和软件开发中缺陷起源的点连接起来。

无论何时，只要在连接发现和起源的线中有锐角，就证明软件质量控制有严重的问题，因为犯错误和找到错误之间可能相隔很多个月。

缺陷清除的目的是使连接缺陷起源点和发现点的角度接近90°。尽管90°角是不可能的，正式审查至少可以将该角度从30°转为大于60°。

如图3-2所示，没有使用正式审查的软件项目在测试周期中进入了“混乱区”。这是因为深深埋在过程中的需求和规格说明的问题突然出现，导致大范围和昂贵的修复和返工。

注意一下在图3-3中连接缺陷发现点和缺陷起源点的线形成了钝角。另外，注意一下起源于一个阶段内的缺陷往往在该阶段内被清除。审查的一个价值就是一个阶段内的大多数缺陷不会传递到下游的阶段。