如何用缺陷积压清单衡量积压规模

2026年11月13日

用缺陷积压清单衡量积压规模，关键是把清单条目数转成可复算的指标：先固定哪些状态算积压、哪些缺陷算未关闭，再固定快照时点与分母口径，然后计算积压总量、积压率、老化分布和清理速度。条目数只反映存量，配合停留时长与清理进展，才能判断积压是在扩大还是收敛。

Table of Contents

要点总览（TL;DR）

积压规模要同时看三个维度：存量规模（积压总量）、老化程度（停留时长分布）、清理进展（清理速度与净变化），只看清单条目数会误判风险。
统计前先固定口径：纳入积压的状态集合（新建、已确认、修复中、待验证）、快照时点、统计周期与分母，跨项目合并时先按缺陷唯一标识去重。
核心公式：积压率 = 积压条数 ÷ 周期内新增缺陷数 × 100%，分母为零记“不适用”；清理速度 = 周期内转终态条数 ÷ 周期天数；净变化为正说明积压在扩大。
老化按停留时长分档统计条数与占比，分档边界结合发布节奏设定；所有指标按严重级别分层输出，避免高等级缺陷被总量掩盖。
阈值不设通用达标线，应结合团队历史数据与发布节奏确定；状态机或级别定义变更后需重新建立基线，新旧数据不宜直接比较趋势。

评估目标：积压规模要回答哪三个问题

积压规模评估要回答三个问题：存量有多大、积压停留了多久、清理是否跟得上新增。三个维度分别对应存量规模、老化程度和清理进展，缺一项都可能得出错误结论。

存量规模回答“现在有多少条缺陷处于未关闭状态”，它是最直观的数字，也是排期讨论中最常被引用的数字。老化程度回答“这些缺陷已经等了多久”，同样是100条积压，集中在最近一周和集中在三个月以上，对发布节奏的影响完全不同。清理进展回答“团队每周能消化多少、新增是否超过消化”，它决定积压是在收敛还是继续扩大。

只看清单条目数不足以判断风险，原因有三点。第一，条目数不区分严重级别，高等级缺陷与低优先级建议混在一起统计，会掩盖真正需要优先处理的部分。第二，条目数不反映时间结构，长期滞留的缺陷往往意味着定位困难、依赖外部条件或责任不清，这些信息在总数里看不到。第三，条目数是静态快照，无法说明趋势，本周100条与上周80条、下周120条代表的风险方向完全不同。

评估结论最终要能支撑三类决策：排期上是否需要为缺陷清理预留容量，资源上是否需要补充验证或开发人力，流程上是否需要调整缺陷准入标准或状态流转规则。因此指标设计应围绕这三个用途展开，避免产出无法落地的统计数字。

指标与范围：哪些缺陷算进积压清单

积压清单的统计范围需要事先写清楚，否则每周取数时口径漂移，指标之间无法比较。范围规则至少覆盖状态、级别、时间窗和归属四个方面。

状态口径

纳入积压的状态通常是尚未完成修复与验证的中间状态，例如新建、已确认、修复中、待验证。排除的状态包括已关闭、已拒绝、重复、无法复现等终态。需要特别处理的是“待验证”：缺陷已修复但尚未通过验证，仍占用团队注意力，一般应计入积压，并在分层统计中单独标注，便于区分开发侧积压与验证侧积压。

级别与模块分层

按严重级别分层统计是必要动作。建议至少区分致命/严重、一般、轻微三档，分别计算总量与老化。按模块或团队分层用于定位积压集中位置，例如某模块长期积压可能提示设计缺陷或测试覆盖不足。分层口径一旦确定，后续周期保持一致。

时间窗与快照时点

积压总量是时点指标，必须指定快照时点，例如每周五18点或每个迭代结束日。积压率、清理速度是周期指标，需要指定统计周期，例如自然周或迭代周期。快照时点与统计周期应固定下来，避免因取数时间不同造成波动。

合并与去重规则

