缺陷积压清单怎么按状态、优先级和滞留时长分组

缺陷积压清单要同时回答三个问题：哪些缺陷还没关闭、哪些更该先处理、哪些已经停留过久。做法是先固定一组基础字段，再按“状态→优先级→滞留时长”三层分组，其中滞留时长以最近一次状态变更日期为基准计算。这样分组后，清单既能反映修复进度，也能把长期滞留的缺陷筛出来进入清理流程。

要点总览（TL;DR）

• 清单先固定缺陷编号、标题、所属模块、发现版本、当前状态、最近状态变更日期、验证人、优先级、严重程度、责任人、发现日期、计划关闭日期等字段，滞留时长由公式计算。
• 分组按“状态→优先级→滞留时长”三层叠加：先按状态分桶，再在每个状态内按 P0–P3 排列，最后按 0–3 天、4–7 天、8–14 天、15–30 天、30 天以上分档。
• 滞留时长以最近状态变更日期为基准，阈值按状态分别设定，待确认、修复中、待验证各环节的合理停留时间不同。
• 待清理缺陷的判定条件是状态未关闭且滞留超过该状态阈值，排序先看优先级再看滞留时长，验证不通过退回的缺陷单独标记并重新计时。
• 清单按周刷新和清理，缺陷提交人、修复责任人、测试验证人、缺陷管理负责人和项目负责人各司其职，刷新后按核对表逐项检查再用于清理会议。

清单先定字段：一条缺陷要记录哪些信息

三层分组能否顺利执行，取决于字段是否齐全、口径是否统一。建议在清单中固定以下字段，字段名和取值方式一旦确定，就写入清单说明，避免不同人按各自习惯填写。

字段名	取值说明	是否必填	用途
缺陷编号	系统生成的唯一编号，如 BUG-1024	必填	唯一标识，便于引用和追溯
标题	一句话描述现象与影响，如“订单列表翻页后筛选条件丢失”	必填	快速识别缺陷内容
所属模块	按产品功能模块填写，如订单、支付、用户中心	必填	定位问题范围，便于分派
发现版本	发现缺陷时的版本号或迭代标识	必填	判断影响范围与回归范围
当前状态	从约定的状态集合中选择，如待确认、已确认待修复、修复中、待验证、验证不通过退回、已关闭	必填	第一层分组依据
最近状态变更日期	状态每变化一次即更新为当天日期	必填	计算滞留时长的基准
验证人	负责验证该缺陷修复结果的人员	必填	明确验证责任，便于催办
优先级	P0/P1/P2/P3，表示修复排期的紧迫程度	必填	第二层分组依据
严重程度	如致命、严重、一般、轻微，表示缺陷对业务的影响程度	必填	辅助判断影响，与优先级配合使用
责任人	当前环节的处理人，修复阶段为开发，验证阶段为测试	必填	明确谁在推进
发现日期	缺陷首次被记录的日期	必填	统计缺陷总量与发现节奏
计划关闭日期	约定的关闭时间点	建议填写	与滞留时长对照，判断是否偏离计划
滞留时长	当前日期减去最近状态变更日期，单位为天	计算字段	第三层分组依据

优先级和严重程度需要分开理解。严重程度描述缺陷本身造成的影响，通常在提交时确定，后续较少调整；优先级描述在当前排期中多快处理，会随版本计划和资源情况变化。一个严重程度为“一般”的缺陷，如果影响核心流程的演示，也可能被定为 P0；反之，一个“严重”缺陷若只影响边缘场景，优先级可以排在后面。两者都保留，分组时以优先级为准，严重程度作为评审参考。

滞留时长不单独手工填写，而是由公式计算，基准是最近状态变更日期而非发现日期。这样做的原因是：一个缺陷从发现到关闭会经过多个环节，每个环节的停留时间才反映当前卡在哪里；用发现日期计算会把已经推进过的缺陷误判为长期滞留。

三层分组：状态、优先级、滞留时长怎么叠加

三层分组的顺序固定为状态、优先级、滞留时长。先按状态分桶，保证不同环节的缺陷不混在一起比较；再在每个状态内按优先级排列；最后按滞留时长分档，让同一优先级内的先后顺序有依据。

第一层：按状态分组

状态集合建议覆盖缺陷从提交到关闭的主要环节：待确认、已确认待修复、修复中、待验证、验证不通过退回、已关闭。状态数量不宜过多，每个状态都应对应一个明确的处理动作和责任人。已关闭的缺陷保留在清单中用于统计，但不参与待清理判定。

第二层：在每个状态内按优先级分组

在每个状态分组内部，按 P0、P1、P2、P3 顺序排列。同一优先级内不再细分，交给第三层处理。这样在清理会议上可以先看 P0 和 P1 的分布，再决定资源投向。

第三层：按滞留时长分档

滞留时长建议分为五档，团队可结合迭代周期调整区间，但需在清单说明中固定下来。

