缺陷积压数量本身不能直接代表风险。判断积压风险，需要把数量放进同一口径，结合老化程度、严重级别结构和清理进展一起看：数量增长且老化加重、高严重级别占比上升、关闭速率低于流入速率时，风险才成立。本文给出一套可复算的指标定义、取数口径与评估步骤，适用于缺陷修复到验证环节的积压判断。
要点总览（TL;DR）
- 缺陷积压数量是规模指标，不能直接等同于风险；判断风险需同时看老化程度、严重级别结构和清理进展。
- 积压规模用未关闭缺陷数及各级别占比衡量；老化程度用停留时长中位数、分位数和超阈值条目占比衡量；清理进展用流入速率、关闭速率和净变化衡量。
- 取数前统一状态范围（待修复、修复中、待验证、已关闭）、项目范围和时间窗，确保跨期与跨项目可比。
- 判断规则按“趋势+结构+老化”组合：净变化持续为正且关闭速率低于流入速率、超阈值占比与高严重级别占比同时上升时，风险较高。
- 积压下降不等于质量提升，阈值是观察线而非达标线；验证环节积压需单独观察，回归测试范围设计另行评估。
评估目标：积压风险要回答哪几个问题
把“积压数量大不大”换成“积压是否正在影响交付与验证”，评估才有决策价值。建议在开始取数前，先明确这次评估要回答的三类问题，并对应到具体决策。
| 问题类别 | 要回答的内容 | 对应决策 |
|---|---|---|
| 积压规模 | 当前未关闭缺陷有多少，按严重级别如何分布 | 是否需要调整排期、预留修复容量 |
| 老化程度 | 缺陷在各个环节停留多久，有多少超过约定时限 | 是否需要加人、调整流转规则或清理长期滞留项 |
| 清理进展 | 新增与关闭的速度对比，净积压是增是减 | 是否需要收紧准入标准、控制新增缺陷流入 |
三类问题分别回答“有多少”“压了多久”“是否在消化”。风险判断最终要落到两个影响上：交付环节是否因缺陷未修复而受阻，验证环节是否因待验证条目堆积而延迟放行。评估结果通常用于三类决策——调整版本排期、增配修复或验证人力、修改缺陷准入与关闭规则。只回答“有多少条”无法支撑这些决策。
指标与范围：积压规模、老化与清理进展怎么定义
指标要能复算，就必须写清分子、分母、时间窗和单位。下表给出一组可直接套用的定义，团队可按自身版本节奏调整时间窗。
| 指标 | 公式 | 分子 / 分母 | 时间窗 | 单位 |
|---|---|---|---|---|
| 未关闭缺陷数 | 统计时点处于未关闭状态的缺陷条目数 | 未关闭条目 / 不适用 | 统计时点快照 | 条 |
| 严重级别结构 | 各严重级别未关闭数 ÷ 未关闭总数 | 某级别未关闭数 / 未关闭总数 | 统计时点快照 | 百分比 |
| 停留时长中位数 | 未关闭缺陷从创建到统计时点的时长中位数 | 不适用 | 统计时点快照 | 天 |
| 超阈值条目占比 | 停留时长超过阈值的未关闭数 ÷ 未关闭总数 | 超阈值条目 / 未关闭总数 | 统计时点快照 | 百分比 |
| 流入速率 | 时间窗内新建缺陷数 ÷ 时间窗天数 | 新建数 / 天数 | 近N天或近N个迭代 | 条/天 |
| 关闭速率 | 时间窗内关闭缺陷数 ÷ 时间窗天数 | 关闭数 / 天数 | 与流入同窗口 | 条/天 |
| 净变化 | 流入数 − 关闭数 | 不适用 | 与流入同窗口 | 条 |
范围界定需要同时固定三件事。第一是状态范围：明确哪些状态计入“未关闭”，通常包括待修复、修复中、待验证，已关闭不计入。第二是项目范围：跨项目汇总时，各项目的严重级别定义要一致，否则结构指标失真。第三是时间窗：流入与关闭必须取同一窗口，窗口长度建议覆盖至少一个完整迭代，避免版本发布前后的波动被误读为趋势。老化阈值没有通用标准，应结合团队历史停留时长分布和版本节奏自行设定，例如取历史中位数的若干倍作为观察线。
数据口径与证据：清单字段怎么取才可比
指标算得对不对，取决于清单字段取得是否一致。取数前先核对必要字段是否齐全：创建时间、每次状态变更时间、严重级别、关闭时间、验证通过时间。缺少状态变更时间，就无法计算各环节停留时长；缺少验证时间，就无法区分“修复完成”和“验证通过”。
状态口径要统一。不同项目对“待修复、修复中、待验证、已关闭”的命名和边界可能不同，汇总前应建立一张映射表，把各项目状态归并到统一分类。特别要区分“已修复待验证”和“已关闭”：前者仍占用验证资源，属于积压的一部分。
- 分母为零：某时间窗内没有新建缺陷时，流入速率为零，占比类指标无意义，应标注“样本不足”而非填零。
- 样本过少：条目数很少时，占比波动会被放大，建议同时给出绝对数，避免仅凭百分比下结论。
- 数据缺失：状态变更时间缺失的条目单独列出，不纳入停留时长计算，并在结论中说明缺失比例。
- 跨项目不可比：严重级别定义、状态模型、迭代节奏不同的项目，先分别计算再比较趋势，不直接合并成一个总数。
在工具层面，缺陷清单的字段记录、状态流转与统计视图需要有稳定的承载。ONES 测试管理解决方案覆盖缺陷管理，缺陷可关联至迭代；ONES Project 支持缺陷跟踪，与 TestCase 数据互通，可一键提交 Bug 并统计缺陷状态分布，也支持自定义数据范围和维度的报表。这些能力可以支撑上述字段与状态口径的落地，具体字段配置以团队实际设置为准。
计算与评估步骤：从清单到风险判断
拿到清单后，按以下步骤计算，再把三类结果合成判断。
- 固定口径。确定统计时点、状态范围、项目范围和时间窗，导出对应清单。
- 统计规模。计算未关闭缺陷总数，并按严重级别分层，得到各级别占比。
- 计算老化。对每条未关闭缺陷计算停留时长，输出中位数、分位数和超阈值条目占比；待验证状态单独统计一份。
- 计算清理进展。在同一时间窗内统计流入数、关闭数和净变化，换算为条/天。
- 看趋势。把连续若干周期的净变化连起来看，判断积压是在扩大、持平还是收敛。
- 合成判断。按“趋势 + 结构 + 老化”组合下结论，单一指标异常不直接定性。
判断规则可参考以下组合，阈值需结合历史基线自定：
| 观察组合 | 风险判断 |
|---|---|
| 净变化持续为正，关闭速率低于流入速率 | 积压在扩大，需关注清理能力 |
| 超阈值条目占比上升，高严重级别占比同时上升 | 老化与结构双重恶化，风险较高 |
| 数量大但关闭速率高于流入速率，老化时长短 | 流转正常，规模本身不构成高风险 |
| 数量小但长期滞留条目集中，待验证积压明显 | 存在隐性风险，验证环节可能成为瓶颈 |
严重级别加权时，可给高严重级别更高权重再计算结构变化，观察权重后的积压是否比条目数增长更快。待验证条目数和其停留时长应单独观察，修复完成不等于风险解除，验证环节的积压会直接推迟放行。
例子：两组积压数据的风险判断对比
以下数据为演示用，非实测，仅用于说明数量相近时风险判断的差异。
| 指标 | 示例A | 示例B |
|---|---|---|
| 未关闭缺陷数 | 120条 | 100条 |
| 高严重级别占比 | 10% | 35%，且较上期上升 |
| 停留时长中位数 | 4天 | 21天 |
| 超阈值条目占比 | 8% | 45% |
| 流入速率 | 6条/天 | 3条/天 |
| 关闭速率 | 7条/天 | 2条/天 |
| 净变化（近30天） | −30条 | +30条 |
| 待验证积压 | 少，停留短 | 多，停留长 |
示例A数量更多，但关闭速率高于流入速率，净变化为负，老化时长短，说明团队在持续消化，规模大主要反映版本前期集中提交，风险判断为可控。示例B数量较少，但高严重级别占比高且上升，停留时长中位数达21天，近半数条目超阈值，关闭速率低于流入速率，待验证环节也在堆积，风险判断为偏高，需要优先处理长期滞留项和验证瓶颈。两组数据说明，积压数量与风险之间没有单调对应关系，必须结合老化、结构和清理进展一起读。
解读与限制：哪些结论不能从积压数量推出
积压指标适合描述状态和趋势，不适合单独作为质量结论或绩效结论。使用时注意以下边界。
- 数量与风险非单调。数量大可能对应高流转，数量小可能对应长期滞留，单看条目数会误判。
- 指标受外部节奏影响。需求集中提交、版本发布、节假日都会改变流入和关闭速率，比较时应选取可比窗口。
- 积压下降不等于质量提升。关闭速率上升可能来自集中清理或降低准入，需结合缺陷来源和严重级别结构判断。
- 验证环节积压有其边界。本文只讨论待验证条目对积压风险的影响，回归测试范围设计、测试用例覆盖等属于回归测试管理的内容，需另行评估。
- 阈值是观察线而非达标线。超阈值占比上升提示需要排查，不能直接等同于不合格。
把上述指标固化为周期性统计视图，可以让每次评估使用同一口径。ONES Project 提供多种图表形态实时呈现项目表现，并支持自定义数据范围和维度，ONES 测试管理可为测试活动生成多维度测试报告，适合承载积压规模、状态分布和趋势的定期回顾；老化时长与流入关闭速率的直接统计仍需按团队配置核对。评估结论建议与修复排期、验证资源安排一起评审，让指标真正服务于交付决策。
常见问题
缺陷积压数量下降，是否说明积压风险已经解除？
不一定。数量下降可能来自集中清理、降低准入标准或需求提交减少，需要结合关闭速率、缺陷来源和严重级别结构判断。如果关闭速率上升主要来自低严重级别条目，而高严重级别占比和老化时长没有改善，风险可能仍然存在。建议同时观察净变化趋势、超阈值条目占比和待验证积压，确认下降是持续消化还是短期波动。
团队没有历史基线，老化阈值怎么设定？
可以先取团队近几个迭代的停留时长分布，以中位数或某个分位数作为初始观察线，再根据版本节奏调整。例如版本周期为两周时，停留时长超过一个迭代的条目可先标记为观察对象。阈值的作用是提示排查，不是考核达标。运行一段时间后，结合误报和漏报情况修正阈值，逐步形成适合团队的历史基线。
待验证状态的缺陷应该计入积压吗？
应该计入。待验证条目仍占用验证资源，且会推迟放行，属于积压的一部分。评估时建议把待验证条目数和其停留时长单独统计一份，与待修复、修复中条目区分观察。修复完成不等于风险解除，验证环节堆积明显时，即使修复侧数量下降，整体风险也可能偏高。
跨项目汇总缺陷积压数据时，最容易出现什么问题？
最常见的问题是状态定义和严重级别定义不一致。不同项目对“待修复、修复中、待验证、已关闭”的边界可能不同，直接合并总数会让结构指标失真。建议先建立状态映射表，把各项目状态归并到统一分类；严重级别定义差异较大时，先分别计算趋势再比较，不直接合并成一个总数。迭代节奏不同的项目，时间窗也应分别选取可比区间。
用积压指标评估团队绩效是否合适？
不建议单独使用。积压数量受需求波动、版本节奏和准入标准影响，关闭速率也可能因集中清理而短期上升。把积压指标直接用于绩效，容易诱导降低准入或拆分条目等行为，反而掩盖真实风险。更合适的做法是把积压指标用于交付决策和过程改进，例如调整排期、增配验证人力或修改流转规则，并与缺陷来源、严重级别结构一起解读。
