将代码度量与bug密度相关联的实验

Question

我想知道是否有人做过一些实验，将代码度量(SLOC、圈复杂度等)与面向对象应用程序中的bug密度相关联。

我并不是在寻找只证明或否定相关关系的实验，而是两者兼而有之的实验。我并没有试图找到一个灵丹妙药，因为我相信项目的bug密度可能与给定项目或团队的一个或多个指标相关，而且相关性在项目/团队的生命周期中可能会发生变化。

我的目标是

1. 测量所有有趣的度量2-3个月(我们已经有相当多的从声纳)。
2. 找到一个与新bug的数量相关的指标。
3. 做一个根本原因分析来检查为什么会发生这种情况(例如，我们缺乏某种设计技能吗？)
4. 为几次迭代提高技能和度量更改。
5. 冲洗并重复2次。

如果你在这方面没有任何经验，但记得看过一篇关于这个主题的论文/博客，如果你能与我分享，我将不胜感激。

到目前为止，我已经找到了与这个主题有关的一些信息的以下链接

• 臭虫是否居住在复杂代码中？ --只是演示文稿上的幻灯片。
• 变化与问题:开采和预测开发活动 --只需幻灯片就可以实现演示。底线是，依赖关系越多，出现bug的可能性就越高(我认为这是一个相当普遍的规则)。
• 失败是一个四个字母的词。 --一个关于bug和度量之间相关性的天堂。

Answer 1

每当我听说有人试图将某种类型的基于代码的度量与软件缺陷相关联时，我首先想到的是McCabe的圈复杂度。各种研究发现，高度的圈复杂度与缺陷的数量之间存在相关性。然而，其他一些研究发现，类似大小的模块(在代码行方面)可能没有相关性。

对我来说，模块中的行数和圈复杂度都可以很好地指示可能的缺陷，或者如果对模块进行修改，那么缺陷注入的可能性就会更大。具有高度圈复杂度的模块(尤其是类或方法级)很难理解，因为代码中有大量独立的路径。具有大量行的模块(尤其是类或方法级别的模块)也很难理解，因为行的增加意味着更多的事情正在发生。有许多静态分析工具支持根据指定的规则和圈复杂度计算源代码行，似乎捕获它们将抓住低挂的成果。

霍尔斯特德复杂性测度可能也很有趣。不幸的是，他们的有效性似乎有些争论，所以我不需要依赖他们。霍斯特德的度量之一是基于努力或体积的缺陷估计(程序长度与操作数的关系，以及程序词汇量与不同运算符和运算符之间的关系)。

还有一组度量被称为CK度量。这个度量套件的第一个定义似乎出现在一篇题为Chidamber和Kemerer的面向对象设计的度量套件的论文中。它们定义了每个类的加权方法，继承树的深度，子级的数量，对象类之间的耦合，类的响应，以及方法中缺乏凝聚力。他们给出了计算方法，并描述了如何分析每一种方法。

在分析这些度量的学术文献中，您可能感兴趣的是面向对象设计复杂性的CK度量的实证分析:软件缺陷的影响，由Ramanath Subramanyam和M.S.Krishna撰写。他们分析了六种CK度量中的三种(每类加权方法、对象类之间的耦合以及继承树的深度)。看一看论文，他们似乎发现这些都是潜在有效的度量标准，但必须谨慎地解释为“改进”一个人可能会导致其他的变化，这也会导致更大的缺陷概率。

周玉明和梁国荣的“面向对象的高、低严重故障预测设计指标实证分析”也对CK指标进行了检验。他们的方法是确定他们是否能够根据这些指标来预测缺陷。他们发现，除了继承树的深度和孩子的数量之外，许多CK指标在预测缺陷可能存在的区域方面都有一定程度的统计意义。

如果您有IEEE会员资格，我建议在软件工程中的IEEE事务中搜索更多的学术出版物，并在IEEE软件中搜索更多的真实世界和应用报告。ACM也可能在其数字图书馆中有相关的出版物。

Answer 2

我在我的一篇博文中讨论了可能的相关性：

圈复杂度与虫密度的相关关系:这是真正的问题吗？答案是否定的。在尺寸不变的情况下，研究与缺陷密度之间没有相关性。然而，还有两个有趣的相关性需要研究:第一个是: CC与检测和修复缺陷的持续时间密切相关吗？换句话说，如果CC较低，我们会花费更少的时间调试和修复缺陷吗？第二个问题是: CC与故障反馈比(FFR，应用一次更改或修复一次缺陷所造成的平均缺陷数)密切相关吗？它需要更多的调查，看看是否有人曾经研究过这种相关性的经验。但是，我的直觉以及与我一起工作的团队给我的反馈是，一方面的圈复杂度与发现和修复缺陷的持续时间或变化对另一边的影响之间存在着很强的正相关。这是一个很好的实验。对结果保持警惕！

Answer 3

在“代码完成”( Complete，p.457 )一书中，Steve McConnell说“控制流的复杂性很重要，因为它与低可靠性和频繁错误相关”。然后，他提到了一些支持这种相关性的引用，包括McCabe本人(他被认为开发了圈复杂度度量)。这些都是在面向对象语言广泛使用之前的大部分时间，但是由于这个指标适用于这些语言中的方法，所以引用可能就是您所要寻找的。

这些参考资料是：

• McCabe，汤姆。1976年。“一个复杂的度量。”，SE-2，no. 4(12)：308-20
• 沈文生，等。1985年。“识别容易出错的软件--一项实证研究”SE-11，no.4 (4月)：317-24。
• Ward，William T. 1989。“使用McCabe的复杂性度量来防止软件缺陷”惠普杂志，4月，64-68。

根据我自己的经验，McCabe的度量，因为它可以由程序在许多代码部分上计算，在寻找方法和函数是有用的，这些方法和函数过于复杂，并且包含错误的可能性很高。虽然我还没有计算，高圈复杂度函数与低圈复杂度函数之间的误差分布，研究这些函数让我发现了被忽略的编程错误。