跨团队或跨项目合并清单时，先按缺陷唯一标识去重，再按归属团队或模块拆分统计。同一缺陷在多个项目中关联的情况，应约定唯一归属方，通常以缺陷创建所在项目或责任团队为准。归属规则不明确时，合并后的总量会虚高。

维度	纳入规则	排除规则	注意事项
状态	新建、已确认、修复中、待验证	已关闭、已拒绝、重复、无法复现	待验证单独标注，区分开发与验证积压
严重级别	全部级别，分层统计	无	级别定义需全团队一致
时间窗	固定快照时点，固定统计周期	临时取数不计入趋势对比	快照时点写入统计说明
归属	按唯一归属团队或模块	重复关联条目去重	跨项目合并前先约定归属方

数据口径：清单字段与取数要求

从缺陷积压清单取数，需要每个字段有明确口径。字段定义不清，公式再正确也无法复算。下表列出计算积压规模所需的关键字段。

字段	口径定义	单位	缺失处理
缺陷ID	缺陷唯一标识，用于去重与追溯	—	缺失则该条不纳入统计
当前状态	快照时点的状态值	—	状态为空按未确认处理并标注
严重级别	按团队统一级别定义取值	—	缺失归入“未分级”，单独统计
创建时间	缺陷首次提交时间	日期时间	缺失则该条不计入新增分母
进入积压状态时间	首次进入纳入状态集合的时间	日期时间	缺失时以创建时间替代并标注
关闭时间	进入终态的时间	日期时间	未关闭为空，不参与清理速度计算
验证时间	验证通过的时间	日期时间	缺失时以关闭时间替代并标注
所属模块/团队	缺陷归属的模块或责任团队	—	缺失归入“未分配”，单独统计

分母定义需要单独说明。积压率的分母是统计周期内新增缺陷数，即创建时间落在该周期内的缺陷条数，与期末积压条数不是同一批数据。清理速度的分母是周期天数。老化指标不需要分母，但需要分档边界。

缺失值处理遵循“可追溯”原则：能用替代值计算的，替代后在统计说明中标注；不能替代的，单独归入未分类并披露条数。状态回退是常见情况，缺陷从待验证退回修复中，进入积压状态时间应保留首次进入时间，不因回退重置，否则老化时长会被低估。跨周期未关闭的条目在每个快照中都计入积压总量，其停留时长持续累加。

数据可比的前提是同一状态机、同一级别定义、同一时间窗。状态机调整、级别定义变更或统计周期改变后，新旧数据不宜直接比较趋势，应在变更点做标注，必要时重新建立基线。

计算步骤：从清单到积压规模指标

以下四组指标按顺序计算，每组都给出公式、单位和适用条件。所有指标建议按严重级别分层输出。

第一步：积压总量

积压总量 = 快照时点处于纳入状态集合的缺陷条数，单位：条。按级别分层时，分别统计各等级条数，并给出合计。这是时点指标，不同快照之间可直接比较大小。

第二步：积压率

积压率 = 积压条数 ÷ 统计周期内新增缺陷数 × 100%。分子取期末快照的积压条数，分母取该周期内创建的缺陷条数。分母为零时，该指标记为“不适用”，不写0%，避免被误读为没有积压。积压率大于100%说明期末积压超过本期新增，存量在累积；小于100%说明本期清理量超过了新增量的一部分。

第三步：老化分布

停留时长 = 快照时点 − 进入积压状态时间，单位：天。按分档统计各档条数与占比，分档示例为7天以内、8至30天、31至90天、90天以上。分档边界应结合团队发布节奏设定，发布周期短的团队可把第一档压缩到3天。老化占比 = 某档条数 ÷ 积压总量 × 100%。

第四步：清理速度与净变化

清理速度 = 统计周期内从积压状态转为关闭或已验证的条数 ÷ 周期天数，单位：条/天。净变化 = 本期新增积压条数 − 本期清理条数，单位：条。净变化为正说明积压在扩大，为负说明在收敛。清理速度与净变化需结合看：清理速度高但新增更高，积压仍在扩大。

