全国咨询热线：136-9172-9932
在分析缺陷过程中，发现集体缺陷会呈现一些特性，常见的缺陷特性包括：缺陷雪崩效应、缺 陷成本放大效应、缺陷集群效应和缺陷的收敛性。
缺陷雪崩效应 在登山时，决不能顺着山边扔石子儿。一是有击中别人的危险，一枚从数千英尺落下的小石头， 破坏力相当惊人；二是有可能引发雪崩，一枚不起眼的小石子，顶多只能撞动几块差不多大小的石 头，但只要有足够数量的石头翻滚起来，用不了多久，大块大块的岩石也会松动下滑。于是这一颗 小小的石子就能引发一场雪崩。这个道理不言自明，就好比是水滴石穿、蝴蝶效应，说的都是一个 小因素的变化，却往往有着无比强大的力量，以致于最后改变整体结构、产生意想不到的结果。现 在，把这个原理用于商业和技术领域，它同样能得到类似的效果——商业和技术本身具有一定的结 构和体系，当人们适当地拆散其结构，并予以重新组合，便能释放出犹如雪崩般巨大的能量。雪崩 把旧有的产业体系打得粉碎，甚至有时干脆让整个产业消失。在雪崩的巨大压力下，商业与技术之 间固有的联系被彻底中断，不得不接受新的改造和整合，其最终将引爆一系列创新的革命，这就是 “雪崩效应”。 在项目研发过程中，软件缺陷也会引起“雪崩效应”，即当系统在运行过程中时，由于某个小 的缺陷导致整个系统瘫痪而不能运行。 在今年，美国在佛州卡纳维拉尔角空军基地发射一枚猎鹰 9 号火箭，当火箭升空 2 分半钟后突 然爆炸解体，这起事故的详细内容如下： 当地时间 2015 年 6 月 28 日，美国佛州卡纳维拉尔角空军基地，美国太空探索技术公司 SpaceX 发射一枚猎鹰 9 号火箭执行国际空间站货运补给任务，火箭升空 2 分半钟后突然爆炸解体，携带约 2500 公斤补给的货舱也被炸毁。 SpaceX 公司经过详细的分析和调查，确认本次事故是由一个零部件的质量缺陷所造成的。这 个零部件使得液氧罐的一个支柱出现了问题，在火箭发射过程中液氧罐的一个支柱断裂，该支架的 强度仅为正常强度的五分之一，导致火箭爆炸。 这起事故显然是由质量缺陷引起的，也就是我们所说的缺陷的雪崩效应，一个看似很小的缺陷 导致整个系统出现事故，最后火箭爆炸。
缺陷成本放大效应 缺陷成本放大效应是指缺陷修复成本会出现放大的现象，也就是缺陷修复的成本不是一成不变 的，随着产品所处阶段不同，缺陷修复成本也不一样，并且产品越是接近推向市场或者已经进入市 场，缺陷修复的成本就越高，这就是缺陷修复成本的放大效应。 关于缺陷修复成本的放大效应，在缺陷修复成本中会详细介绍。
缺陷集群效应 Pareto 原则是 20 世纪初意大利统计学家、经济学家维弗雷多·帕雷托提出的，他指出：“在任 何特定群体中，重要的因数通常只占少数，而不重要的因数则占多数，因此只要控制具有重要性的 少数因数即可以控制全局。”这个原理经过多年的演化，已变成当今管理学界所熟知的二八法则， 即 80%的公司利润来自 20%的重要客户，其余的 20%的利润则来自 80%的普通客户。 在我们的测试过程中，对所有的缺陷所分布的规则进行分析时，发现也存在这类集群现象。 80%的缺陷主要集中在 20%的模块中，也就是说，缺陷其实并不是平均分布，其也呈现集群分布 方式。 依据缺陷集群现象，我们可以对测试过程进行以下改进： 测试时应该将主要精力放在核心的 20%的功能模块中。 通常一个模块发现很多缺陷，那么通常这个模块中可能发现更多的缺陷。
缺陷的收敛性 缺陷的收敛性是指在系统测试过程中，每个 Build 版本所发现的缺陷数是逐渐减少的，呈逐步 收敛的现象，最后趋向于零值。缺陷收敛性如图 9-5 所示。需要注意的是，虽然缺陷是具有收敛性 的，但是并不代表测试过程中下一个 Build 版本所发现的缺陷数一定比上一个 Build 版本所发现的 缺陷数少。在图 9-5 中，T2 版本所发现的缺陷就比 T1 版本所发现的缺陷多，这种现象一般是由以 下两个原因引起的： 需求变更：需求出现修改或增加的情况时，可以导致当前 Build 版本所发现的缺陷数增多。 修改上一版本的缺陷时引入了一些新的缺陷。
一般情况下，这种情况只会在测试的前期出现，如果在测试后期出现这种情况（后期缺陷数只 会出现小幅度的反弹，并且缺陷的数量不多，一般是在 5 个以内），说明我们制定的测试策略存在 很大的问题。
缺陷收敛性的曲线图中有两个特征： （1）Bug 收敛点。Bug 收敛点是指发现的缺陷开始逐渐减少的一个转折点，如图 9-5 所示， 在 T3 版测试时 Bug 数量开始出现收敛现象，T3 版即为收敛点。 （2）零 Bug 反弹 零 Bug 反弹是指在某一个 Build 测试版本过程中发现零个 Bug。零 Bug 反弹一般出现在测试的 后期，后期主要是验证缺陷修改的情况，如图 9-5 所示，在 T5 时出现零 Bug 反弹现象，即 T5 版 本只发现零个 Bug，但在 T6、T7 和 T8 版又发现一些 Bug，此时就出现明显的零 Bug 反弹现象。 为什么在后期又可能发现极少一些 Bug 呢？工作中有可能出现这种情况，T5 主要是对修改的问题 进行回归测试，但开发工程师并没有一次性将所有的遗留问题都修改成功，不得不提交 T6 版的测 试。但 T5 回归测试修改的问题时，并未带来新的 Bug，而在 T6 时遗留问题又引入了新的 Bug， 这样就容易出现零 Bug 反弹现象。
