嵌入式软件缺陷率

尽管我对这种情况下任何估计的有效性表示怀疑,但我还是发现了一些可能相关的统计数字。

在 this article ,作者引用了发表在 Software Assessments, Benchmarks, and Best Practices (Jones, 2000) . 在 SIE CMM Level 1 ,这听起来与此代码的级别类似,可以预期每段代码的缺陷率为0.75 function point . 我会让你来决定 功能点 metrics tool 进行分析。

代码完整的Steve McConnell cites a study 高得多

关于警告的要点是,有些是良性的,有些是错误(即,将导致软件的不希望的行为),如果在假定它们都是良性的基础上忽略它们,则会引入错误。而且有些人会 成为 当其他情况发生变化时,维护中的错误,但如果您已经选择接受警告,则您无法防止此类错误的出现。

你的问题是“5个缺陷/100行代码是合理的估计吗?”这个问题很难回答,而且它高度依赖于代码库和代码复杂性。

为了打开管理层形象的眼睛,我建议至少采取一种三管齐下的方法:

• 获取特定的编译器警告,并显示其中一些警告如何导致未定义/灾难性行为。并不是所有的警告都那么重要。例如,如果有人使用未初始化的指针,那就是纯金。如果有人将一个无符号的16位值填充到一个无符号的8位值中,并且可以显示16位值将始终为<=255,那么这个值不会有助于使您的情况变得如此强烈。
• 运行静态分析工具。 PC-Lint (或Flexelint)很便宜,而且提供了很好的“物美价廉”。它几乎肯定会捕获编译器不会捕获的内容,而且它还可以跨翻译单元运行(将所有内容都连接在一起,即使有两个或更多的过程),并找到更细微的错误。再次,使用其中一些作为指示。
• 运行一个工具,它将给出关于代码复杂性的其他度量,这是另一个bug源。我建议你 M Squared's Resource Standard Metrics (RSM) 这将为您提供比您希望的更多的信息和度量(包括代码复杂性)。当你告诉管理层 a complexity score over 50 is "basically untestable"

还有一点:我需要在我的组中进行干净的编译,并清除Lint输出。通常这只能通过编写好的代码来实现,但有时需要对编译器/lint警告进行调整,以使工具安静下来,不出现问题(明智地使用)。

但我要强调的是: . 这是一个令人钦佩的目标,但您也可以无意中破坏工作代码,和/或发现在“破坏”代码中意外工作的未定义行为。是的,这真的发生了。所以小心行事。

最后,如果您已经有了一组可靠的测试,这将帮助您确定在重构时是否意外中断了某些内容。

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

我的猜测是,如果源代码包含这么多警告,那么代码中将隐藏很多bug。

这还取决于谁编写了代码(经验水平),以及代码库有多大。

在代码上运行静态分析工具时会得到多少错误?

编辑

运行cccc,检查mccabe的循环复杂性。它应该说明代码有多复杂。

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

运行其他静态分析工具。

如果您想要获得缺陷数量的估计,通常的统计估计方法是对数据进行子采样。我会随机挑选三个中等大小的子程序,仔细检查它们是否有错误(消除编译器警告、运行静态分析工具等)。如果在随机选择的100行代码中发现三个bug,那么在其余代码中出现类似的bug密度似乎是合理的。

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

对部分代码执行一些单元测试、代码检查和运行静态分析工具。向管理层展示使用这些方法发现的bug数量。希望结果能说明问题。

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