指标	公式	单位	条件说明
积压总量	快照时点纳入状态的缺陷条数	条	时点指标，按级别分层
积压率	积压条数 ÷ 周期新增缺陷数 × 100%	%	分母为零记“不适用”
老化占比	某档条数 ÷ 积压总量 × 100%	%	分档边界按发布节奏设定
清理速度	周期内转终态条数 ÷ 周期天数	条/天	转终态含关闭与已验证
净变化	本期新增积压 − 本期清理条数	条	正值表示积压扩大

分层计算是必要步骤。总量持平时，严重级别缺陷可能正在增加，轻微缺陷在减少，合并统计会掩盖这一变化。建议每个指标都输出“合计+分级”两行数据。

例子：一份积压清单的规模测算

以下数据为演示用途，仅说明计算过程，不代表任何真实团队基线。

某团队以自然周为统计周期，期末快照积压120条，期初积压100条，本周新增缺陷40条，本周从积压转为关闭或已验证的缺陷25条。按停留时长分档：7天以内50条，8至30天40条，31至90天20条，90天以上10条。

积压率 = 120 ÷ 40 × 100% = 300%。这个数字说明期末积压是本周期新增的三倍，存量远大于单周流入量。老化占比分别为：7天以内41.7%，8至30天33.3%，31至90天16.7%，90天以上8.3%。清理速度 = 25 ÷ 7 ≈ 3.6条/天。净变化 = 40 − 25 = 15条，为正，说明本周积压在扩大。

解读这份结果：积压规模在扩大，净增15条，清理速度约3.6条/天，按此速度消化新增需要约11天，尚未考虑存量。老化结构上，超过30天的条目合计30条，占25%，这部分缺陷滞留时间较长，应优先排查是否存在定位困难或责任不清的问题。90天以上的10条需要单独审视，判断是否应关闭、降级或重新排期。若严重级别分层后显示高等级缺陷集中在31天以上档，则风险信号更强，应优先安排处理。

这个例子也说明单看条目数会误判：期初100条、期末120条，增幅20%，看似温和，但净变化为正且清理速度低于新增速度，积压实际在持续累积。

解读与限制：条目数量与积压风险的关系

清单条目数与积压风险不是线性关系。同样100条积压，如果80%在7天以内，说明流转正常，只是当期流入较多；如果40%超过30天，说明存在结构性滞留，风险明显更高。判断风险应同时看总量、老化结构和净变化方向。

积压率与清理速度需要结合看。积压率高但清理速度也在上升，可能是短期集中提测造成的波动；积压率不高但净变化连续多周期为正，说明积压在缓慢累积，同样需要干预。单看任何一个指标都容易得出片面结论。

指标不能直接当作质量因果结论。积压增加可能来自需求变更、测试范围扩大、人员变动或缺陷准入标准放宽，指标只反映现象，归因需要结合严重级别分布、业务影响和流程变更记录。把积压条数直接等同于质量下降，会误导改进方向。

数据不可比的情况需要提前识别：分母为零时积压率不适用；统计范围变更后新旧数据不宜直接比较趋势；状态机调整会改变进入积压状态的时间口径，导致老化时长跳变；级别定义调整会影响分层结果。出现这些情况时，应在变更点重新建立基线，并在报表中标注口径版本。

阈值不设通用达标线。积压总量控制在多少、老化占比多少算健康，取决于团队发布节奏、缺陷流入规模和验证人力，应结合自身历史数据确定参考区间，并按迭代或季度复核。指标用于发现趋势和定位问题，不宜直接作为个人或团队的考核依据。

在工具承载上，缺陷积压清单的字段、状态和统计需要稳定的数据基础。ONES 测试管理提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代；ONES Project 支持缺陷跟踪管理与质量统计，可统计缺陷状态分布，并提供多种图表形态和自定义数据范围与维度。团队可据此按上述口径组织缺陷清单、按周期取快照并输出分层统计。停留时长分档、快照机制与自定义分母的具体实现方式，需以实际产品配置为准。