将代码指标与错误密度相关联的实验

我想知道是否有人进行了一些将代码量度（SLOC，循环复杂度等）与面向对象应用程序中的错误密度相关联的实验。

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

我的目标是

测量2-3个月内所有有趣的指标（声纳中已经有很多）。
找到一个与新错误数量相关的指标。
进行根本原因分析以检查为什么会发生这种情况（例如，我们是否缺乏某种设计技能？）。
提高技能并衡量变化的两次迭代。
冲洗并从2开始重复。

如果您没有任何经验，但记得看过有关此主题的论文/博客，希望与您分享。

到目前为止，我已经找到了以下链接，其中包含有关此主题的一些信息

错误是否存在于复杂代码中？-只是演示文稿中的幻灯片。
变更和错误：挖掘和预测开发活动 -只需滑动演示文稿即可。最重要的是，依赖关系越多，发生错误的几率就越高（我认为这是很普遍的规则）。
失败是一个四个字母的词 -关于错误和指标之间相关性的天堂。

code-quality code-metrics

— 奥古斯托
source

如果要避免关闭，则应重新分配问题。Stack Exchange网站不是搜索引擎，用户也不是个人研究助手。而不是要求提供论文链接，重点应该放在询问与缺陷和缺陷密度相关的度量标准类型上。

— 托马斯·欧文斯

对不起，这个问题是我成为我的个人搜索助手的要求，这绝对不是我想要做的，但是找到这些类型的论文并不是很常见。我已更改标题，以使其他人没有相同的印象。

— 2012年

Answers:

每当我听到尝试将某种基于代码的度量标准与软件缺陷相关联时，我想到的第一件事就是McCabe的圈复杂度。各种研究发现，高圈复杂度与缺陷数量之间存在相关性。但是，其他研究以相似的大小（在代码行方面）查看模块的研究发现，可能没有相关性。

对我来说，模块中的线数和圈复杂性都可以作为可能存在缺陷的良好指示，或者如果对模块进行了修改，则注入缺陷的可能性更大。具有较高的循环复杂性的模块（尤其是在类或方法级别的模块）更难理解，因为代码中存在大量独立的路径。包含大量行的模块（同样，尤其是在类或方法级别）也很难理解，因为行的增加意味着发生了更多的事情。有许多静态分析工具支持针对指定规则和循环复杂性来计算代码的源代码行，似乎捕获它们将是一件容易的事。

在霍尔斯特德复杂性的措施也可能是有趣的。不幸的是，它们的有效性似乎有些争议，因此我不必依赖它们。Halstead的一种测量方法是根据工作量或工作量（程序长度（以总操作符和操作数计）与程序词汇量（以不同的操作符和运算符计）之间的关系）进行估计。

还有一组称为CK度量的度量。该度量标准套件的第一个定义似乎出现在Chidamber和Kemerer撰写的题为面向对象设计的度量套件中。他们定义了每个类的加权方法，继承树的深度，子代数，对象类之间的耦合，类的响应以及方法中缺乏内聚性。他们的论文提供了计算方法以及如何分析每种方法的描述。

就分析这些指标的学术文献而言，您可能对由Ramanath Subramanyam和MS Krishna撰写的CK指标的经验分析对面向对象的设计复杂性：对软件缺陷的影响感兴趣。他们分析了六个CK指标中的三个（每个类的加权方法，对象分类之间的耦合以及继承树的深度）。仔细阅读本文，似乎他们发现这些是潜在有效的度量标准，但必须谨慎解释，因为“改进”一个度量标准可能会导致其他变化，从而也增加了出现缺陷的可能性。

周玉明和梁海峰合着的用于预测高低故障的面向对象设计指标的实证分析也检验了CK指标。他们的方法是确定是否可以根据这些指标预测缺陷。他们发现，除了继承树的深度和子代数之外，许多CK指标在预测可能存在缺陷的区域中具有一定的统计意义。

如果您拥有IEEE会员资格，我建议您在IEEE Transactions on Software Engineering上搜索更多的学术出版物，并在IEEE Software中搜索更多的真实世界和应用报告。ACM的数字图书馆中也可能有相关出版物。

— 托马斯·欧文斯
source

