是否有测量缺陷密度的标准方法？大多数在线网站都声明应按以下方式衡量:
number of defects discovered / the code size
我的问题是:
- 是否应该从发现的缺陷中减去在此期间“修复”的缺陷？
- 由于时间不够，人们应该如何处理决定在下一个版本中修复的缺陷？这些积压的缺陷是否应该添加到下一个版本的密度中？
- 如果已证明代码由于大量重复而不必要地膨胀，则分母中的 KLOC 可能不是一个好的衡量标准。应该如何考虑这一因素？
- 能否将特定时间段内的流失情况以及特定模块的现有积压缺陷与由于流失而创建/发现的缺陷数量相关联
我们的最终目标是能够 (a) 将我们的缺陷密度与行业标准进行比较 (b) 识别脆弱且有更多 bug 且值得更多关注的模块 (c) 使用一致的指标来绘制缺陷密度趋势线显示模块质量随着时间的推移而提高
最佳答案
缺陷密度是指在规定的开发/操作期间在软件/模块中检测到的已确认缺陷的数量除以软件/模块的大小。 ('缺陷(已确认并商定(不仅仅是报告)))。
缺陷密度: 缺陷密度=缺陷/单位尺寸
这里可能出现的问题是，这个单位大小的实际含义是什么。 单元大小=大小通常以代码行数或功能点来计算。作为一名优秀的编码员，您应该有足够的信心，确保您的编码中没有重复，这可能会导致代码大小膨胀。
例如:假设 1 个 KLOC 中发现 10 个错误 因此DD为10/KLOC
关于software-quality - 应该如何测量缺陷密度？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6067990/