缺陷分析之缺陷特性

在分析缺陷过程中，发现集体缺陷会呈现一些特性，常见的缺陷特性包括：缺陷雪崩效应、缺陷成本放大效应、缺陷集群效应和缺陷的收敛性。

9.4.1 缺陷雪崩效应
在登山时，决不能顺着山边扔石子儿。一是有击中别人的危险，一枚从数千英尺落下的小石头，破坏力相当惊人；二是有可能引发雪崩，一枚不起眼的小石子儿，顶多只能撞动几块差不多大小的石头；但只要有足够数量的石头翻滚起来，用不了多久，大块大块的岩石也会松动下滑。于是乎，这一颗小小的石子儿，就能引发一场雪崩。这个道理不言自明，好比就是水滴石穿、蝴蝶效应，说的都是一个小因素的变化，却往往有着无比强大的力量，以至于最后改变整体结构、产生意想不到的结果。现在，把这个原理适用于商业和技术领域，它同样能得到类似的效果—商业和技术本身具有一定的结构和体系，当人们适当地拆散其结构，并予以重新组合，便能释放出犹如雪崩般巨大的能量。雪崩把旧有的产业体系打得粉碎，甚至，有时候干脆让整个产业消失。在雪崩的巨大压力下，商业与技术之间固有的联系被彻底中断，不得不接受新的改造和整合，其最终将引爆一系列创新的革命，这就是“雪崩效应”。

在项目研发过程中，软件缺陷也会引起“雪崩效应”，即当系统在运行过程中时，由于某个小的缺陷导致整个系统瘫痪不能运行。

在今年，美国在佛州卡纳维拉尔角空军基地发射一枚猎鹰9号火箭，当火箭升空2分半钟后突然爆炸解体，这起事故的详细内容如下：

当地时间2015年6月28日，美国佛州卡纳维拉尔角空军基地，美国太空探索技术公司SpaceX发射一枚猎鹰9号火箭执行国际空间站货运补给任务，火箭升空2分半钟后突然爆炸解体，携带约2500公斤补给的货舱也被炸毁。

SpaceX公司经过详细的分析和调查，确认本次事故的主要原因是由一个零部件的质量缺陷所造成的。这个零部件使得液氧罐的一个支柱出现了问题，在火箭发射过程中液氧罐的一个支柱断裂，该支架的强度仅为正常强度的五分之一，导致火箭爆炸。

这起事故是一个典型的质量缺陷引起的，这也是我们所说的缺陷的雪崩效应，一个看似很小的缺陷，导致整个系统出现事故，最后火箭爆炸。

9.4.2 缺陷成本放大效应
缺陷成本放大效应是指缺陷修复成本会出现放大的现象，也就是缺陷修复的成本不是一成不变的，随着产品所处阶段不同缺陷修复成本也不一样，并且随着产品越是接近推向市场或者已经进入市场，那么缺陷修复的成本会越来越高，这就是缺陷修复成本的放大效应。

关于缺陷修复成本的放大效应在缺陷修复成本中会详细介绍。

9.4.3 缺陷集群效应
Pareto原则，是20世纪初意大利统计学家、经济学家维弗雷多·帕雷托提出的，他指出：在任何特定群体中，重要的因数通常只占少数，而不重要的因数则占多数，因此只要控制具有重要性的少数因数即可以控制全局。这个原理经过多年的演化，已变成当今管理学界所熟知的二八法则，即80%的公司利润来自20%的重要客户，其余的20%的利润则来自80%的普通客户。

这类集群现象在我们的测试过程中的，对所有的缺陷所分布的规则进行分析时发现其也存在这种现象。80%的缺陷主要集中在20%的模块中，也就是说缺陷其实并不是平均分布，其也呈现集群分布方式。

依据缺陷集群现象，我们可以对测试过程进行以下一些方面的改进：

Ø 测试时应该将主要精力放在核心的20%的功能模块中；

Ø 通常一个模块发现很多缺陷，那么通常这个模块中可能发现更多的缺陷。

注：所以在测试前对以前研发的类似项目进行缺陷分布的分析是有必要的，可以按功能模块的方式对缺陷进行详细的分析，这样可以得出哪些功能模块曾经出现缺陷集群现象，这为后期项目测试策略的制定有着积极的作用。

9.4.4 缺陷的收敛性
缺陷的收敛性是指在系统测试过程中，每个Build版本所发现的缺陷数是逐渐减少的，呈逐步收敛的现象，最后趋向于零值。缺陷收敛性如图7-4所示。需要注意的是虽然缺陷是具有收敛性的，但是并不代表测试过程中下一个Build版本所发现的缺陷数一定比上一个Build版本所发现的缺陷数少。在图9-5中，T2版本所发现的缺陷就比T1版本所发现的缺陷多，这种现象一般是由以下几个原因引起的：

Ø 需求变更：需求出现修改或增加的情况时，可以导致当前Build版本所发现的缺陷数增多。

Ø 修改上一版本的缺陷时引入了一些新的缺陷。

一般情况下，这种情况只会在测试的前期出现，如果在测试后期出现这种情况（一般情况下后期缺陷数只会出现小幅度的反弹，并且缺陷的数量不多，一般是在5个以内），说明我们制定的测试策略存在很大的问题。

关于缺陷收敛性的曲线图中有两个特征：

（1）Bug收敛点。

Bug收敛点是指发现的缺陷开始逐渐减少的一个转折点，如图9-5所示，在T3版测试时Bug数量开始出现收敛现象，T3版即为收敛点。

（2）零Bug反弹。

零Bug反弹是指在某一个Build测试版本过程中发现零个Bug，零Bug反弹一般出现在测试的后期，后期主要是验证缺陷修改的情况，如图7-4所示，在T5时出现零Bug反弹现象，即T5版本只发现零个Bug，但在T6、T7和T8版又发现一些Bug，此时就出现明显的零Bug反弹现象。为什么在后期又可能发现极少一些Bug呢？工作中有可能出现这种情况，T5主要是对修改的问题进行回归测试，但开发工程师并没有一次性将所有的遗留问题都修改成功，不得不提交T6版的测试。但T5回归测试修改的问题时，并未带来新的Bug，而在T6时遗留问题又引入了新的Bug，这样就容易出现零Bug反弹现象。