什么是缺陷率跟踪的最佳选择？每个KLOC的缺陷？

Question

我正在尝试创建一些内部指标来演示（确定？）TDD如何改善代码中的缺陷率。

有没有比缺陷/ KLOC更好的方法？语言的“功能密度”怎么样？

任何意见或建议都会有所帮助。

谢谢 - 乔纳森

Answer 1

您还可以考虑映射缺陷发现率和缺陷解决率...查找错误需要多长时间，一旦找到错误，它们需要多长时间才能修复？据我所知，TDD应该可以改善修复时间，因为它可以让早期知道错误......对吗？

Answer 2

任何措施都是对缺陷与代码大小的任意比较;只要比较相似，就应该有效。例如，C中的缺陷/ kloc到C中的缺陷/ kloc如果你改变了语言，它会在任何情况下影响度量，因为另一种语言中的相同程序可能不易出错。

Answer 3

我建议使用之间的比率：

1. 花费时间修复错误
2. 花费撰写其他代码的时间

这似乎对各种语言都有效......

---

如果您只对某些大代码库进行粗略估计，它也可以工作。您仍然可以将它与您正在编写的新代码进行比较，以给您留下深刻的印象; - ）

Answer 4

测量缺陷并非易事。人们想要考虑代码的复杂性，但这是令人难以置信的混乱和不愉快。在测量代码质量时，我建议：

1. 测量当前状态（现在您的缺陷率是多少）
2. 进行更改（同行评审，培训，代码指南等）
3. 测量新的缺陷率（改进了吗？）
4. 转到2

如果您要比较编码器，请确保比较使用相同语言进行类似工作的编码员。不要将在最复杂计算引擎的深层内部工作的编码器与编写将数据存储在数据库中的代码的编码器进行比较。

我试图确保编码人员知道正在测量的过程不是编码员。这有助于提高指标的质量。

Answer 5

我对所有与LOC相关的测量结果持怀疑态度，不仅仅是因为语言的相对表现力不同，而且因为个别程序员在代码的表现力方面会有足够的变化，因此最好使这个指标“模糊”。

我为项目管理的利益而衡量的是：

• 项目中的开放缺陷数量。没有单个标量可以告诉您项目的位置以及与可释放状态的接近程度，但这仍然是一个方便的数字。随着时间的推移，一边观看。
• 缺陷检测率。这不是将新缺陷引入系统的速度，但它可能是您找到的最接近的代理。
• 缺陷解决率。如果这低于检测率，那么你就会落后 - 如果它更大，你就会领先。

如果将这些数字与严重性信息结合起来，所有这些数字都会更有用。有20个小错误的产品可能比有2个崩溃错误的产品更接近发布。如果您要清除小错误而不是严重错误，则必须让开发人员重新关注他们的注意力。

我会跟踪每个项目和每个开发人员的这些数字。每个项目执行这些数据的原因应该是清楚的。每个开发人员的数字肯定不是个人贡献者的技能或生产力的全貌，但可以指向可能需要培训或补救的人。

您可能还希望按项目模块标记缺陷跟踪系统中的所有故障单（特别是对于较大的项目），这样您就可以判断关键模块何时处于脆弱状态。

Answer 6

为什么不考虑每个用例的缺陷？或每个要求的缺陷。我们在抵达KLOC时遇到了实际问题。