什么是缺陷密度？计算公式与示例
托马斯·汉密尔顿
什么是缺陷密度？
缺陷密度 缺陷率是指在特定运行或开发周期内，软件或模块中已确认的缺陷数量除以该软件或模块的大小。它可以帮助团队判断软件是否可以发布。
缺陷密度以每千行代码 (KLOC) 为单位进行统计。由于该计数已按模块大小进行归一化，因此可以在同一尺度上比较缺陷较多的大型模块和缺陷较少的小型模块，而原始缺陷计数则无法做到这一点。
该指标通常在测试周期结束时报告， tracked release over release，所以它与其余部分并排摆放 缺陷管理流程 ，在 软件测试生命周期.
如何计算缺陷密度
测量缺陷密度的公式：
Defect Density = Defect count/size of the release
版本的大小可以用代码行数 (LOC) 来衡量。
决定最终结果数字是否有意义的三个关键因素：
- 尺寸单位。 LOC 和 KLOC 是最常用的单位。功能点用于团队希望衡量规模而不随编程语言变化的情况，有些团队则会按模块或组件进行标准化。
- 什么才算缺陷？ 只有已确认的缺陷才计入分子。重复项、被拒绝的报告和增强请求必须排除在外，否则数字会膨胀，而代码质量却没有任何变化。
- 测量窗口。 系统测试期间发现的缺陷 回归测试并且，发布后会描述不同的事情，因此必须用数字来表示时期。
缺陷密度示例
假设您的软件产品中集成了 3 个模块。每个模块已发现以下数量的错误：
- 模块 1 = 10 个错误
- 模块 2 = 20 个错误
- 模块 3 = 10 个错误
总共有 10+20+10 = 40 个错误
每个模块的代码总行数为：
- 模块 1 = 1000 行
- 模块 2 = 1500 行
- 模块 3 = 500 行
总线 Code = 1000+1500+500 = 3000
缺陷密度的计算公式为：
Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc
按模块进行相同的计算比合并后的数字更有用，如下表所示：模块 2 在 1500 行代码中存在 20 个缺陷，而模块 3 在仅 500 行代码中存在 10 个缺陷，因此，尽管模块 3 报告的错误较少，但它的密度更高，风险也更大。
缺陷密度标准
缺陷密度没有固定的标准。研究表明， 缺陷 每千行代码量通常被认为是衡量项目质量好坏的标志，而且这个数字是业内引用最广泛的经验法则。
预期会随着领域而变化。安全关键型和受监管软件，例如航空电子设备和医疗设备，其缺陷率目标远低于每千行代码 (KLOC) 一个缺陷，而普通业务应用程序的缺陷率通常高于此目标。由于不同组织采用的计数规则、规模单位和测试深度各不相同，因此，从已发表的研究中提取的基准数据只能与采用相同测量方法的项目进行比较。因此，该指标的实际应用仅限于内部：将当前版本与同一产品的先前版本进行比较，且前一个版本必须采用相同的测量方法。
影响缺陷密度的因素
同一代码库，由于以下因素的影响，可能会产生截然不同的缺陷密度数据：
- Code 复杂。 深度嵌套逻辑和高 圈复杂度 与直接编写的代码相比，每行代码产生的缺陷更多。
- 所考虑的缺陷类型。 仅统计功能性缺陷，还是包括可用性、文档和 非功能性 研究结果大幅改变了分子。
- 所考虑的时间跨度。 两周测试周期内测得的数据与六个月生产使用期间测得的数据不具有可比性。
- 开发和测试技能。 经验丰富的开发人员引入的缺陷较少，而经验丰富的测试人员发现的缺陷更多，因此这两种效应使指标朝着相反的方向发展。
- 测试覆盖率。 从未被发现的缺陷永远不会被统计在内，所以 测试覆盖率 它悄无声息地限制了测量密度的最高值。
缺陷密度与其他缺陷指标
缺陷密度回答了一个问题：已知缺陷的集中程度如何。它无法回答的其他问题，则有三个配套指标可以解答，而且大多数团队会将这些指标一起报告。
| 米制 | 它测量什么 | 它解答的问题 |
| 缺陷密度 | 已确认缺陷按规模（代码行数或功能点）划分 | 哪些模块在同等尺寸下缺陷最多？ |
| 缺陷泄漏 | 发布后发现的缺陷占所有缺陷的比例 | 有多少内容绕过了测试流程，最终到达了用户手中？ |
| 缺陷去除效率 | 发布前已修复的缺陷占所有缺陷的比例 | 测试在及时发现缺陷方面有多有效？ |
| 缺陷严重程度指数 | 缺陷按严重程度加权，而不是同等计数。 | 缺陷的危害程度，而不仅仅是缺陷的数量？ |
综合来看，这四点可以得出更完整的结论：低缺陷密度和高缺陷泄漏点出现在浅层测试中，而不是干净的代码中，这正是下一节警告的误读。
缺陷密度优势
以下是缺陷密度的优势：
- 它有助于衡量测试效果。
- 它有助于区分组件和软件模块之间的缺陷集中情况。
- 它有助于找出需要纠正或改进的地方。
- 它有助于指出高风险组件，这直接影响到 基于风险的测试.
- 它有助于确定各种资源的培训需求。
- 它有助于估算缺陷造成的测试和返工工作量。
- 它可以估算软件中剩余的缺陷。
- 在正式发布之前，它有助于确定目前为止所做的测试是否足够。
- 它建立了一个历史基准，后续版本可以以此为基准进行衡量。
缺陷密度的局限性
该指标计算简便，但也容易被误解。以下限制因素决定了它在版本发布决策中应占多大的权重：
- 未被发现的缺陷是看不见的。 分子只包含测试实际发现的缺陷，因此测试不充分的模块会报告一个粉饰过高的数字。
- 严重程度被忽略。 一个导致支付失败的缺陷和一个外观上的对齐问题，其严重程度是一样的，因此需要结合严重程度加权视图来分析。
- 缺陷的定义各不相同。 即使在同一组织内部，两个团队采用不同的计数方法得出的数据也无法进行比较。
- 代码行数并不能很好地代表规模大小。 冗长的代码会降低密度，却没有任何改进，而且该单位在不同编程语言之间不具有可比性。
- 这个指标是可以被操纵的。 拒绝临界报告或虚增行数都会改善数据，但不会改善产品。
但这并非意味着缺陷密度毫无用处。它只是表明缺陷密度是一个趋势指标，用于衡量单个产品的持续测量结果，而不是用于比较不同团队之间的表现。
如何降低缺陷密度
真正降低缺陷密度（而非纸上谈兵）意味着更早地预防缺陷，并在发布前发现其余缺陷。以下做法在已发布的指南中反复出现：
- 提前进行测试。 在需求和设计阶段引入测试人员，可以在歧义变成代码之前将其发现，而代码阶段的缺陷修复成本最低。
- Rev在合并之前查看新代码。 同行评审可以发现逻辑错误、需求误读和设计缺陷，而这些是其他任何方法都无法实现的。 单元测试 写这篇文章是为了寻找。
- 自动化回归测试套件。 通过运行检查来处理每次提交 持续整合 在编写新代码时，防止旧缺陷再次出现。
- 先编写测试。 测试驱动的开发 强制要求在实现每项行为之前对其进行明确定义，并且 突变测试 然后可以确认测试结果确实证实了某些结论。
- 使用静态分析。 自动代码扫描会在每次测试运行之前标记出空引用解引用、资源泄漏和复杂度热点问题。
- 重构密集模块。 一旦缺陷密度分析确定了最差的组件，将其拆分和简化通常会降低复杂性和缺陷数量。
- 将缺陷反馈到生产过程中。 回顾性分析中的根本原因分析，将单个缺陷转化为流程改进，而不是一次性修补。
Tracked 的发布超过了发布旁边 软件测试技术 结合覆盖率数据，缺陷密度不再是成绩单，而变成了预警系统。
