缺陷积压清单要能回答“先清哪一条”，靠的是把状态、优先级和滞留时长放在同一张表里分组排序。本文限定在缺陷从修复到验证的环节，先给出字段结构，再分别说明三层分组口径，最后合成一张可执行的待清理清单，并交代维护角色与检查项。
要点总览（TL;DR）
- 缺陷积压清单先固定字段：状态、优先级、进入当前状态时间、负责人、验证结论是分组与排序的基础，其中进入当前状态时间必须强制填写。
- 状态分组拆成待处理、处理中、待验证、已关闭四段，每段对应修复到验证流程中的一个环节和一类清理动作，积压集中在哪一段一目了然。
- 滞留时长按“当前时间减进入当前状态时间”计算，并按7天内、8–14天、15–30天、30天以上分档，按状态分别计算才能反映真实瓶颈。
- 三层叠加的排序为状态（待验证优先）、优先级（P0到P3）、滞留时长（从长到短），优先清理“高优先级+长滞留+卡在待验证”的条目。
- 清单由测试负责人维护排序并组织每周评审，各环节负责人即时更新状态和时间字段，评审时按字段完整、状态准确、时长可算、排序可执行逐项核验。
清单先要有哪些字段
分组的前提是字段可计算、取值可统一。缺陷积压清单不需要字段很多，但每个参与分组和排序的字段都必须有明确取值，否则后续的状态统计和滞留时长计算会失真。建议按下表建表，其中“进入当前状态时间”是滞留时长计算的唯一依据，必须强制填写。
| 字段名 | 取值示例 | 必填 | 用途 |
|---|---|---|---|
| 缺陷编号 | BUG-1024 | 必填 | 唯一标识，便于交接和引用 |
| 标题 | 订单列表分页跳转后数据重复 | 必填 | 快速识别问题内容 |
| 所属模块/版本 | 订单中心 / V2.3.1 | 必填 | 定位影响范围，支撑按版本清理 |
| 状态 | 待处理、处理中、待验证、已关闭 | 必填 | 状态分组依据 |
| 优先级 | P0、P1、P2、P3 | 必填 | 优先级分组与排序依据 |
| 进入当前状态时间 | 2025-03-12 14:20 | 必填 | 计算滞留时长 |
| 创建时间 | 2025-03-10 09:05 | 必填 | 计算总存活时长，辅助判断 |
| 负责人 | 张工 | 必填 | 明确当前环节责任人 |
| 验证人 | 李工 | 待验证及之后必填 | 验证环节交接对象 |
| 验证结论 | 通过、不通过、待验证 | 待验证及之后必填 | 判断能否关闭，支撑交接 |
必填与选填的划分原则是：参与分组、排序和交接的字段必填，描述性信息可选填。状态枚举要固定为四个值，避免出现“修复完成”“已解决”等含义重叠的写法；优先级只使用一套分级，不在同一列混用“高/中/低”和“P0–P3”。字段口径一旦确定，就写入清单模板说明，新增字段需同步更新说明。
按状态分组：把积压拆成四段
状态分组的作用是把“积压”这个笼统数字拆成四段，看清缺陷卡在修复、验证还是关闭环节。建议固定为待处理、处理中、待验证、已关闭四组，每组对应流程中的一个环节和一类清理动作。
| 状态分组 | 含义 | 清理动作 | 主要责任角色 |
|---|---|---|---|
| 待处理 | 已提交，尚未开始修复 | 确认是否有效、补齐复现信息、排入修复计划 | 缺陷提交人、测试负责人 |
| 处理中 | 已分派，正在修复 | 跟进修复进度，识别长期无进展项 | 修复人 |
| 待验证 | 修复完成，等待验证 | 安排验证，记录验证结论 | 验证人 |
| 已关闭 | 验证通过或确认不修复 | 归档，不再计入积压 | 验证人 |
四组与修复到验证的流程一一对应：待处理对应受理，处理中对应修复，待验证对应验证，已关闭对应结束。状态口径统一的做法是：每次状态变更时同步更新“进入当前状态时间”，并在变更记录中写明操作人和时间；状态只能按流程向前流转，回退（如验证不通过退回处理中）同样视为一次状态变更，重新计时。这样每个分组的条目数都能直接对应到具体环节，积压集中在哪一段一目了然。
按优先级分组：确定清理顺序
优先级分组解决的是同一状态组内先清谁的问题。建议使用P0–P3四级，判定依据围绕影响范围和业务后果，而不是修复难度。
| 优先级 | 判定依据 | 处理要求 |
|---|---|---|
| P0 | 核心流程不可用、数据错误或存在安全风险 | 立即处理，当日响应 |
| P1 | 主要功能受阻，有可接受的临时绕行方案 | 本迭代内修复 |
| P2 | 局部功能异常，影响有限 | 排入近期计划 |
| P3 | 体验问题、文案或低频场景缺陷 | 按容量安排 |
优先级与严重程度要分开记录。严重程度描述缺陷本身造成的影响，优先级描述在当前版本和当前时间下的处理紧迫性，两者可以不一致：一个严重程度高的缺陷如果已有稳定绕行方案，优先级可能下调；一个严重程度一般的缺陷如果阻塞了即将发布的版本，优先级需要上调。组内排序规则为：先按优先级从P0到P3，同一优先级内再按滞留时长从长到短。优先级调整必须有触发条件和记录，例如版本发布临近、影响范围扩大、出现新的绕行失败，调整时在清单中注明调整人、时间和理由，避免优先级被随意改动而失去排序意义。
按滞留时长分组：算出卡了多久
滞留时长的计算口径是：当前时间减去进入当前状态时间。它衡量的是缺陷在当前环节停留了多久，而不是从创建至今的总时长，因此必须按状态分别计算——待处理项算的是等待受理的时间，待验证项算的是等待验证的时间，两者含义不同，混算会掩盖真正的瓶颈。
| 滞留分档 | 时长范围 | 处理提示 |
|---|---|---|
| 正常 | 7天内 | 按常规节奏推进 |
| 关注 | 8–14天 | 在例会中确认进展 |
| 超期 | 15–30天 | 指定跟进人，给出明确时间点 |
| 严重超期 | 30天以上 | 升级处理，评估是否关闭或重新排期 |
超期阈值可以按状态差异化设置：待验证环节通常应比处理中环节更短，因为验证动作本身耗时有限，长时间停留在待验证往往意味着验证资源不足或交接遗漏。提醒规则建议与阈值绑定，例如进入“关注”档时在清单中标记，进入“超期”档时通知负责人和测试负责人，进入“严重超期”档时纳入积压评审议题。滞留时长按天计算即可满足分组需要，精确到小时会增加维护成本，收益有限。
三层叠加：生成待清理排序清单
三层叠加的做法是：先按状态分组确定当前环节，再在未关闭组内按优先级排序，最后用滞留时长分档标记紧急程度。组合视图的筛选条件建议为“状态不等于已关闭”，排列顺序为状态（待验证优先于处理中，处理中优先于待处理）、优先级（P0到P3）、滞留时长（从长到短）。待验证排在前面的理由是：修复已完成，验证是投入产出比最高的清理动作，积压在这里的缺陷离关闭只差一步。
示例（演示情景）：一条缺陷BUG-1024，状态为待验证，优先级P1，进入待验证时间为20天前，验证人为李工，验证结论为待验证。按三层规则，它落在“待验证+P1+超期”组合中，排序靠前，应被识别为优先清理项：由测试负责人确认验证排期，李工在约定时间内完成验证并填写结论，通过则关闭，不通过则退回处理中并重新计时。
| 排序 | 缺陷编号 | 状态 | 优先级 | 滞留时长 | 下一步动作 |
|---|---|---|---|---|---|
| 1 | BUG-1024 | 待验证 | P1 | 20天（超期） | 安排验证，填写结论 |
| 2 | BUG-1031 | 待验证 | P2 | 9天（关注） | 本周内完成验证 |
| 3 | BUG-1018 | 处理中 | P0 | 3天（正常） | 跟进修复进度 |
| 4 | BUG-1007 | 待处理 | P2 | 32天（严重超期） | 确认有效性，决定修复或关闭 |
清理清单建议每周更新一次，版本发布前额外更新一次，由测试负责人维护排序结果，各环节负责人更新自己条目的状态和时间字段。清单的边界是缺陷修复与验证的跟踪：验证通过后的整体回归测试安排、测试范围设计属于另外的管理动作，不在本清单中展开，清单只保证每条缺陷有明确的状态、责任人和下一步动作。
在工具层面，这类清单依赖工作项的状态流转和字段记录。ONES支持为工作项配置状态与自定义字段，状态变更时间可随流转记录，便于按状态、优先级和进入状态时间生成分组视图与筛选结果，减少手工维护表格时的口径偏差。
角色分工与完成检查
清单能否持续可用，取决于每个角色是否在正确的时间更新正确的字段。职责划分建议如下。
| 角色 | 职责 |
|---|---|
| 缺陷提交人 | 提交时填写标题、模块/版本、复现信息，配合确认缺陷有效性 |
| 修复人 | 接单后更新状态为处理中，修复完成后流转为待验证并指定验证人 |
| 验证人 | 完成验证并填写验证结论，通过则关闭，不通过则退回并说明原因 |
| 测试负责人 | 维护清单排序，组织每周积压评审，跟进超期项 |
清单维护时点为：状态每次变更时即时更新字段；每周固定时间由测试负责人汇总一次分组结果并组织评审；版本发布前对未关闭项做一次全量核对。完成检查可按以下条目逐项核验：字段是否完整，尤其是进入当前状态时间和负责人；状态是否与实际进展一致，是否存在修复完成但仍停留在处理中的情况；滞留时长是否可算，进入当前状态时间是否缺失或早于创建时间；排序是否可执行，每条靠前条目是否有明确的下一步动作和责任人。
常见填写错误包括：状态使用自定义写法导致分组遗漏；优先级长期不调整，P0项堆积失去区分度；状态变更后未更新时间字段，滞留时长偏小；验证结论留空就关闭缺陷。纠正方式是在评审时逐条核对上述检查项，把口径问题反馈到模板说明中，而不是逐条口头提醒。
常见问题
缺陷长期停在“待验证”，滞留时长该怎么算才合理？
滞留时长按“当前时间减进入当前状态时间”计算，缺陷进入待验证时重新计时，所以待验证项的时长反映的是等待验证的时间，而不是从创建至今的总时长。待验证环节本身耗时有限，长时间停留通常意味着验证资源不足或交接遗漏，建议给待验证设置比处理中更短的超期阈值，例如超过7天即进入关注档，超过14天升级处理。
优先级和严重程度不一致时，清单排序以哪个为准？
排序以优先级为准。严重程度描述缺陷本身造成的影响，优先级描述在当前版本和当前时间下的处理紧迫性，两者可以不一致：严重程度高但已有稳定绕行方案的缺陷，优先级可以下调；严重程度一般但阻塞版本发布的缺陷，优先级需要上调。优先级调整要记录调整人、时间和理由，避免排序失去意义。
验证不通过退回处理中，滞留时长要重新计算吗？
要重新计算。验证不通过退回处理中同样视为一次状态变更，进入当前状态时间更新为退回时刻，滞留时长从零开始累计。这样处理中环节的时长反映的是本轮修复的实际等待时间，不会把上一轮修复和验证的时间混入，便于判断当前环节是否真的卡住。
清单每周更新一次够不够，什么情况下需要临时更新？
常规节奏下每周更新一次可以满足积压评审需要，版本发布前应额外做一次全量核对。出现以下情况时建议临时更新：P0缺陷新增或优先级上调、缺陷状态发生流转、超期档位发生变化。状态字段本身应在每次变更时即时更新，周更新汇总的是分组与排序结果，两者不冲突。
用表格维护清单和用工具管理，主要差别在哪里？
差别主要在状态变更时间的记录方式和分组视图的生成。手工表格需要每次变更时手动改写时间字段，容易出现漏改导致滞留时长偏小；工具中工作项状态流转可随流转记录时间，按状态、优先级和进入状态时间筛选分组也更直接。ONES支持为工作项配置状态与自定义字段，可减少手工维护表格时的口径偏差。选择哪种方式取决于团队规模和变更频率，条目少、变更不频繁时表格也能用。
