缺陷密度与趋势
缺陷密度等于缺陷数除以规模，规模常用千行代码或功能点，用密度而非总数可以横向比较不同大小的模块。比绝对值更重要的是趋势：新版本的缺陷率是否下降、回归缺陷在总量中的占比是否收敛、修复时长的分布是否向短侧移动。数据来源必须是缺陷跟踪系统并按版本打标签，靠印象统计无法支撑任何决策。
口径与数据源
| 密度口径 | 缺陷数除以千行代码，或缺陷数除以功能点 |
|---|---|
| 关注点 | 趋势、回归缺陷占比、修复时长分布 |
| 数据源 | 缺陷跟踪系统，按模块与版本标签聚合 |
| 前提 | 缺陷定义与规模口径在多期之间保持一致 |
典型使用场景
- 版本复盘：对比相邻版本的新增缺陷率与回归缺陷比例，判断质量投入是否有效
- 定位薄弱模块：按模块看缺陷贡献，把测试与评审资源投向长尾集中处
- 判断重构收益：重构前后对同模块的缺陷密度做对比，作为偿还验收依据
- 发布前风险评估：统计当前版本未关闭缺陷的严重度分布，决定是否放行
- 测试策略调整：按缺陷引入阶段分类，判断是需求澄清不足还是测试覆盖不足
分析切面读法
| 切面 | 看什么 | 异常信号 |
|---|---|---|
| 按模块 | 哪几个模块贡献了多数缺陷 | 少数模块占比过高，说明设计或知识集中 |
| 按阶段 | 需求、设计、编码、测试各阶段漏出的比例 | 编码阶段占比过高，通常是需求或设计未澄清 |
| 按版本 | 新增缺陷与修复引入的新缺陷 | 回归占比上升，说明修复缺少回归用例 |
| 按时长 | 从发现到关闭的耗时分布 | 长尾拉长，说明优先级或复现成本有问题 |
| 按来源 | 客户报障与内部发现的比例 | 外部占比高，说明测试未覆盖真实使用路径 |
横向比较的前提是模块类型、复杂度与统计口径一致：把基础库与业务编排模块放在同一张表里比密度，结论通常不可用。跨团队对比前先统一缺陷定义、规模口径与统计窗口。
缺陷数一旦被用于个人考核，数据立刻失真：缺陷会被拆条、改写严重度或延迟登记。指标应服务于流程改进与资源投放，而不是用来评价个人。
落地检查清单
- 统计窗口、版本标签与规模口径在报告里写明
- 分母明确：统计的是全部代码还是本期变更
- 把回归缺陷单列一类，不与新功能缺陷混算
- 每期报告附一句变化归因，而不是只给数字