用缺陷积压清单衡量积压规模，关键在把清单从条目列表转成可复算的度量口径：先固定统计范围，再按时间窗计算积压总量、按严重级别加权的积压规模、账龄分布与老化率，以及净清理速度。本文围绕数量、严重程度、老化与清理进展三个方向，给出纳入规则、指标公式、按周取数步骤和一份完整计算示例，并说明条目数量与积压风险之间的关系。
要点总览（TL;DR）
- 积压规模要先固定统计口径：明确哪些状态、严重级别和模块计入积压，排除重复单、已关闭和明确不修复的条目，保证每个周期可复算。
- 核心指标覆盖三个方向：积压总量看数量，加权积压规模看严重程度，账龄分布与老化率看积压时长，净清理速度看清理进展。
- 按周固定快照时点取数，与上一周期对比看趋势，阈值以团队自身历史基线设定，不套用外部通用达标线。
- 条目数量只反映数量维度，需结合加权规模、老化率和净清理速度联合判断；条目数下降但加权规模上升，说明积压风险实际在上升。
- 度量结果适合用于排期、资源调配和风险预警，清单质量依赖状态流转及时更新，脏数据会扭曲账龄与清理速度的解读。
评估目标：积压规模要回答哪三个问题
积压规模度量要回答三个问题：有多少、有多严重、积压多久。三个问题对应三类指标，缺一类就可能误判。只回答“有多少”，会把一个高严重级别的长期未修缺陷和一个低优先级的体验问题算成同等负担；只回答“有多严重”，会忽略积压是否在持续扩大。
三类问题的具体指向如下：
- 有多少：统计时点上的积压条目总数，反映待处理工作量。
- 有多严重：按严重级别加权后的积压规模，反映积压对交付质量的实际压力。
- 积压多久：账龄分布与老化率，反映积压是否在沉淀为长期问题。
度量结果服务于三类决策：排期时判断是否需要为缺陷修复预留容量；资源调配时判断是否要把人力从新功能转向存量缺陷；风险预警时判断当前积压是否已偏离团队历史常态。度量本身不解决变更后的整体回归测试管理，也不涉及具体代码修复方法，这两部分属于其他工作范围。
指标与范围：清单里哪些条目算积压
积压条目需要先定义纳入与排除规则，否则不同人导出的清单口径不同，指标无法复算。建议把规则写成一张纳入规则表，固定状态集合、分组维度、时间窗和排除项。
状态集合的取舍
积压通常指“已提交但尚未关闭”的缺陷。状态集合一般包含已提交、待修复、修复中、待验证、验证未通过等未关闭状态。是否把“待验证”计入积压，取决于团队对积压的定义：若积压指“尚未完成修复动作”，待验证可排除；若积压指“尚未关闭的未完成项”，待验证应计入。两种口径都可以用，但必须在规则表中写明，并在多个周期之间保持一致。
分组维度与时间窗
分组维度建议至少保留严重级别、所属模块和缺陷来源。严重级别用于加权，模块用于定位集中区域，来源用于区分测试发现、线上反馈等渠道。时间窗决定快照时点，建议按周固定取数，例如每周一上午导出上周最后一个工作日的清单快照，保证相邻周期的数据可比。
排除项的处理
| 条目类型 | 处理方式 | 理由 |
|---|---|---|
| 重复单 | 合并到主单后排除 | 重复计数会虚增积压规模 |
| 已关闭条目 | 排除 | 已不属于积压 |
| 明确不修复的条目 | 标记后排除，并在规则表注明 | 不构成待处理工作量，但需保留记录以便回溯 |
| 需求类或任务类条目 | 排除 | 不属于缺陷范畴 |
排除项一旦确定，应在每个周期沿用同一规则。若中途调整规则，需要在趋势对比时标注口径变更点，避免把口径变化误读为积压变化。
数据口径：从清单字段到可计算指标
指标可复算的前提是清单字段完整。每条缺陷至少需要创建时间、当前状态、严重级别、关闭时间、验证时间五个字段。缺失严重级别或时间字段的条目，应单独归集为“未分级”或“时间缺失”组，不直接丢弃，也不默认填入某个级别。
核心指标与公式
| 指标 | 公式 | 单位 | 说明 |
|---|---|---|---|
| 积压总量 | 快照时点未关闭且符合纳入规则的条目数 | 条 | 数量维度 |
| 加权积压规模 | Σ（条目严重级别权重 × 1） | 权重分 | 严重程度维度，权重由团队自定，如致命5、严重3、一般1、轻微0.5 |
| 账龄 | 快照日期 − 创建日期 | 天 | 逐条计算后汇总为分布 |
| 老化率 | 账龄超过阈值的条目数 ÷ 积压总量 × 100% | % | 阈值取团队历史基线，如30天或60天 |
| 净清理速度 | 当期关闭数 − 当期新增数 | 条/周 | 正值表示积压在收敛，负值表示在扩大 |
净清理速度也可以用“当期关闭数 ÷ 当期新增数”表达为比值，大于1表示清理快于流入。两种表达都要求固定统计周期和快照时点，保证分子分母来自同一时间窗。
分母为零与缺失值的处理
当期无新增时，关闭数除以新增数的比值无意义，应改用净清理速度的差值形式，或标注“当期无新增，比值不适用”。当期无关闭时，净清理速度为负的新增数，老化率仍可正常计算。严重级别缺失的条目计入积压总量，但不参与加权规模计算，同时在报告中单列“未分级条目数”，提示数据质量问题。创建时间缺失的条目无法计算账龄，应归入“账龄未知”组并单独披露。
计算与评估步骤：按周取数与趋势判断
建议把度量做成每周固定执行的动作，流程如下：
- 固定快照时点导出清单：按纳入规则筛选状态集合，导出包含必备字段的条目，按条目编号去重，合并重复单。
- 计算当期指标：按上节公式算出积压总量、加权积压规模、账龄分布、老化率和净清理速度，并记录未分级与账龄未知条目数。
- 与上一周期对比：把各指标与上周、上月同期并列，观察变化方向和幅度，而不是只看单点数值。
- 判断趋势：连续多个周期加权规模上升、老化率上升，说明积压在扩大且沉淀；加权规模下降但老化率上升，说明新缺陷流入减少而旧缺陷未清理。
- 设定观察阈值：以团队自身历史数据为基线，例如取过去12周的加权规模中位数，超过一定幅度时触发预警。阈值随团队规模与发布节奏调整，不套用外部通用达标线。
取数与状态流转的及时更新直接决定指标可信度。缺陷从提交到修复、验证、关闭的状态变化需要被完整记录，账龄和关闭时间才有依据。在 ONES 测试管理中，缺陷可关联至迭代进行全生命周期跟踪，支持一键创建并关联缺陷，团队围绕缺陷协作处理；ONES Project 支持一键提交 Bug 至对应项目或迭代，并统计缺陷状态分布。这些能力承载了状态流转和字段记录，使按周导出清单、计算账龄具备数据基础。具体字段配置与报表形式需在实际环境中确认。
例子：一份缺陷积压清单的完整计算
以下为演示数据，用于说明公式代入与结果解读，不代表任何真实团队。
示例清单概况
| 严重级别 | 权重 | 条目数 | 其中账龄>30天 |
|---|---|---|---|
| 致命 | 5 | 2 | 1 |
| 严重 | 3 | 6 | 4 |
| 一般 | 1 | 20 | 5 |
| 轻微 | 0.5 | 12 | 2 |
| 未分级 | — | 2 | 1 |
积压总量为 2+6+20+12+2 = 42 条。加权积压规模为 2×5 + 6×3 + 20×1 + 12×0.5 = 10+18+20+6 = 54 权重分，未分级条目不计入加权。账龄超过30天的条目共 1+4+5+2+1 = 13 条，老化率为 13÷42 ≈ 31.0%。
两周对比与解读
假设上一周积压总量为 45 条、加权规模为 50 权重分、老化率为 28%。本周总量降至 42 条，加权规模升至 54 权重分，老化率升至 31%。条目数下降但加权规模上升，说明关闭的多是低级别缺陷，而严重级别缺陷在累积，积压风险实际在上升。若同期净清理速度为 −3 条/周，即新增多于关闭，则进一步印证积压在扩大。
反过来，若某周积压总量持平、加权规模下降、净清理速度为 +2 条/周，说明团队在优先清理高严重级别缺陷，积压结构在改善。净清理速度为正负两种情形下，结论方向相反，必须结合加权规模与老化率一起读。
解读与限制：条目数量与积压风险的关系
条目数量只反映数量维度。42 条积压和 42 条积压可能对应完全不同的风险：前者以轻微问题为主且账龄短，后者包含多个致命缺陷且长期未修。因此条目数适合作为规模的基础描述，判断风险时需要联合加权规模、老化率和净清理速度。
建议的联合判断规则如下：
- 加权规模与老化率同时上升：积压在扩大且沉淀，优先安排高严重级别缺陷的修复容量。
- 条目数下降但加权规模上升：低级别清理有效，高级别流入未受控，需检查严重级别缺陷的来源与修复排期。
- 净清理速度持续为负：流入大于流出，需评估新增缺陷是否集中在某模块或某次发布。
- 老化率高位但净清理速度转正：积压开始收敛，继续观察两到三个周期确认趋势。
这套指标与交付质量、发布节奏之间是相关观察，不能当作因果保证。积压下降不必然意味着质量提升，也可能来自测试覆盖收缩或缺陷记录减少。清单质量依赖状态流转的及时更新，长期不关闭、不验证的条目会扭曲账龄和净清理速度，脏数据需要先治理再解读。度量结果适合用于排期、资源调配和风险预警等改进动作，作为个人绩效的唯一依据会诱导条目操作，反而破坏数据可信度。
在工具承载上，ONES 测试管理可为测试活动生成多维度测试报告并提供报告模板，ONES Project 提供多种图表形态呈现项目表现并支持自定义数据范围和维度，可用于按周查看缺陷状态分布与趋势。积压清单、账龄字段和积压趋势报表是否以现成形式提供，需结合具体版本与配置在实际环境中核验。
常见问题
积压清单里的“待验证”缺陷要不要计入积压规模？
取决于团队对积压的定义，两种口径都可用，但要在规则表中写明并在各周期保持一致。
- 若积压指“尚未完成修复动作”，待验证条目可排除，因为修复已提交。
- 若积压指“尚未关闭的未完成项”，待验证应计入，因为缺陷仍未闭环。
中途切换口径时，需要在趋势对比中标注变更点，避免把口径变化误读为积压变化。
当期没有新增缺陷时，净清理速度和老化率还能算吗？
可以算，但表达方式要调整。当期无新增时，“关闭数÷新增数”的比值无意义，应改用差值形式（关闭数减新增数），或标注“当期无新增，比值不适用”。老化率不依赖新增数，按账龄超过阈值的条目数除以积压总量照常计算。当期无关闭时，净清理速度为负的新增数，同样可以正常解读。
严重级别或创建时间字段缺失的条目怎么处理？
不建议直接丢弃，也不建议默认填入某个级别。严重级别缺失的条目计入积压总量，但不参与加权规模计算，报告中单列“未分级条目数”提示数据质量。创建时间缺失的条目无法计算账龄，归入“账龄未知”组单独披露。两类缺失条目都应推动在源头补录，否则会持续影响指标可信度。
积压指标下降是否说明交付质量在改善？
两者之间是相关观察，不能当作因果保证。积压下降可能来自修复效率提升，也可能来自测试覆盖收缩、缺陷记录减少或口径调整。判断质量变化需要结合缺陷发现率、验证通过率等指标一起看。积压度量的价值在于提示排期和资源调配的方向，不宜单独作为质量结论或个人绩效的唯一依据。
团队刚开始做积压度量，阈值应该怎么定？
建议先用四到十二周的数据积累自身基线，例如取过去十二周加权积压规模的中位数，再设定触发预警的偏离幅度。阈值随团队规模、发布节奏和缺陷来源结构变化而调整，外部通用达标线参考价值有限。起步阶段可以先只跟踪趋势方向，等数据稳定后再引入阈值判断。
