2

是否有测量缺陷密度的标准方法？大多数在线网站声明它应该被衡量为：

number of defects discovered / the code size

我的问题是：

  • 是否应该从发现的缺陷中减去在此期间“修复”的缺陷？
  • 由于时间不够，决定在下一个版本中修复的缺陷应该怎么办？是否应该将这些积压缺陷添加到下一个版本的密度中？
  • 如果已经证明代码由于大量重复而不必要地膨胀，那么分母中的 KLOC 可能不是一个好的衡量标准。应该如何考虑其中的一个因素？
  • 是否可以将特定时间段内的流失以及特定模块的现有缺陷积压与由于流失而创建/发现的缺陷数量相关联

我们的最终目标是能够 (a) 将我们的缺陷密度与行业标准进行比较 (b) 识别易碎且有更多错误并值得更多关注的模块 (c) 使用一致的指标来绘制趋势线来展示随着时间的推移，模​​块质量的提高

4

5 回答 5

6

缺陷密度是在定义的开发/操作期间在软件/模块中检测到的已确认缺陷的数量除以软件/模块的大小。（'缺陷（确认并同意（不只是报告）））。

缺陷密度：缺陷密度 = 缺陷/单位尺寸

这里可能出现的问题是，这个单元大小实际上是什么意思。Unit size=Size 通常以代码行数或功能点数计算。作为一名优秀的编码员，您应该有足够的信心，您的编码中没有重复可能会增加您的代码大小。

例如：假设在 1 KLOC 中发现 10 个错误，因此 DD 为 10/KLOC

于 2013-05-23T07:00:42.890 回答
2

缺陷密度用于衡量代码/模块/需求/产品的质量。是的，测量相同的标准是缺陷密度 = 缺陷数/尺寸

但是在这里，如果我们将大小用作 KLOC（千行代码）或 FP（功能点），那么可能很难计算相同的值，有时对于客户（或某些持有人）来说没有任何意义。因此，我们在计算缺陷密度时也应该考虑以下几点。

  1. 缺陷数量应通过添加与代码相关的所有缺陷来计算（这些缺陷也应包括审查缺陷、内部错误和客户端/UAT 错误），因为所有错误都与代码相关，因此应该是缺陷密度的一部分。
  2. 在添加缺陷之前根据它们的严重性均衡缺陷计数，这会提供更准确的结果，这也是一个标准。可以将其视为严重错误 = 5，高 = 3，中 = 1，低 = 0.5。这有时称为加权缺陷密度，但结果更精确。
  3. 大小不应仅限于代码行或功能点。可以不是。的要求。最简单有效的方法是将大小作为编码所花费的时间（这不应该包括代码审查、编码返工工作）。因此，缺陷密度可以被认为是每 100 人日的编码工作中的缺陷数，如果您指定了项目目标，那么您可以查看这是否符合您的目标。

这是计算缺陷密度的一种有效且简单的方法，您可以在一段时间内查看您是否正在改进。

于 2015-06-15T21:00:33.007 回答
1

我猜这Defect Density用于检测程序员产生缺陷的速度，而减去固定缺陷与客户/最终用户的投诉数量有关。

在你的目标中，(a) 似乎不合理，(b) 非常敏锐并且会带来回报，(c) 可能会导致错误的乐观。

您确实应该瞄准，Zero Defects并且出于度量目的，您应该忽略在发布之前发现和修复的错误。

于 2011-05-29T21:55:55.130 回答
0

缺陷基本上是，当产品交付给客户之后，任何功能都不起作用或者您可以说与用户要求有偏差，您无法衡量缺陷，但您可以采取一些措施来防止出现缺陷，可以通过不同的测试方法，您将在下面找到一些重要的方法：

  • 冒烟测试
  • 健全性测试
  • 黑盒测试
  • 白色测试
  • 负载和压力测试

您应该完全了解客户对您的要求，这将帮助您防止缺陷。

于 2013-01-02T04:32:58.190 回答
0 
total number detected defects in your developed software divided by size of your software in line of code . it is calculated in KLOC ,it means it is multiply by 1000 
for example
defects found are 12
size is 2000
defect density= defects/size
answer=.006
it is calculated in kloc so .006*1000=6 so defect density is 6
于 2014-06-04T17:15:19.630 回答