惊奇队长那篇文章，我们从语义的角度，谈了测试只能“保障”软件的质量，而非“保证”质量。今天，我们从缺陷引入的角度，谈谈软件的质量还能如何得到保障。

一、缺陷的引入

缺陷的引入，从项目的早期就开始了。需求、设计、编码的每个阶段，都会产生正确与错误两种不同的工作结果。排列组合一下，从需求阶段到编码阶段，便会产生如下图所示的8种不同的编码结果。并且，越是早期引入的缺陷，其负面影响力就越是深远。

测试之前，软件已经形成，其质量已是固然存在了。测试通过寻找缺陷的方式，能保障的，是对正确需求做了正确设计，从而产生的编码的质量。从图上来说，只有针对蓝色部分的测试，才是有效的测试。而除此之外的所有测试，可以很尖锐的说，都是无效的测试。这样找出来的缺陷，也都是没有意义的缺陷。

测试能发挥作用的部分，是在“有意义的缺陷”中，减少“未发现”的缺陷比例。因此，这也从缺陷引入的角度，说明了测试只能“有限支撑和支持”质量，即“保障”而非“保证”。

那么，想要提高软件质量，最直观的是扩大有效测试，减少无效测试。这需要尽早发现与纠正需求、设计与编码阶段的错误，降低早期错误的后期影响。

二、如何提高质量

“保证”的角度：

从知识、技能与过程能力的角度，提高需求、设计、编码人员的胜任力。使得他们正确工作产出的比例不断扩大。

“保障”的角度：

为了尽早发现错误，在测试之前，最有效的方式是评审。

胜任力的提升，对于质量改善的保证作用是很直接的。但这个过程，漫长而持续。所以能够短期见效的办法，就是在软件开发的各个阶段加入评审机制。

三、同行评审的价值

用于软件项目的评审种类有很多。以1028-2008 - IEEE Standard for Software Reviews and Audits为例，就涉及管理评审、技术评审、审查、走查和审计五种类型。

CMMI建立之初，结合了IEEE标准，在模型中，直接用同行评审泛指软件项目中的众多评审类型。也是因为如此，现在在软件领域，一说到评审就是指同行评审。

同行评审已成为软件行业公认的最佳评审实践。它能在早期发现错误，帮助需求、设计、编码阶段获得更多正确的工作产出，从而减少无意义的缺陷，为后期有效的测试提供更大的可能性。

也是因为如此，我们说同行评审是一个非常重要和必要的管理机制。它和测试作为软件质量保障的两大重要环节，一前一后，为软件的质量保驾护航。

数据显示：

测试阶段识别和修复软件问题的成本，平均要高出前期同行评审的4倍。

而一套成熟且有效的同行评审机制，能够使测试阶段出现的错误减少80%，即使算上同行评审本身的成本，那么总体验证的成本，也会下降45%~60%。

对于“同行评审性价比低”的认知，在这里就不攻自破了。

还有一个有趣的地方。