缺陷修复逾期时，先把“逾期”拆开看：是缺陷还没修完、修完没提交验证、验证被退回，还是卡在外部依赖。分流后为每条缺陷补齐责任人、新的承诺时间和阻塞原因，再按风险排序处置，并用逾期数量、平均滞留时长和二次退回率确认恢复情况。缺陷状态流转、验证记录和责任人变更通常需要在同一套工作项跟踪中留痕，ONES 的测试管理与项目缺陷跟踪可用于承载这一段管理动作。
要点总览（TL;DR）
- 先把逾期拆成四类：无人认领、修复中停滞、已修复未提交验证、验证退回后搁置，分别对应不同责任人和动作。
- 原因排查以记录证据为准：先看状态流转断点，再看评论与附件中的阻塞说明，最后确认外部依赖，证据不足时标注待确认。
- 处置按风险分级：高风险缺陷当日或次日给出新时间点和临时规避方案，中低风险缺陷重排计划并合并验证批次，阻塞类缺陷记录依赖并设跟进节点。
- 处置后用逾期数量、平均滞留时长和验证退回后重新处理比例三项指标确认恢复，按批次核对缺陷状态与验证结论。
- 预防复发靠到期前提醒、逾期自动升级、定期逾期清单复盘，并把依赖项纳入迭代计划评审。
先判断逾期发生在修复、提交还是验证环节
“缺陷修复逾期”是一个笼统说法，落到处置上至少要区分三种计时口径：超过承诺修复时间、超过验证排期、验证退回后重新计时。三种口径对应不同的责任人和动作，混在一起统计会让逾期数量失真，也会让处置会议变成互相解释。
建议先建立判定口径，再逐条归类。承诺修复时间以缺陷记录中约定的时间为准；验证排期以测试方确认的验证批次或验证窗口为准；验证退回后，从退回时刻重新起算修复时限，原承诺时间不再作为有效依据。口径确定后，同一批缺陷的逾期天数才具备可比性。
常见的逾期症状可以归为四类，每类卡在不同环节：
- 无人认领：缺陷已提交但未指定责任人，或责任人已变更未交接，状态长期停留在待处理。
- 修复中停滞：已有责任人，但状态在“修复中”停留超过约定时长，缺少进展说明。
- 已修复未提交验证：开发侧认为已改完，缺陷状态未流转到待验证，测试方不知道可以验证。
- 验证退回后搁置：验证不通过退回，缺陷重新打开后无人跟进，或重新计时后再次超期。
圈定处置范围时，按严重级别和影响范围两个维度排序。阻塞主流程、影响线上用户、涉及数据正确性的缺陷列入必须立即处理；一般体验问题、文案问题可排期处理。范围不宜一次铺得过大，先处理当前迭代内到期和已逾期的缺陷，历史积压单独建清单，避免处置表变成全量缺陷列表。
这一环节的交付物是一张逾期缺陷分类清单，字段至少包括：缺陷编号、严重级别、影响范围、当前状态、卡住的环节、原承诺时间、逾期天数、责任人。清单的作用是让后续排查有明确对象，每条缺陷只归入一个主环节，避免重复计数。
逐类排查逾期原因并收集排除证据
分类完成后，对每条逾期缺陷提出原因假设，再用记录中的证据验证。原因假设常见有五类：工作量低估、依赖未就绪、责任人负荷过高、需求或复现信息不清、验证环境不可用。假设只是排查起点，不能直接写进结论。
| 原因假设 | 可查证据 | 排除或确认方式 |
|---|---|---|
| 工作量低估 | 状态变更时间、修复评论中的工作量说明、关联代码或配置变更记录 | 对比承诺时间与实际投入，确认是否存在范围扩大 |
| 依赖未就绪 | 关联需求、依赖项状态、对接人评论 | 确认依赖项的完成时间是否晚于缺陷承诺时间 |
| 责任人负荷过高 | 责任人名下同时段缺陷数量、状态变更频率 | 确认是否存在长期无状态变更，且同期承担其他紧急任务 |
| 需求或复现信息不清 | 缺陷描述、附件、复现步骤、评论中的追问记录 | 确认是否因信息不足导致多次往返而未进入修复 |
| 验证环境不可用 | 验证记录、环境占用说明、测试方评论 | 确认验证排期是否因环境原因被推迟 |
排查顺序建议固定为三步：先看状态流转断点，找到缺陷最后一次有效状态变更发生在什么时间、由谁操作；再看阻塞说明，检查评论和附件中是否记录了等待依赖、等待信息、等待环境；最后确认外部依赖，包括第三方接口、其他团队交付物、硬件或数据准备。三步走完仍无法解释的，标注“待确认”，指定跟进人和确认时间，不强行归因。
证据不足时直接下结论，容易把管理问题误判为技术问题。例如缺陷长期停在“修复中”，可能并非开发未处理，而是复现信息不足导致反复沟通；也可能开发已完成但未更新状态。两种情况的责任人和处置动作完全不同，必须用状态变更记录和评论区分。
这一环节的交付物是原因与证据对照表，每条逾期缺陷给出一个主因和至少一条支撑证据。主因用于决定处置动作，次要原因记录在备注中，供后续预防规则参考。
按风险分级安排处置动作
原因确认后进入处置。处置的核心不是把所有逾期缺陷同时推进，而是按风险决定先后，并为每条缺陷明确责任人、新时间点和具体动作。
高风险缺陷指阻塞主流程、影响线上用户或涉及数据正确性的缺陷。处置动作是立即指定责任人，评估是否需要临时规避或降级方案，例如关闭受影响入口、增加人工校验、回退相关配置，并约定当日或次日的新时间点。临时方案要写进缺陷记录，说明适用条件和解除条件，避免临时措施长期化。
中低风险缺陷重排修复计划，合并到同一验证批次，明确新的承诺时间。合并批次可以减少验证环境的反复切换，也便于测试方集中核对。重排时要检查同一责任人名下的缺陷总量，避免新时间点再次集中到期。
阻塞类缺陷把依赖项和对接人写进缺陷记录，设定跟进节点，例如每日确认依赖进展。依赖长期无法解决时提交升级，由项目负责人或跨团队协调人决定调整范围、更换方案或接受延期。升级时带上已确认的证据，说明依赖对交付的具体影响。
处置涉及线上变更或数据修复时，先备份相关数据，先在非生产环境验证修复方案，确认回滚方式后再执行。明确停止点：验证未通过、影响范围超出预期、备份未完成时停止操作，回到评估环节。这类操作的风险边界应在处置表中单独标注，不能与普通缺陷修复混排。
| 风险级别 | 处置动作 | 时间要求 | 记录要求 |
|---|---|---|---|
| 高风险 | 指定责任人，给出临时规避或降级方案 | 当日或次日新时间点 | 临时方案、适用条件、解除条件 |
| 中低风险 | 重排计划，合并验证批次 | 纳入下一验证窗口 | 新承诺时间、所属批次 |
| 阻塞类 | 记录依赖项与对接人，设跟进节点 | 按跟进节点复查 | 依赖状态、升级记录 |
处置表完成后，建议每天用短会核对高风险项和阻塞项，中低风险项按批次节点核对。核对内容只看三件事：责任人是否明确、新时间点是否可行、阻塞是否解除。缺陷状态、责任人和承诺时间在同一工作项中更新，验证记录与缺陷关联，可以减少处置表与系统记录不一致的情况。ONES Project 支持将 Bug 提交至对应项目或迭代并跟踪修复情况，ONES 测试管理方案中的缺陷可关联至迭代，适合把上述状态流转和验证记录放在同一处维护；具体字段与提醒配置需以实际使用版本为准。
验证恢复并设置复发预防规则
处置完成后需要确认逾期确实消除，而不是暂时从清单上消失。恢复验证建议看三项指标：逾期缺陷数量降到约定阈值或归零、平均滞留时长下降、验证退回后重新处理的比例下降。三项指标按同一统计口径对比处置前后，例如都按当前迭代内到期缺陷计算，避免口径变化造成“看起来好转”。
验证方式是按批次核对缺陷状态与验证结论。每条关闭的缺陷应有明确的验证记录：验证人、验证时间、验证结论、关闭依据。验证退回的缺陷要确认已重新指定责任人和新时间点，不能停留在退回状态。核对时抽查高风险缺陷的临时方案是否已解除，避免临时规避措施被遗忘。
复发预防可以从四个动作入手：
- 到期前提醒：在承诺时间前设置提醒，给责任人和测试方留出处理窗口。
- 逾期自动升级：超过承诺时间仍未流转的缺陷，自动通知项目负责人或测试负责人，减少人工巡检遗漏。
- 定期逾期清单复盘：每日或每周固定查看逾期清单，重点看新增逾期和重复逾期，分析是否集中在某类缺陷或某个环节。
- 依赖项纳入计划评审：在迭代计划阶段确认外部依赖的交付时间，把依赖风险提前暴露，而不是等到缺陷逾期后再协调。
跟踪规则要写清楚触发条件、通知对象和处理时限，例如“缺陷超过承诺修复时间 1 天未变更状态，通知责任人与测试负责人，2 天内未响应升级至项目负责人”。规则确定后放入团队现有的缺陷跟踪流程，与状态流转一并执行。ONES 测试管理方案提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代，可作为承载状态、责任人与验证记录的跟踪基础；到期提醒和自动升级的具体配置方式，需结合所用版本确认。
最后形成一份恢复验证结论与跟踪规则清单：结论部分记录三项指标的前后对比和抽查结果，规则部分记录触发条件、通知对象、处理时限和复盘频率。下一次出现逾期时，直接按本文的分类、排查、处置、验证四步执行，处置表和历史清单可作为复盘依据。
常见问题
缺陷的承诺修复时间已经过了，但开发说一直在处理，这种情况算逾期吗？
算。逾期判定以缺陷记录中约定的承诺修复时间为准，与责任人是否在处理无关。状态长期停留在“修复中”且缺少进展说明，本身就是需要处置的症状。
处置时先看状态变更记录：最后一次有效变更发生在什么时间、由谁操作。如果确实在推进但工作量超出预期，应更新承诺时间并说明原因，让逾期天数重新有可比口径；如果长期无状态变更，按修复中停滞处理，确认是否存在复现信息不足或依赖未就绪等阻塞。
验证退回后重新打开的缺陷，逾期时间从什么时候开始算？
从验证退回的时刻重新起算修复时限，原承诺时间不再作为有效依据。这样同一批缺陷的逾期天数才具备可比性。
重新计时后要同步做两件事：重新指定责任人，给出新的承诺时间；在缺陷记录中写明退回原因和需要补充的信息。退回后长期无人跟进，是二次逾期的常见来源，建议把退回缺陷纳入每日逾期清单一起核对。
缺陷卡在外部依赖上，团队内部无法推动，应该怎么处理？
先把依赖项和对接人写进缺陷记录，设定跟进节点，例如每日确认依赖进展。跟进节点到期仍无进展时提交升级，由项目负责人或跨团队协调人决定调整范围、更换方案或接受延期。
升级时带上已确认的证据，说明依赖对交付的具体影响，避免升级变成口头催促。如果依赖长期无法解决，也可以评估临时规避方案，并在缺陷记录中写明适用条件和解除条件。
处置涉及线上数据修复，执行时要注意什么？
先备份相关数据，先在非生产环境验证修复方案，确认回滚方式后再执行。这类操作的风险边界应在处置表中单独标注，不与普通缺陷修复混排。
明确停止点：验证未通过、影响范围超出预期、备份未完成时停止操作，回到评估环节。临时规避措施要记录解除条件，恢复验证时抽查是否已解除，避免临时方案长期化。
怎么判断逾期处置已经见效，而不是缺陷暂时从清单上消失了？
看三项指标按同一口径的前后对比：逾期缺陷数量是否降到约定阈值或归零、平均滞留时长是否下降、验证退回后重新处理的比例是否下降。统计口径保持一致，例如都按当前迭代内到期缺陷计算。
同时按批次核对关闭依据：每条关闭的缺陷应有验证人、验证时间、验证结论。验证退回的缺陷要确认已重新指定责任人和新时间点。指标好转但关闭依据缺失，说明处置尚未真正完成。
