嵌入式软件缺陷率答案

【问题标题】：Embedded Software Defect Rate嵌入式软件缺陷率
【发布时间】：2010-10-29 07:43:48
【问题描述】：

在为嵌入式处理器 (DSP) 编写的 C++ 代码库中，如果没有单元测试、代码审查、静态代码分析，并且编译项目会生成大约 1500警告。 5 个缺陷/100 行代码是合理的估计吗？

【问题讨论】：

你为什么想知道？
很难说警告的数量有多相关。来自标头的大多数警告将在包含该标头的所有翻译单元中报告。
@Jan：向管理层表明代码库中可能存在很多错误，我们应该立即着手解决。
我一直在走这条路，但没有成功。我建议寻找一个在客户脸上爆炸的错误。如果您开始在这样的代码库中“修复”一些东西，并且您不熟悉代码，那么预计会出现新的错误和从休眠中醒来的旧错误。
为什么缺陷率（即一个数字）甚至很重要？一种可能是良性的，而另一种可能会杀死某人，或者扼杀你的生意。您可能会容忍许多第一个，但只有一个是关键的。

标签： c++ embedded software-quality

【解决方案1】：

您的问题是“5 个缺陷/100 行代码是一个合理的估计吗？”这个问题非常难以回答，并且高度依赖于代码库和代码复杂性。

您还在评论中提到“向管理层表明代码库中可能存在很多错误”——太好了，赞，继续。

为了打开管理层形象的眼睛，我建议至少采用三管齐下的方法：

获取特定的编译器警告，并展示其中的一些警告如何导致未定义/灾难性的行为。并非所有的警告都会如此重要。例如，如果有人使用未初始化的指针，那就是纯金。如果有人将一个无符号的 16 位值填充到一个无符号的 8 位值中，并且可以证明 16 位值将始终为
运行静态分析工具。 PC-Lint（或 Flexelint）很便宜，而且“物超所值”。它几乎肯定会捕获编译器不会捕获的东西，并且它还可以跨翻译单元运行（将所有内容放在一起，即使经过 2 次或更多遍）并找到更微妙的错误。同样，使用其中一些作为指示。
运行一个工具，该工具将提供有关代码复杂性的其他指标，这是另一个错误来源。我推荐M Squared's Resource Standard Metrics (RSM)，它将为您提供比您希望的更多的信息和指标（包括代码复杂性）。当您告诉管理层 a complexity score over 50 is "basically untestable" 并且您在一个例程中的得分为 200 时，这应该会让您大开眼界。

另外一点：我需要在我的组中进行干净的编译，并且也需要干净的 Lint 输出。通常这可以仅通过编写好的代码来完成，但有时需要调整编译器/lint 警告以使工具安静下来处理没有问题的事情（明智地使用）。

但我想说的重要一点是：进入和修复编译器和 lint 警告时要非常小心。这是一个令人钦佩的目标，但您也可能无意中破坏工作代码，和/或发现意外在“破坏”代码中起作用的未定义行为。是的，这确实发生了。所以要小心行事。

最后，如果您已经有一套可靠的测试，这将帮助您确定在重构时是否意外破坏了某些东西。

祝你好运！

【讨论】：

+1 以获得谨慎的建议。另请参阅本书以获取从未经测试的代码过渡到对重构友好的代码的帮助：amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/…
@matthieu：那是一本很棒的书。它也强烈推荐它。
感谢您的宝贵建议，并指出在修复看似无害的警告时引入新错误的风险，尤其是在没有测试的情况下。

【解决方案2】：

尽管我对这种情况下任何估计的有效性持怀疑态度，但我发现了一些可能相关的统计数据。

在this article 中，作者引用了来自Software Assessments, Benchmarks, and Best Practices (Jones, 2000) 上发表的“大量实证研究”的数据。在SIE CMM Level 1，听起来就像这段代码的级别，可以预期每个function point 的缺陷率为0.75。我将由您来确定 功能点 和 LOC 在您的代码中如何关联 - 您可能需要 metrics tool 来执行该分析。

