迭代中后期发现测试执行落后，先别急着归因于“执行慢”。更可靠的做法是先把偏差量化到具体模块、用例和执行人，再按计划口径、用例阻塞、环境数据、缺陷积压、人力投入逐层核对证据，排除掉不成立的假设。确认原因后安排处置，并用同一口径复检恢复情况。本文聚焦测试运行过程，缺陷修复闭环与测试报告编制不在讨论范围内。
要点总览（TL;DR）
- 先把“进度落后”量化成偏差量、集中模块、起始时点和涉及执行人，算出所需日均执行量，再启动排查。
- 按顺序逐层核对：计划口径是否变化、用例是否被阻塞、环境与数据是否可用、缺陷是否积压、人力是否被挤占，每层都要有支持证据和排除证据。
- 确认原因后按类处置：重定基线、分组解阻、调整环境优先级、单列阻塞缺陷、重排任务或调整范围，并明确责任人与停止点。
- 处置后两到三个工作日复检，用同一口径对比日均执行量和阻塞用例数，避免口径变化造成假恢复。
- 把成立的原因沉淀为阻塞日报、环境看板、缺陷滞留提醒等日常检查项，并设定触发再排查的阈值。
先界定偏差：落后多少、落在哪里
“进度落后”本身是主观判断，排查前需要把它转换成可核对的范围描述。一个可用的偏差描述至少包含四项信息：偏差量、集中位置、起始时点、涉及人员。缺其中任何一项，后续排查都容易停留在印象层面。
用四个数字确定偏差量
先取同一时点的计划执行数、实际执行数、剩余天数和剩余用例数，算出所需日均执行量。例如计划在本迭代执行400条用例，当前应执行300条、实际执行240条，剩余5个工作日、剩余160条，则所需日均执行量从原计划的20条上升到32条。这个数字比“落后20%”更有行动意义，因为它直接说明后续每天要补多少。
计算时注意口径一致：计划执行数按当前有效计划统计，实际执行数只计入达到“已执行”标准的用例，避免把部分执行、重复执行混入。口径不一致会人为放大或缩小偏差。
按模块、优先级、执行人、环境拆分分布
总量偏差往往由少数集中区域造成。把偏差按四个维度拆开，可以快速缩小排查范围：
- 按模块：哪些模块的未执行用例占比明显高于整体水平，偏差是否集中在某几个模块。
- 按用例优先级：高优先级用例是否已基本执行完，剩余的是否以低优先级为主。若高优先级用例大量未执行，偏差性质更严重。
- 按执行人：各执行人的计划任务量与实际完成量是否匹配，是否存在个别执行人任务堆积。
- 按测试环境：不同环境上的执行进度是否分化，是否有一组用例因环境原因整体停滞。
确认偏差起始时间点
把每日实际执行量与计划日均量对比，找出从哪一天开始持续低于计划线。单日波动通常由任务切换或临时会议造成，连续两到三日低于所需日均值才值得作为偏差起点。区分持续落后与单日波动，可以避免为偶发情况启动完整排查。
完成以上三步后，应形成一份偏差范围描述，例如：“本迭代第8个工作日起，支付模块剩余未执行用例62条，其中高优先级18条，集中在两名执行人和测试环境B上，所需日均执行量由20条升至32条。”这份描述就是后续排查的对象清单。
逐层排查：从计划口径到执行阻塞
偏差范围确定后，按“先核对口径、再查执行受阻、最后查资源投入”的顺序逐层验证。顺序有讲究：计划口径变化会让所有执行数据失去可比性，必须先排除；执行受阻类原因可以用用例状态数据直接验证；人力投入类原因通常放在最后，因为它常是其他问题的结果而非起点。
假设一：计划口径发生变化
范围新增、用例拆分、排期调整都会让“计划执行数”本身变大，此时实际执行并未变慢，是分母变了。验证方法是核对计划变更记录与基线版本：当前计划相比迭代启动时的基线，新增了多少用例、是否有用例被拆分导致条数增加、排期是否被压缩。
支持证据：存在明确的计划变更记录，且变更量与偏差量大致吻合。排除证据：计划自基线确定后未发生实质变更，或变更量远小于偏差量。若组织内没有保留计划基线，这一层只能标记为待验证，转而依靠其他层的证据判断。
假设二：用例被阻塞
依赖未就绪、前置用例未通过、环境不可用，都会让用例停留在无法执行的状态。验证方法是统计阻塞用例数量及其原因分布：阻塞用例占总剩余量的比例是多少，主要集中在哪些阻塞原因上。
支持证据：阻塞用例数足以解释大部分偏差，且阻塞原因集中。排除证据：阻塞用例占比很低，或阻塞集中在低优先级用例上、不影响关键路径。需要注意，阻塞状态需要有明确的标记和记录才能统计；如果团队只靠口头同步阻塞情况，应先补上记录再判断。
假设三：测试数据与环境可用性不足
环境被其他任务占用、测试数据未准备好，会造成执行人“有任务但无法开工”。验证方法是核对环境占用记录、数据准备工单与实际等待时长：偏差期间环境被占用的时段有多长，数据准备工单从提出到交付的平均时长是否明显拉长。
支持证据：环境占用时段与执行量低谷时段重合，或数据等待时长足以覆盖偏差量。排除证据：环境在整个偏差期间可用，数据准备按时交付。这一层排查依赖环境与数据相关记录的可获取性，记录缺失时应通过执行人访谈补充，并标注证据来源。
假设四：缺陷积压导致无法继续执行
阻塞级缺陷未修复时，相关用例无法继续执行或执行后无法验证。验证方法是看阻塞级缺陷的数量与平均滞留时长：偏差期间新增多少阻塞级缺陷，从提交到修复的平均时长是否超出约定时限。
支持证据：阻塞级缺陷数量与滞留时长足以解释停滞的用例范围。排除证据：阻塞级缺陷数量少、流转及时。这里只判断缺陷是否阻塞了测试执行；缺陷本身的修复闭环流程属于缺陷修复与验证跟踪主题，本文不展开。
假设五：执行人力被抽调或并行任务挤占
执行人被临时抽调支持其他项目，或同时承担多项任务，实际投入低于计划投入。验证方法是对比计划投入与实际投入：按人统计计划分配的用例量与可用工时，再对照实际执行记录和任务分配变化。
支持证据：存在明确的人员抽调记录或并行任务分配，且时间与偏差起点吻合。排除证据：执行人投入稳定，任务分配未发生明显变化。人力因素常与其他原因叠加，例如环境不可用导致执行人转去做其他工作，此时应把环境问题作为主因。
用一张表并列核对假设与证据
| 原因假设 | 支持证据 | 排除证据 | 当前判定 |
|---|---|---|---|
| 计划口径变化 | 存在计划变更记录，变更量与偏差量吻合 | 计划自基线后无实质变更 | 成立／排除／待验证 |
| 用例被阻塞 | 阻塞用例数足以解释偏差，原因集中 | 阻塞占比低或集中在低优先级 | 成立／排除／待验证 |
| 环境与数据不足 | 占用时段与执行低谷重合，等待时长覆盖偏差 | 环境全程可用，数据按时交付 | 成立／排除／待验证 |
| 缺陷积压 | 阻塞级缺陷数量与滞留时长足以解释停滞 | 阻塞级缺陷少且流转及时 | 成立／排除／待验证 |
| 人力被挤占 | 有抽调记录，时间与偏差起点吻合 | 投入稳定，任务分配未变 | 成立／排除／待验证 |
排查时允许同时存在多个成立的原因，但应区分主因与次因：能解释大部分偏差量的为主因，处置资源优先投向主因。证据不足的假设保持“待验证”，不要为了尽快给出结论而把它写成成立。
在记录层面，排查依赖三类可核对的数据：用例的执行状态与分配执行人、计划的范围与变更痕迹、阻塞与缺陷的流转记录。ONES 测试管理提供测试计划的多维度进度概览和通过率查看，用例可分配执行人，用例属性支持筛选，便于按模块、执行人等条件圈定偏差范围；未通过用例可快速创建缺陷任务并在测试与研发团队间流转。计划基线与变更历史的记录方式，需结合团队实际配置确认后再作为排查依据。
按排查结果安排处置动作
原因确认后，处置动作要与原因一一对应，并明确责任人、前置条件和停止点。笼统地“加加班、赶一赶”只能短期掩盖问题，无法阻止同类偏差再次出现。
计划口径变化：重定基线并同步
若确认是范围新增或排期压缩导致偏差，应基于当前有效范围重新确定执行基线，并把新基线同步给测试、研发和项目干系人。继续用旧基线判断进度，会让团队持续处于“虚假落后”状态，也会掩盖真实的执行问题。重定基线前保留原基线记录，便于后续追溯范围变化。
阻塞用例：按原因分组解阻
把阻塞用例按阻塞原因分组，每组指定解阻责任人和解阻时点。依赖未就绪的，明确依赖方的交付时间；前置用例未通过的，优先安排前置用例复测；环境原因导致的，转入环境处置。解阻时点应具体到日期，并与复检时点对齐。
环境与数据：调整优先级或提前准备
环境被占用时，与占用方协商调整占用优先级，或为测试执行划定固定时段；数据准备滞后时，把数据准备提前到用例执行之前，按批次预置。这类调整会影响并行任务，处置时应说明对哪些任务造成影响、影响时长多少，由相关方确认后再执行。
缺陷积压：单列阻塞执行的缺陷
把阻塞测试执行的缺陷单独列出，标注影响的用例范围，优先推进修复。处置动作聚焦于“解除执行阻塞”，缺陷修复完成后的验证与闭环流程按缺陷修复与验证跟踪的既定流程执行，不在本文展开。
人力挤占：重排任务或调整范围
执行人被抽调时，要么重新分配执行任务、补充人力，要么调整本迭代的测试范围。调整范围需要明确取舍：优先保障高优先级用例和关键路径模块，低优先级用例可顺延并记录顺延原因。范围取舍应由测试负责人与项目负责人共同确认，避免单方面缩减造成质量风险。
处置动作表与风险边界
| 原因 | 处置动作 | 责任人 | 前置条件 | 风险与停止点 |
|---|---|---|---|---|
| 计划口径变化 | 重定执行基线并同步干系人 | 测试负责人 | 确认当前有效范围 | 保留原基线记录；范围争议未决时暂停重定 |
| 用例阻塞 | 按原因分组，明确解阻责任人与时点 | 各阻塞原因对应负责人 | 阻塞原因已分类 | 依赖方无法承诺时点时上报项目负责人 |
| 环境与数据 | 调整环境占用优先级、提前准备数据 | 测试环境管理员、数据准备人 | 与占用方达成一致 | 影响并行任务需相关方确认；冲突未解时保留原安排 |
| 缺陷积压 | 单列阻塞执行的缺陷并优先推进 | 研发负责人 | 阻塞缺陷清单已确认 | 修复验证按缺陷流程执行，不跳过验证直接关闭 |
| 人力挤占 | 重排执行任务或调整测试范围 | 测试负责人、项目负责人 | 范围取舍方案已确认 | 缩减范围须记录并评估质量风险 |
涉及重排计划、关闭或顺延用例等有破坏风险的操作，执行前先确认原记录可保留或已备份，并设定停止点：例如范围调整方案未获确认前不修改计划，阻塞依赖未明确前不关闭相关用例。
验证恢复并防止再次偏离
处置动作落地后，需要设定复检时点和指标，确认偏差确实收敛。复检的核心指标有两个：日均执行量是否回到所需水平，阻塞用例数是否下降。复检时点建议设在处置后两到三个工作日，给动作留出生效时间，又不至于拖到迭代结束才发现无效。
用同一口径对比处置前后
复检时必须沿用界定偏差时的口径：同样的计划范围、同样的执行完成标准、同样的统计维度。如果处置过程中重定了基线，应分别记录“按旧基线”和“按新基线”两组数据，避免口径变化造成假恢复。例如新基线缩小了范围，执行率自然上升，但这不代表执行速度改善，需要结合日均执行量单独判断。
把确认的原因沉淀为日常检查项
本次排查中成立的原因，应转化为迭代期间的常规检查项，让同类问题在造成明显偏差前被发现：
- 阻塞用例日报：每日统计新增阻塞用例数与解阻数，阻塞超过约定时长的用例单独提示。
- 环境占用看板：展示测试环境的占用时段与预约情况，执行前可提前确认可用性。
- 阻塞级缺陷滞留提醒：对超过约定时限未修复的阻塞级缺陷设置提醒。
- 计划变更登记：范围新增或排期调整时登记变更，保持基线与实际范围一致。
设定触发再排查的阈值
为偏差设置明确的预警线，例如连续两日实际执行量低于所需日均值的80%，或阻塞用例数单日新增超过剩余量的10%，即触发一次简化版排查。阈值应结合迭代长度和执行规模设定，并在迭代回顾时根据实际触发情况调整。阈值过松会错过早期信号，过紧则造成频繁排查、消耗执行精力。
复检结束后，把偏差范围描述、原因判定、处置动作和复检结果整理成一份简短记录，作为下次迭代计划时的参考。这份记录同时回答了三个问题：偏差发生在哪里、为什么发生、处置是否有效，也为团队积累可复用的排查经验。
常见问题
迭代中后期才发现进度落后，排查还来得及吗？
来得及，但排查范围要收窄。此时剩余时间有限，建议优先核对两类最可能解释大部分偏差的原因：计划口径是否在迭代中发生变化，以及阻塞用例是否集中在关键路径上。这两类原因一旦确认，处置动作相对明确，能在剩余时间内看到执行量变化。环境和人力类原因可以并行收集证据，但不必等全部假设验证完再开始处置。复检时点设在处置后两到三个工作日，确保迭代结束前能判断动作是否有效。
团队没有记录计划基线，还能区分计划口径变化和执行受阻吗？
可以部分区分，但结论需要标注证据强度。没有基线记录时，可以通过访谈和间接材料还原：对比迭代启动时的范围说明与当前用例清单，核对需求变更单和排期调整通知，询问执行人是否记得范围在何时扩大。如果变更量能与偏差量大致对上，可判为“可能成立”；如果找不到变更痕迹，这一层标记为“待验证”，转而依靠阻塞、环境、缺陷等层的证据判断。后续迭代建议保留计划基线，避免同类排查反复受限于记录缺失。
多个原因同时成立时，处置资源应该先投向哪里？
先区分主因与次因。能解释大部分偏差量的原因作为主因，处置资源优先投向主因；次因可以并行安排轻量动作，但不占用主要精力。例如阻塞用例数足以解释七成偏差，人力挤占只解释两成，则应先集中解阻，人力调整作为辅助。如果两个原因相互叠加、难以拆分，例如环境不可用导致执行人转做其他任务，应把环境问题作为主因处置，因为它是起点。主因处置后复检执行量变化，再判断次因是否需要单独处理。
复检时执行率上升了，但日均执行量没变，算恢复了吗？
不算。执行率上升可能来自计划范围缩小或基线重定，属于口径变化造成的假恢复。判断恢复的核心指标是日均执行量是否回到所需水平，以及阻塞用例数是否下降。复检时应同时看两组数据：按旧口径的日均执行量，和按新口径的执行率。如果日均执行量仍低于所需值，说明执行速度没有实质改善，需要回到排查层继续找原因。把口径变化单独记录，可以避免在迭代回顾时误判处置效果。
阻塞用例的记录不规范，只有口头同步，怎么排查？
先补记录再判断。可以花半天时间让执行人集中标注当前无法执行的用例及原因，形成一份临时阻塞清单，按依赖未就绪、前置用例未通过、环境不可用等类别分组。这份清单的证据强度低于日常记录，结论中应注明来源为临时补录。如果临时清单显示阻塞用例占比很低，可以初步排除阻塞假设；如果占比高且原因集中，则阻塞很可能成立，同时应把阻塞标记纳入日常执行规范，避免下次排查再依赖补录。