Halstead度量标准都与原始SLOC（代码的源代码行数）密切相关。到那时，与任何Halstead指标相关的任何东西都与原始SLOC相关联，并且测量SLOC比任何Halstead指标都容易。

— 约翰·斯特罗姆

@ JohnR.Strohm我不同意在使用工具进行计算时，计算SLOC比计算Halstead指标更容易。假设Halstead度量标准是有效的（实际上是有争议的，但是对于无效的度量标准则无所谓），知道开发代码所需的时间或系统中预计的缺陷数量比知道该数量更有用。行。我可以使用时间数据来建立时间表，使用缺陷数据来建立质量计划，或者为困难的代码审查分配足够的时间。使用原始SLOC进行这些操作比较困难。

— 汤玛斯·欧文斯

@ JohnR.Strohm我敢肯定，Halstead指标计算程序的执行时间比SLOC计数程序要长一些。但是，假设有效的输出成为决策的有效输入，我宁愿拥有有意义的时间，精力和缺陷数据，而不是原始的SLOC计数。再次假设有效的输入和有效的计算输出，则更复杂的度量的附加值通常值得额外的计算时间。

— 汤玛斯·欧文斯

@ThomasOwens，是否可以直接从原始SLOC的估算到死亡的过程中直接估算软件工作量以及成本和进度的问题。在对实际项目数据进行了大量研究之后，该问题得到了肯定的解决。参见Barry Boehm撰写的“软件工程经济学”，1981

— 。– John R. Strohm，2012年

@ThomasOwens：此外，必须认识到Halstead指标本质上是追溯性的。您无法测量尚未编写的软件的Halstead指标。另一方面，可以估计给定任务的原始SLOC，并且，由于具有足够详细的规格和一点经验，因此很容易接近估计值。此外，非常容易将估计值与实际值进行比较，以微调一个人的估计启发式方法，并校准一个人的成本估计器。通用动力/沃思堡在1980年代初期为此做了很多工作。

— 约翰·R·斯特罗姆

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

圈复杂度和虫子密度之间的关系：这是真正的问题吗？

答案是不。保持尺寸不变，研究表明CC和缺陷密度之间没有相关性。但是，还有其他两个有趣的相关关系需要研究：

第一个是：CC是否与检测和修复缺陷的持续时间密切相关？换句话说，如果CC较低，我们将花费更少的时间调试和修复缺陷吗？

第二个问题是：CC是否与故障反馈率（FFR，即应用一种更改或修复一种缺陷产生的平均缺陷数）密切相关？

它需要更多的调查，看看是否有人曾凭经验研究过这种相关性。但是，我的直觉和从与我一起工作的团队那里得到的反馈是，一侧的循环复杂性与另一侧检测并修复缺陷或更改影响的持续时间之间存在很强的正相关关系。

这是一个很好的实验。对结果保持警惕！

— 诺曼
source

不值得一票，但应该是“一些研究没有相关性”，因为其他研究确实具有相关性。

— David Hammen

史蒂夫·麦康奈尔（Steve McConnell）在《代码完整》（第457页）一书中说：“控制流复杂性很重要，因为它与低可靠性和频繁错误相关联”。然后，他提到了一些支持这种相关性的参考文献，包括McCabe本人（他被认为开发了圈复杂度度量标准）。其中大多数早于面向对象语言的广泛使用，但是由于此指标适用于这些语言中的方法，因此您可能正在寻找引用。

这些参考是：

汤姆·麦凯比。1976年。“一项复杂性措施”。IEEE Transactions on Software Engineering，SE-2，编号。4（12月）：308-20
Shen，Vincent Y.，等。1985年。“识别错误符号软件-实证研究。” IEEE软件工程学报SE-11，第4号（4月）：317-24。
Ward，William T.，1989年。“使用McCabe复杂性度量标准预防软件缺陷”。惠普杂志，四月，64-68。

根据我自己的经验，McCabe的度量标准（可以由程序在许多代码段中计算得出）对于查找过于复杂且极有可能包含错误的方法和函数很有用。尽管我还没有计算过，但高圈复杂度函数与低圈复杂度函数之间的错误分布使我得以发现那些被忽视的编程错误。

— 量子欧米茄
source