考虑到没有单元测试、没有代码审查、没有静态代码分析，并且编译项目会产生大约 1500 条警告，我在为嵌入式处理器 (DSP) 编写的 C++ 代码库中可以预期的缺陷率是多少。5 个缺陷/100 行代码是一个合理的估计吗？
问问题
576 次
7 回答
10
您的问题是“5 个缺陷/100 行代码是一个合理的估计吗？” 这个问题非常难以回答，并且高度依赖于代码库和代码复杂性。
您还在评论中提到“向管理层表明代码库中可能存在很多错误”——太好了，赞，继续。
为了打开管理层的比喻眼，我建议至少采用三管齐下的方法：
- 采取特定的编译器警告，并展示其中一些如何导致未定义/灾难性的行为。并非所有的警告都会如此重要。例如，如果有人使用未初始化的指针，那就是纯金。如果有人将一个无符号的 16 位值填充到一个无符号的 8 位值中，并且可以证明 16 位值将始终为 <= 255，那么这个值不会帮助您的情况如此强烈。
- 运行静态分析工具。 PC-Lint（或 Flexelint）价格便宜，而且“物超所值”。它几乎肯定会捕获编译器不会捕获的东西，并且它还可以跨翻译单元运行（将所有内容放在一起，即使经过 2 次或更多遍）并找到更微妙的错误。同样，使用其中一些作为指示。
- 运行一个工具，该工具将提供有关代码复杂性的其他指标，这是另一个错误来源。我推荐M Squared 的 Resource Standard Metrics (RSM)，它将为您提供比您希望的更多的信息和指标（包括代码复杂性）。当您告诉管理层超过 50 的复杂性分数“基本上无法测试”并且您在一个例程中的分数为 200 时，这应该会让一些人大开眼界。
还有一点：我需要在我的组中进行干净的编译，并且也需要干净的 Lint 输出。通常这可以仅通过编写好的代码来完成，但有时需要调整编译器/lint 警告以使工具安静下来处理没有问题的事情（明智地使用）。
但我想说的重要一点是：进入和修复编译器和 lint 警告时要非常小心。这是一个令人钦佩的目标，但您也可能无意中破坏工作代码，和/或发现意外在“破坏”代码中起作用的未定义行为。是的，这确实发生了。所以小心行事。
最后，如果您已经有一套可靠的测试，这将帮助您确定在重构时是否不小心破坏了某些东西。
祝你好运！
于 2010-10-29T14:04:16.203 回答
4
这也取决于谁编写了代码（经验水平），以及代码库有多大。
我会将所有警告视为错误。
当您对代码运行静态分析工具时，您会遇到多少错误？
编辑
运行 cccc，并检查 mccabe 的循环复杂度。它应该告诉它的代码有多复杂。
http://sourceforge.net/projects/cccc/
运行其他静态分析工具。
于 2010-10-29T07:53:49.950 回答
4
看看代码质量。它会很快告诉您隐藏在源中的问题数量。如果源代码丑陋并且需要很长时间才能理解，那么代码中就会出现很多错误。
具有一致风格且易于理解的结构良好的代码将包含更少的问题。代码显示了它付出了多少努力和思考。
我的猜测是，如果源代码包含这么多警告，那么代码中就会隐藏很多错误。
于 2010-10-29T09:11:22.003 回答
4
尽管我对这种情况下任何估计的有效性持怀疑态度，但我发现了一些可能相关的统计数据。
在这篇文章中，作者引用了来自“大量实证研究”的数据，这些数据发表在Software Assessments, Benchmarks, and Best Practices (Jones, 2000)上。在SIE CMM 级别 1上，这听起来像此代码的级别，可以预期每个功能点的缺陷率为 0.75 。我将由您来确定功能点和 LOC 在您的代码中如何关联 - 您可能需要一个度量工具来执行该分析。
在 Code Complete 中，Steve McConnell引用了对同一团队开发的 11 个项目的研究，其中 5 个没有代码审查，6 个有代码审查。未审查代码的缺陷率为每 100 LOC 4.5，而审查代码的缺陷率为 0.82。因此，在此基础上，在没有任何其他信息的情况下，您的估计似乎是公平的。但是，我必须假设这个团队有一定的专业水平（只是因为他们觉得有必要进行研究），并且他们至少会注意警告；你的缺陷率可能会高得多。
关于警告的要点是有些是良性的，有些是错误的（即会导致软件的不良行为），如果您假设它们都是良性的而忽略它们，您将引入错误。此外，当其他条件发生变化时，有些在维护中会变成错误，但是如果您已经选择接受警告，则无法防御此类错误的引入。
于 2010-10-30T07:50:26.577 回答
3
如果要估计缺陷数量，通常的统计估计方法是对数据进行二次抽样。我会随机挑选三个中等大小的子程序，并仔细检查它们是否存在错误（消除编译器警告、运行静态分析工具等）。如果您在随机选择的 100 行代码中发现三个错误，那么在其余代码中存在相似密度的错误似乎是合理的。
这里提到的引入新错误的问题是一个重要的问题，但是您不需要将修改后的代码检查回生产分支来运行此测试。我建议在修改任何子例程之前进行彻底的单元测试，并清理所有代码，然后在将新代码发布到生产环境之前进行非常彻底的系统测试。
于 2010-10-29T16:42:19.367 回答
2
如果你想展示单元测试、代码审查、静态分析工具的好处，我建议做一个试点研究。
对部分代码进行一些单元测试、代码审查和运行静态分析工具。向管理层展示您使用这些方法发现了多少错误。希望结果不言自明。
于 2010-11-01T11:18:02.280 回答
1
以下文章有一些基于已应用静态分析的实际项目的数字：http: //www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html
当然，计算异常的标准会显着影响结果，导致表 1 中显示的数字有很大差异。在此表中，C 的每千行代码的异常数量从 500（！）到大约 10（自动生成）。
于 2010-11-01T12:17:18.460 回答