分档	滞留天数	含义
第 1 档	0–3 天	正常流转中
第 2 档	4–7 天	需要关注
第 3 档	8–14 天	明显偏慢，应说明原因
第 4 档	15–30 天	长期滞留，进入清理议程
第 5 档	30 天以上	严重滞留，需要升级处理

阈值按状态分别设定，因为各环节的合理停留时间不同。例如待确认状态通常应在 1–2 天内完成确认，超过 3 天即可视为异常；修复中状态受排期影响，可以放宽到 7 天；待验证状态若验证资源充足，超过 3 天未验证就应提醒。统一用一个阈值会让确认环节的拖延被掩盖，也会让修复环节的正常排期被误判。

分组结果的呈现形式有两种：一是分组表，按状态分工作表或分区块，每个区块内按优先级和滞留分档排列；二是透视视图，行放状态和优先级，列放滞留分档，单元格显示缺陷数量。前者适合逐条处理，后者适合在清理会议上快速判断积压集中在哪个环节。

待清理缺陷怎么识别与排序

待清理缺陷的判定条件是两个同时满足：状态未关闭，且滞留时长超过该状态设定的阈值。只满足其中一个都不进入待清理区——未关闭但刚变更状态的缺陷属于正常流转，滞留久但已关闭的缺陷不再需要处理。

排序规则为先优先级、后滞留时长。具体做法是：P0 排在最前，同优先级内滞留时长从长到短排列。这样高优先级且滞留久的缺陷始终位于清单顶部，清理会议从第一行开始处理即可。

验证不通过退回的缺陷需要单独标记。这类缺陷回到修复责任人队列，滞留时长从退回当天重新计算，并在清单中加一个“退回次数”标记。单独标记的目的是把它与首次修复的缺陷区分开，便于识别反复修复仍不通过的模块和责任人。

长期滞留缺陷需要升级处理。建议设定两级升级：滞留进入第 4 档（15–30 天）的缺陷，由缺陷管理负责人在周会上点名说明原因；进入第 5 档（30 天以上）的缺陷，提交给项目负责人决定是安排修复、降级处理还是关闭并记录原因。升级动作要有结论，避免缺陷在清单中反复出现却无人决策。

清理节奏建议按周执行：每周固定一天刷新滞留时长和分组结果，同一天召开清理会议，会议输出每条待清理缺陷的处理结论和新的责任人，会后回写清单。刷新时点固定，可以避免不同人看到不同版本的数据。

角色分工与清单维护

清单的准确性依赖各角色在各自环节及时更新字段。职责划分清楚，分组结果才可信。

角色	主要职责	交付物
缺陷提交人	提交时填写编号、标题、所属模块、发现版本、发现日期、严重程度，并给出初始优先级建议	字段完整的缺陷记录
修复责任人（开发）	确认缺陷后更新状态为已确认待修复或修复中，修复完成后改为待验证并指定验证人	状态变更记录与修复说明
测试验证人	验证后更新状态为已关闭或验证不通过退回，填写验证结论	验证结论与状态更新
缺陷管理负责人或测试负责人	每周复核分组结果，核对阈值执行情况，主持清理会议	分组复核记录与清理会议纪要
项目负责人	对升级的长期滞留缺陷做出处理决策	升级缺陷的处理结论

清单维护频率与清理节奏一致，按周更新。日常状态下，状态变更由处理人在变更当天完成，不需要等到周会；周会前由缺陷管理负责人统一刷新滞留时长并复核分组，确保会议使用的是最新数据。清单的责任人建议指定一人，负责口径解释和字段规范，避免多人维护导致口径漂移。

如果团队使用 ONES 管理缺陷，可以把上述字段落到工作项属性上：ONES Project 支持一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况；ONES 测试管理支持一键创建并关联缺陷，缺陷可关联至迭代，覆盖从提交到关闭的过程。状态流转和状态变更时间由系统记录，滞留时长可作为计算字段或报表维度使用。分组视图和报表维度能否完全按优先级与滞留时长自定义，需要在具体配置中核验，建议先在测试项目中小范围验证再推广。

填写示例：一份按三层分组的积压清单

以下示例为演示情景，日期与缺陷内容均为虚构，用于说明字段填写和分组归属。

编号	标题	模块	状态	优先级	严重程度	责任人	最近状态变更	滞留天数	分档
BUG-201	支付回调重复入账	支付	修复中	P0	致命	开发A	18 天前	18	第 4 档
BUG-202	订单列表筛选条件丢失	订单	待验证	P1	严重	测试B	9 天前	9	第 3 档
BUG-203	用户头像上传偶发失败	用户中心	待确认	P2	一般	测试C	5 天前	5	第 2 档
BUG-204	导出报表缺少合计行	报表	验证不通过退回	P1	严重	开发D	2 天前	2	第 1 档
BUG-205	帮助页文案错别字	帮助中心	已确认待修复	P3	轻微	开发E	12 天前	12	第 3 档

