测试执行进度滞后时，先别急着砍用例。把剩余未执行用例、可用人天和阻塞情况放在一起算清缺口，再按业务影响与变更风险把剩余范围分成必测、可压缩、可延后三类，同步调整执行分派和退出条件，最后用一轮关键路径回归确认重排后的覆盖仍守得住质量底线。本文按量化缺口、排查原因、分级取舍、验证恢复四步展开，涉及测试用例与执行跟踪时，可借助ONES测试管理承接分级结果与执行分派。
要点总览（TL;DR）
- 先把剩余未执行用例、已执行未通过用例、阻塞用例和剩余可用人天放在一起算缺口比例，判断是轻度压缩还是必须大幅取舍。
- 原因排查按先环境与阻塞、再人力、最后范围本身的顺序进行，证据不足时保留假设，不据此削减范围。
- 剩余用例按业务影响、变更影响、历史缺陷密度分为必测、可压缩、可延后三类，可压缩范围用等价类合并和关键路径优先来压缩。
- 执行分派改为按模块认领、阻塞项当日攻坚、每人设定每日执行目标，涉及资金、权限、数据安全和核心交易链路的用例不单方面削减。
- 退出条件以必测完成率、关键路径通过情况和遗留缺陷等级分布共同判断，重排后跑一轮关键路径或冒烟回归验证恢复，并显式记录未覆盖范围做风险移交。
滞后到什么程度：先量化剩余范围与时间缺口
“进度滞后”本身不是可执行的信息。重排范围前，需要把滞后换算成一组可比较的数字：还剩多少用例没跑、多少跑了没通过、多少被卡住，以及团队真正还能投入多少时间。只有缺口大小和来源都清楚，后面的取舍才有依据。
建议先做一张剩余范围与时间缺口对照表，按模块或测试计划分行填写：
| 统计项 | 口径 | 用途 |
|---|---|---|
| 剩余未执行用例数 | 计划内尚未开始执行的用例，按模块拆分 | 确定待处理的总量 |
| 已执行未通过数 | 已执行但结果为失败的用例，区分是否已提交缺陷 | 判断是否需要返工与复测时间 |
| 阻塞用例数 | 因环境、数据、依赖未就绪而无法执行的用例 | 识别可先行清理的障碍 |
| 剩余可用人天 | 剩余工作日内可投入测试的人天，扣除会议、支持等占用 | 换算真实产能 |
| 剩余用例估算工作量 | 按历史执行速度折算所需人天 | 与可用人天对比得出缺口 |
| 缺口比例 | （所需人天－可用人天）÷所需人天 | 判断是轻度压缩还是必须大幅取舍 |
缺口比例算出来后，还要标注主要滞后来源。常见情况包括：用例总量超出原估算、环境或测试数据长时间不可用、执行人力被线上问题或其它项目抽调、缺陷集中出现导致返工复测占用时间、用例粒度过粗单条执行耗时远超预期。来源不同，处置动作完全不同——环境阻塞优先清理障碍，人力不足优先调整分派，范围膨胀才需要动用例本身。
这里需要明确本文的处理边界：重排只针对测试运行范围，即哪些用例在剩余时间内执行、由谁执行、按什么顺序执行。缺陷修复闭环、缺陷验证跟踪以及最终测试报告的编写与质量评估，属于另外的工作流，不在本文展开。
滞后原因假设与排除证据
量化出缺口后，容易犯的错误是把第一直觉当成结论，直接按“范围太大”砍用例。更稳妥的做法是把可能原因列为假设，逐条找证据验证，再决定是否动范围。证据不足时保留假设，不据此削减测试范围。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 范围膨胀：计划内用例数超出原估算 | 计划用例总数与基线对比、需求变更记录 | 第三位 |
| 环境或数据阻塞：用例无法执行 | 阻塞记录、环境可用时间、数据准备工单 | 第一位 |
| 执行人力被抽调 | 每日实际执行人数、人员投入记录、抽调通知 | 第二位 |
| 缺陷集中返工 | 缺陷分布、失败用例复测次数、返工耗时统计 | 第二位 |
| 用例粒度粗导致执行慢 | 单条用例平均执行时长、执行日志中的长耗时用例 | 第三位 |
排查顺序建议先环境与阻塞、再人力、最后范围本身。原因在于：阻塞项往往可以当天清理，清理后执行速度立刻恢复，此时削减范围属于误伤；人力问题可以通过调整分派或申请支援缓解；只有前两类都排除后，才说明缺口确实来自范围本身，需要进入分级取舍。
验证时以执行日志和每日执行趋势为主要证据。例如连续几天执行完成数明显低于计划，同时阻塞用例数居高不下，基本可以判断瓶颈在环境；若执行完成数正常但失败率高、复测反复，则更可能是缺陷返工占用产能。证据只能支持方向性判断时，在记录中写明“待确认”，并设定一个观察窗口（如再跟踪一个工作日）后再决策。
重排剩余测试范围：分级、取舍与执行分派
确认缺口主要来自范围后，进入处置动作。核心方法是对剩余用例分级，把有限时间投到风险最高的部分，同时把取舍决定记录清楚，避免事后无人说得清哪些范围被放弃、为什么放弃。
按三个维度给剩余用例分级
分级依据建议统一为业务影响、变更影响、历史缺陷密度三项。业务影响看用例覆盖的功能是否为核心交易或高频入口；变更影响看该功能本次是否有代码改动、改动范围多大；历史缺陷密度看该模块过往缺陷数量。三项都高的用例进入必测，单项较高的进入可压缩，其余进入可延后。
| 分级 | 判定参考 | 处置方式 |
|---|---|---|
| 必测 | 核心业务路径、本次有变更、历史缺陷集中 | 全部执行，不压缩 |
| 可压缩 | 业务影响中等，或变更较小 | 等价类合并、抽样执行、保留关键路径 |
| 可延后 | 低频功能、本次无变更、历史稳定 | 记录后延至下一轮或下个版本 |
可压缩范围的合并与抽样
可压缩不等于随意删减。常用做法是：把验证同一规则的多条用例按等价类合并为一条代表性用例；对同一表单的多个字段校验，保留边界值和异常值各一条；对流程类用例优先保留主路径和关键分支，跳过次要分支的组合场景。合并后要在用例记录中注明覆盖了哪些原有用例，便于追溯。
调整执行分派
范围确定后，执行分派同步调整：按模块认领，让熟悉该模块的成员集中执行，减少上下文切换；对阻塞项安排专人当日攻坚，清理一条释放一批用例；为每人设定每日执行目标，并在当天结束时核对完成情况。分派调整后，原先按人平均分配的做法要让位于按风险分配，必测模块可以多配人手。
取舍的风险边界与留痕
有些范围不得单方面削减：涉及资金、权限、数据安全、核心交易链路的用例，即使时间紧张也应保留；监管或合同约定的测试项同样不能跳过。削减可压缩和可延后范围时，需要明确确认人——通常是测试负责人与产品负责人共同确认，并在用例或测试计划中记录延后原因、影响范围和计划补测时间。跳过或延后的用例保留原状态并标注处置结论，避免被误认为已通过。
当分级结果需要落到具体用例上时，ONES测试管理支持用例与需求、任务关联，测试计划与迭代关联，便于把必测范围对应到本次迭代的变更内容；用例库属性支持筛选，可按模块、执行人等条件快速圈出待重排的用例集合；用例可分配执行人，支持按模块认领后的分派调整。这些能力承接的是分级之后的执行组织动作，分级标准本身仍需团队按业务判断确定。
退出条件评估与恢复验证
重排后的范围能否支撑退出本轮测试，不能只看“时间到了”。需要一组事先约定的退出条件，并在条件满足后做一次恢复验证，确认重排没有留下明显的质量缺口。
退出条件的构成
- 必测范围执行完成率：必测用例应全部执行完毕，未执行项需逐条说明原因。
- 关键路径通过情况：核心业务路径的用例全部通过，无未关闭的高等级失败。
- 遗留缺陷等级分布：统计未修复缺陷的等级与数量，明确哪些可带入下一阶段、由谁跟踪。
三项条件建议在重排时一并确定阈值，例如“必测完成率100%、关键路径无阻断级缺陷、遗留缺陷中高等级为零或已获书面接受”，避免临近结束时临时放宽标准。
恢复验证
重排后执行一轮关键路径回归或冒烟测试，作为恢复验证。这一轮的目的不是补全所有覆盖，而是确认被压缩和延后的部分没有连带影响核心功能。验证结果记录为恢复验证记录，包含执行时间、覆盖的关键路径、结果和发现的问题。
| 记录项 | 填写内容 |
|---|---|
| 验证时间与执行人 | 实际执行时间、参与人员 |
| 覆盖的关键路径 | 列出本轮回归覆盖的核心流程 |
| 执行结果 | 通过、失败及对应缺陷编号 |
| 未覆盖范围 | 延后或跳过的用例清单及原因 |
| 风险移交 | 接收人、补测计划时间、确认记录 |
未覆盖范围的显式记录与风险移交
延后和跳过的用例必须形成清单，写明影响的功能、潜在风险和计划补测时间，移交给对应的产品负责人或下轮测试负责人，并取得确认。风险移交不是形式动作，它决定了后续版本能否据此安排补测资源。
复发预防
重排解决的是当下缺口，防止再次滞后需要日常机制：每天跟踪执行趋势，对比计划完成数与实际完成数，偏差连续出现时提前预警；阻塞项当日清理，不积压到周末；范围发生变更时重新评估工期，把新增用例的工作量纳入计划而不是默认消化。ONES测试管理提供测试计划的多维度概览和测试情况概览，可查看计划进度与通过率，适合作为每日执行跟踪的查看入口；不同用户组和测试计划可单独配置权限，便于把范围调整与确认记录限定在相关角色内。每日趋势预警等更细的统计口径，选型时可按团队实际需要核验。
常见问题
剩余时间只够跑一半用例，应该先砍哪些、保留哪些？
先保留三类：覆盖核心交易或高频入口的用例、本次有代码改动的功能用例、历史缺陷集中的模块用例。这三类对应业务影响、变更影响和历史缺陷密度三个维度，任一项突出就优先保留。可以压缩的是验证同一规则的多条用例，按等价类合并为一条代表性用例；可以延后的是低频功能、本次无变更且历史稳定的用例。涉及资金、权限、数据安全和核心交易链路的用例，即使时间紧张也应保留，削减前需测试负责人与产品负责人共同确认并记录延后原因。
环境阻塞导致大量用例跑不了，这种情况还要不要重排范围？
先清理阻塞，暂缓动用例。环境或数据阻塞往往可以当天或次日解决，清理后执行速度会立刻恢复，此时削减范围属于误伤。建议安排专人当日攻坚阻塞项，同时观察一个工作日左右的执行趋势：如果阻塞解除后完成数回升到计划水平，说明缺口来自环境而非范围，不需要重排；如果阻塞清理后仍明显落后，再进入分级取舍。判断依据以阻塞记录、环境可用时间和每日执行完成数为准。
重排后削减的范围，需要谁确认、怎么留痕？
可压缩和可延后范围的削减，通常由测试负责人与产品负责人共同确认。留痕要求包括：在用例或测试计划中记录延后原因、影响的功能范围、计划补测时间，跳过或延后的用例保留原状态并标注处置结论，避免被误认为已通过。涉及监管或合同约定的测试项不能跳过，需单独说明。ONES 测试管理支持为用例库、测试计划单独配置权限，便于把范围调整与确认记录限定在相关角色内。
退出条件里的阈值应该在什么时候定，临近结束再定行不行？
建议在重排范围时一并确定阈值，与分级结果同步落地。常见口径是必测范围执行完成率100%、关键路径无阻断级失败、遗留缺陷中高等级为零或已获书面接受。临近结束才定阈值，容易在进度压力下临时放宽标准，使退出判断失去约束力。阈值确定后写入测试计划或重排记录，退出评估时逐项对照，未达标项需说明原因和后续安排。
重排之后怎么防止下一个迭代再次出现同样的滞后？
把重排时的判断转成日常机制：每天对比计划完成数与实际完成数，偏差连续出现时提前预警；阻塞项当日清理，不积压到周末；范围发生变更时重新评估工期，把新增用例的工作量纳入计划。ONES 测试管理提供测试计划的多维度概览和测试情况概览，可查看计划进度与通过率，适合作为每日执行跟踪的查看入口。每日趋势预警的具体统计口径，选型时可按团队实际需要核验。
