在为嵌入式处理器（DSP）编写的C ++代码库中，我可以期待什么样的缺陷率，因为没有单元测试，没有代码审查，没有静态代码分析，并且编译项目产生大约1500警告。 5个缺陷/ 100行代码是否合理估计？
答案 0 :(得分：10)
您的问题是“5个缺陷/ 100行代码是否合理估算？”这个问题极难回答，而且它高度依赖于代码库和代码复杂性。
你还在评论中提到“向管理层展示代码库中可能存在很多错误” - 这很好，很荣幸，就是这样。
为了打开管理层的具象眼光，我建议至少采取三管齐下的方法：
另一点：我需要在我的组中进行干净的编译，并清理Lint输出。通常这可以通过编写好的代码来完成，但偶尔需要调整编译器/ lint警告来安静工具以解决非问题（明智地使用）。
但我想说的重点是：进入＆amp ;;时要非常小心修复编译器＆amp;棉绒警告。这是一个令人钦佩的目标，但您也可能无意中破坏工作代码，和/或发现在“损坏”代码中意外工作的未定义行为。是的，这确实发生了。所以谨慎行事。
最后，如果您已经有一套可靠的测试，这将有助于您确定在重构时是否意外破坏了某些内容。
祝你好运！答案 1 :(得分：4)
这还取决于编写代码的人（经验水平）以及代码库的大小。
我会将所有警告视为错误。
在代码上运行静态分析工具时会得到多少错误？
修改
运行cccc，并检查mccabe的循环复杂性。它应该告诉代码有多复杂。
http://sourceforge.net/projects/cccc/
运行其他静态分析工具。
答案 2 :(得分：4)
看看代码质量。它会很快告诉您隐藏在源中的问题数量。如果源代码很丑陋并需要很长时间才能理解代码中会有很多错误。
具有一致风格且易于理解的结构良好的代码将包含更少的问题。代码显示了它付出了多少努力和想法。
我的猜测是，如果源包含许多警告，那么代码中会隐藏很多错误。
答案 3 :(得分：4)
尽管我对这种情况下的任何估计的有效性持怀疑态度，但我发现了一些可能相关的统计数据。
在this article中，作者引用了Software Assessments, Benchmarks, and Best Practices (Jones, 2000)中发表的“大量实证研究”中的数字。在SIE CMM Level 1，听起来像这个代码的级别，可以预期每function point的缺陷率为0.75。我将留给您确定功能点和LOC如何与您的代码相关 - 您可能需要metrics tool来执行该分析。
Steve McConnell代码完成cites a study由同一团队开发的11个项目，5个没有代码审查，6个代码审查。未经审核的代码的缺陷率为每100 LOC 4.5个，并且对于审查的代码为0.82。所以在此基础上，如果没有任何其他信息，您的估计似乎是公平的。但是，我必须在这个团队中承担一定程度的专业精神（仅仅因为他们感到需要进行研究），并且他们至少会接受警告;您的缺陷率可能更高。
关于警告的一点是有些是良性的，有些是错误的（即会导致软件的不良行为），如果你假设它们都是良性的而忽略它们，你就会引入错误。此外，当其他条件发生变化时，有些人会在维护时成为错误，但如果您已经选择接受警告，则无法防止引入此类错误。
答案 4 :(得分：3)
如果要估计缺陷数，通常的统计估算方法是对数据进行二次采样。我会随机选择三个中等大小的子程序，仔细检查它们是否有错误（消除编译器警告，运行静态分析工具等）。如果您在随机选择的100行代码中发现三个错误，那么在其余代码中出现类似密度的错误似乎是合理的。
此处提到的引入新错误的问题是一个重要问题，但您无需将修改后的代码检入生产分支即可运行此测试。在修改任何子程序之前，我会建议一套完整的单元测试，并在将新代码发布到生产环境之前清理所有代码，然后进行非常彻底的系统测试。
答案 5 :(得分：2)
如果您想展示单元测试，代码评审，静态分析工具的好处，我建议您进行试点研究。
对部分代码执行一些单元测试，代码审查和运行静态分析工具。显示管理使用这些方法找到的错误数量。希望结果不言而喻。
答案 6 :(得分：1)
以下文章根据已应用静态分析的实际项目提供了一些数字：http://www.stsc.hill.af.mil/crosstalk/2003/11/0311German.html
当然，计算异常的标准会对结果产生显着影响，导致表1中所示数字的巨大变化。在此表中，每千行代码的异常数量范围为500 （！）到大约10（自动生成）。