Steve McConnell 在 Code Complete cites a study 中由同一团队开发的 11 个项目中，5 个没有代码审查，6 个有代码审查。未审查代码的缺陷率为每 100 LOC 4.5，而审查代码的缺陷率为 0.82。因此，在此基础上，在没有任何其他信息的情况下，您的估计似乎是公平的。但是，我必须假设这个团队有一定的专业水平（只是因为他们觉得有必要进行研究），并且他们至少会注意警告；您的缺陷率可能要高得多。

关于警告的要点是，有些是良性的，有些是错误的（即会导致软件的不良行为），如果您假设它们都是良性的而忽略它们，则会引入错误。此外，当其他条件发生变化时，有些会在维护中变成错误，但如果您已经选择接受警告，则您无法防御此类错误的引入。

【讨论】：

非常感谢您精心研究的答案。我必须承认，我以前从未听说过功能点。

【解决方案3】：

看看代码质量。它会很快告诉您隐藏在源中的问题数量。如果源码很丑，需要很长时间才能理解，代码中会有很多错误。

结构良好、风格一致且易于理解的代码将包含更少的问题。代码显示了它付出了多少努力和思考。

我的猜测是，如果源代码包含这么多警告，那么代码中就会隐藏很多错误。

【讨论】：

代码质量是相对的，很难衡量。只看代码不会提供太多信息。
没错，但它可以让您了解软件中发生的情况。

【解决方案4】：

这也取决于谁编写了代码（经验水平），以及代码库有多大。

我会将所有警告视为错误。

在代码上运行静态分析工具时会出现多少错误？

编辑

运行 cccc，检查 mccabe 的循环复杂度。它应该告诉它的代码有多复杂。

http://sourceforge.net/projects/cccc/

运行其他静态分析工具。

【讨论】：

我什至没有尝试在代码库上运行静态分析工具。我认为我们应该首先尝试将警告计数归零。这看起来合理吗？
@geschema 是的，当然。在我看来，代码应该在没有警告的情况下编译，因为大多数警告都是有效的。
我认为您必须假设任何编写了那么多代码并且没想过修复警告的人都非常缺乏经验！我想知道它是如何变得如此糟糕的？
@Clifford 不必如此。可能是态度吧。有些人不关心编写单元测试，有些人忽略警告等。
@Clifford：代码库演变成这样的原因有很多，但我认为主要是对代码的态度问题。帮助按时完成的快速破解被认为是英勇的。人们没有意识到，在没有安全网的情况下以这种方式工作只会积累技术债务，总有一天必须偿还。

【解决方案5】：

如果您想估计缺陷数量，通常的统计估计方法是对数据进行二次抽样。我会随机挑选三个中等大小的子程序，并仔细检查它们是否存在错误（消除编译器警告、运行静态分析工具等）。如果您在随机选择的 100 行代码中发现三个错误，那么其余代码中的错误密度相似似乎是合理的。

这里提到的引入新错误的问题是一个重要的问题，但是您不需要将修改后的代码检查回生产分支来运行此测试。我建议在修改任何子例程之前进行彻底的单元测试，并清理所有代码，然后在将新代码发布到生产环境之前进行非常彻底的系统测试。

【讨论】：

@VJo：Subsample 并不意味着一个样本！这是给你的统计数据。
@Clifford 统计很好，但莫菲定律高于统计 ;)

【解决方案6】：

如果您想展示单元测试、代码审查、静态分析工具的好处，我建议您进行试点研究。

对部分代码进行一些单元测试、代码审查和运行静态分析工具。向管理层展示您使用这些方法发现了多少错误。希望结果不言自明。

【讨论】：

【解决方案7】：

以下文章有一些基于已应用静态分析的实际项目的数字：http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html

当然，计算异常的标准会极大地影响结果，导致表 1 中显示的数字有很大差异。在此表中，C 的每千行代码的异常数从 500 起(!) 到大约 10（自动生成）。

【讨论】：