按三层分组后，清单呈现为：修复中分组下有 BUG-201（P0，第 4 档）；待验证分组下有 BUG-202（P1，第 3 档）；待确认分组下有 BUG-203（P2，第 2 档）；验证不通过退回分组下有 BUG-204（P1，第 1 档，带退回标记）；已确认待修复分组下有 BUG-205（P3，第 3 档）。

按“先优先级、后滞留时长”排序，待清理区内的顺序为：BUG-201（P0，18 天）、BUG-202（P1，9 天）、BUG-205（P3，12 天）。BUG-204 虽然优先级为 P1，但滞留仅 2 天且处于退回后的重新计时阶段，暂不进入待清理区，只做退回标记跟踪。BUG-203 滞留 5 天，若待确认状态的阈值设为 3 天，则它已超过阈值，应进入待清理区并排在 P2 组内首位。

完成检查：清单可用性的核对项

清单发布或每周刷新后，按以下条目逐项核对，全部通过再用于清理会议。

核对项	核对方法	通过标准
必填字段完整性	筛选必填字段为空的行	无空缺，或空缺项已注明原因和补填时间
状态与日期一致性	抽查最近变更过状态的缺陷	状态与最近状态变更日期对应，无状态已改但日期未更新的情况
滞留时长计算口径	抽取若干条手工复算	结果等于当前日期减最近状态变更日期，单位统一为天
分组层级与阈值	检查分组顺序和分档区间	按状态、优先级、滞留时长三层排列，阈值与清单说明一致
待清理缺陷可识别	查看待清理区或筛选条件	未关闭且超过状态阈值的缺陷全部出现在待清理区，排序符合规则
退回缺陷标记	筛选验证不通过退回状态	均有退回标记，滞留时长从退回日重新计算

核对中发现口径不一致时，先修正字段和公式，再重新生成分组结果，避免在错误数据上做清理决策。清单说明中应记录阈值、分档区间和更新时点，人员变动时按说明交接即可保持口径稳定。

常见问题

团队迭代周期短，滞留时长分档区间需要调整吗？

可以调整，但要在清单说明中固定下来并保持一段时间不变。分档区间的目的是区分正常流转、需要关注和需要清理的缺陷，如果迭代周期为一周，0–3 天和 4–7 天两档可能覆盖了大部分缺陷，可以把区间压缩为 0–1 天、2–3 天、4–7 天、8–14 天、14 天以上。调整后要同步修改各状态的阈值，避免分档和阈值互相矛盾。区间频繁变动会让周与周之间的数据无法比较，建议至少连续使用一个季度再评估。

缺陷在待验证状态停留很久，是算测试的问题还是开发的问题？

滞留时长只反映缺陷在当前状态停留了多久，不直接判定责任归属。待验证状态停留久，可能的原因包括验证资源不足、验证环境未就绪、验证人未收到通知，也可能是修复说明不清晰导致验证无法开展。清理会议上看这条缺陷时，先确认验证人是否明确、验证条件是否具备，再决定是催办验证还是退回补充修复说明。把原因记录在清单备注中，积累几周后可以看出待验证环节的积压主要来自哪类原因，再针对性调整。

已关闭的缺陷还要保留在积压清单里吗？

建议保留，但不参与待清理判定。保留已关闭缺陷有两个用途：一是统计各模块的缺陷总量和关闭节奏，判断积压是在减少还是在增加；二是当同一模块反复出现验证不通过退回时，可以回溯历史缺陷查看是否有相似问题。如果清单数据量较大影响查看，可以把已关闭缺陷放在单独的分组或视图中，主视图只显示未关闭缺陷。清理会议的讨论范围限定在未关闭缺陷，已关闭缺陷只作为背景数据参考。

用 ONES 管理缺陷时，滞留时长和分组视图能直接配置出来吗？

ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况；ONES 测试管理支持一键创建并关联缺陷，缺陷可关联至迭代。状态流转由系统记录，但滞留时长作为计算字段、以及按优先级与滞留时长的分组视图能否完全按本文规则自定义，需要在具体配置中核验。建议先在测试项目中小范围验证字段、公式和视图配置，确认结果与手工计算一致后再推广到正式项目。

清理会议上对长期滞留缺陷做出的决策，怎么保证被执行？

每条待清理缺陷在会议上要有三个输出：处理方式（安排修复、降级、关闭并记录原因）、新的责任人和完成时间。会后由缺陷管理负责人把结论回写到清单对应行，并在下一周刷新时优先检查上周结论的执行情况。对于进入 30 天以上分档的缺陷，处理结论提交给项目负责人确认，避免在清理会议上反复讨论却没有决策权限。如果某条缺陷连续两周没有结论或结论未执行，应在会议纪要中单独列出，作为流程问题跟进。