迭代中后期发现测试执行落后，先别急着加人或压缩用例。更可靠的做法是核对统计口径，确认偏差是否真实存在；再沿“输入就绪—执行阻塞—返工回流—人力投入”的执行链路逐层验证，用数据区分假设与结论。本文给出偏差核对表、原因假设清单和带停止点的排查步骤，并在排查与跟踪环节说明ONES测试管理可承载的执行记录方式。
要点总览（TL;DR）
- 先按同一基数重算计划执行量、实际执行量、剩余用例和剩余工作日，排除用例拆分、计划调整、统计时点不一致造成的假偏差。
- 口径确认后按“输入就绪—环境阻塞—返工回流—人力投入”列出原因假设，每个假设配一项可核对数据，命中即停。
- 排查从低成本数据入手：版本到达时间与变更记录、阻塞用例分布、返工占比、人力与执行速率，逐步收敛主因。
- 恢复动作与主因对应，用连续两到三个统计周期的执行速率和剩余用例/剩余工作日比值验证恢复。
- 把偏差发生时间、主因、处置动作和恢复时点记录下来，作为下一次偏差定位的比对依据。
先确认偏差是真实落后还是口径问题
进度偏差的第一层判断是：按同一口径重算后，落后是否仍然存在。迭代中后期常见的“看起来落后”，有一部分来自统计口径变化，而非执行量真的减少。先做这一步，可以避免后续排查建立在错误基数上。
量化偏差需要四个数：计划执行量、实际执行量、剩余用例数、剩余工作日。用剩余用例除以剩余工作日，得到当前所需的日均执行量，再与计划日均执行量对比。两个日均值的差距，比“完成了百分之多少”更能反映真实压力。
| 核对项 | 计划值 | 实际值 | 统计时点 | 口径差异 | 修正后偏差 |
|---|---|---|---|---|---|
| 用例总数 | 例如 320 条 | 例如 350 条 | 迭代第 8 天 | 中途新增 30 条 | 按 350 条重算 |
| 已执行用例 | 例如 200 条 | 例如 180 条 | 同一天 18:00 | 统计时点不同 | 统一到同一时点 |
| 剩余用例 | 例如 120 条 | 例如 170 条 | 同一天 18:00 | 含新增与失效用例 | 剔除失效后重算 |
| 剩余工作日 | 例如 5 天 | 例如 4 天 | 同一天 18:00 | 节假日口径不同 | 按团队日历统一 |
常见口径误差有四类。一是用例拆分变更，原有一条用例拆成多条后，执行量分子被放大；二是计划中途调整，范围增加但计划基数未同步更新；三是统计时点不一致，早会数据与下班前数据混用；四是重复计入，同一用例在多轮执行中被多次统计为“已执行”。逐项核对后，若修正偏差明显缩小甚至消失，说明问题主要在统计规则，应先统一口径再谈恢复。
范围上，本文只讨论测试运行过程，即用例从分配到执行完成的这一段。缺陷修复闭环与验证跟踪、测试报告与质量评估属于另外的主题，排查时可以把它们作为返工量的输入，但不展开其内部流程。
按执行链路列出原因假设与排除证据
口径确认后仍有偏差，就进入原因排查。有效的方式是先列出假设，再为每个假设指定一项可核对的数据，用数据决定保留还是排除。以下四类假设覆盖了测试执行链路的主要环节，排查时不必全部走完，命中即停。
| 原因假设 | 典型表现 | 验证数据 | 排除证据 |
|---|---|---|---|
| 输入未就绪 | 用例已分配但无版本可测 | 待测版本实际到达时间与计划到达时间之差；需求变更记录条数及影响用例数；测试数据准备完成时间 | 版本按计划到达、变更未影响待测范围、测试数据在计划开始前已就绪 |
| 环境与工具阻塞 | 用例处于“待执行”但无人推进 | 环境不可用时长；账号权限申请与开通时间；自动化任务失败次数与恢复时间 | 环境可用时长覆盖计划执行窗口，自动化任务失败未影响手工执行 |
| 执行能力不足 | 执行速率持续低于计划 | 实际投入人天与计划人天；执行人技能覆盖与用例复杂度分布；单人日均执行量 | 人力投入达到计划，单人执行速率与历史基线一致 |
| 返工回流 | 已执行用例被重新打开 | 返工用例数占已执行用例比例；缺陷集中模块分布；失效用例重写数量 | 返工占比低于历史常态，重测未挤占新用例执行时间 |
排查顺序建议按“输入—阻塞—返工—能力”推进。输入问题通常最先发生且影响面最大，版本延迟会直接压缩后续所有执行窗口；阻塞问题次之，它决定已分配用例能否真正跑起来；返工量需要等执行推进到一定阶段才显现；人力与速率属于结果性指标，放在最后用于解释剩余缺口。这个顺序也符合证据获取成本：版本到达时间和变更记录容易查，阻塞分布需要按原因归类，返工占比需要跨轮次比对。
每个假设都要落到具体数据，避免用“感觉人手不够”直接下结论。例如判断能力因素时，应比较计划投入人天与实际投入人天，并看单人日均执行量是否偏离历史基线；如果人力到位而速率下降，更可能指向用例复杂度上升或环境等待，而不是单纯缺人。
按顺序执行的排查步骤
把假设转化为动作，需要一份有顺序、有判断条件、有停止点的步骤表。每一步都产出可记录的数据，命中主因后停止后续步骤，避免过度排查。
| 步骤 | 动作 | 判断条件 | 停止点 |
|---|---|---|---|
| 第一步 | 核对计划口径与统计时点，按同一基数重算偏差 | 修正后偏差消失或低于阈值 | 确认为口径问题，转入口径统一，不再往下排查 |
| 第二步 | 查待测版本到达时间与需求变更记录 | 版本延迟或变更影响待测用例，且延迟时长可解释大部分缺口 | 确认输入未就绪为主因，转入补输入动作 |
| 第三步 | 统计阻塞用例数及阻塞原因分布 | 阻塞用例占比高，且集中在环境、权限或依赖 | 确认阻塞为主因，转入解阻塞动作 |
| 第四步 | 统计返工用例占比与缺陷重测分布 | 返工占比明显高于历史常态，重测挤占新用例执行 | 确认返工为主因，转入压缩返工动作 |
| 第五步 | 核对人力投入与执行速率变化 | 人力缺口或单人速率持续低于基线 | 确认能力因素为主因，转入调人力动作 |
执行这套步骤时有两个操作风险需要提前交代。第一，调整计划或重新分配用例前，先备份当前执行记录，包括每条用例的执行状态、执行人、执行时间和关联缺陷，避免重排后丢失原始数据，导致后续无法复盘。第二，为排查设定时间盒，例如半天内完成前四步，若仍未收敛，先按最可能的假设采取临时措施，再继续验证，避免排查本身拖慢执行。
数据记录方式直接影响排查效率。如果执行状态、执行人和阻塞原因分散在表格、聊天记录和缺陷系统里，统计阻塞分布和返工占比会耗费大量时间。ONES 测试管理支持测试计划的规划和执行，并可多维度概览全部测试计划，进度一目了然；用例可分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转。把执行状态与阻塞记录统一在测试计划下，排查时按执行人、状态筛选即可得到分布数据，减少手工汇总。具体统计维度和阻塞标记方式以团队实际配置为准。
确认主因后的恢复动作与复发预防
主因确认后，恢复动作应与原因一一对应，避免所有偏差都用“加班赶进度”处理。补输入针对版本延迟与数据缺失，优先与研发确认可测版本的最早时间，并调整用例执行顺序，先跑不依赖该版本的用例；解阻塞针对环境与权限，集中清理阻塞清单，按影响用例数排序处理；调人力针对真实的人力缺口，从低优先级任务抽调或调整执行范围；压缩返工针对缺陷集中模块，先聚焦高返工区域的用例复核，减少无效重测。
恢复是否有效，要用指标验证，而不是看某一天的执行量。建议连续观察两到三个统计周期，确认日均执行速率回到计划区间，且剩余用例与剩余工作日的比值持续下降。如果速率回升但剩余用例同步增加，说明范围仍在变化，需要先冻结范围再评估。
复发预防落在计划与跟踪两个环节。计划中为版本到达和環境准备预留缓冲，把待测版本到达时间写成计划的前置条件；执行期间建立阻塞用例的每日跟踪，当天记录、当天归类、当天指定处理人；迭代复盘时回看偏差发生时间、主因、处置动作和恢复时点，形成可复用的判断依据。ONES 测试管理支持测试计划与迭代关联，测试情况概览可查看测试计划的进度和通过率，用例属性支持筛选，便于按状态定位阻塞用例和返工用例。把这些记录留在同一测试计划下，下一次出现偏差时可以直接比对历史数据，缩短定位时间。
常见问题
迭代只剩几天，排查偏差会不会反而耽误执行？
排查本身需要设时间盒。建议半天内完成口径核对、版本到达时间和阻塞分布这三步，多数偏差在这一段就能收敛。若仍未定位，先按最可能的假设采取临时措施，例如先跑不依赖延迟版本的用例、集中清理阻塞清单，同时继续验证。排查与处置可以并行，前提是每一步都产出可记录的数据，而不是反复开会讨论。
执行速率回升了，但剩余用例也在增加，算恢复了吗？
不算。速率回升与剩余用例同步增加，通常说明范围仍在变化，执行量被新增用例抵消。此时应先冻结或确认范围变更，再按新的用例总数重算剩余工作日，观察剩余用例与剩余工作日的比值是否持续下降。只有比值下降，才说明执行压力真正缓解。
阻塞用例的统计口径应该怎么定，才能用于排查？
关键是每条阻塞用例都记录阻塞原因、发生时间和处理人，并按原因归类。统计时用阻塞用例数占已分配未执行用例的比例，比绝对数量更能反映影响。如果执行状态、阻塞原因分散在表格和聊天记录里，统计成本会很高；把执行状态与阻塞记录统一在测试计划下，按执行人和状态筛选即可得到分布。ONES 测试管理支持测试计划的规划和执行，并可多维度概览全部测试计划，用例可分配执行人，便于按状态定位阻塞用例。
返工量怎么算进进度偏差，才不会和缺陷修复流程混在一起？
本文只把返工量作为执行环节的输入：统计已执行用例被重新打开的数量占已执行用例的比例，以及缺陷重测占用的执行时间。缺陷从提交到关闭的完整闭环属于缺陷修复与验证跟踪主题，不在本文展开。若返工占比明显高于历史常态，且重测挤占新用例执行时间，可判定返工回流是主因之一，处置方向是聚焦高返工模块的用例复核，减少无效重测。
偏差定位完成后，需要留下哪些记录供下次比对？
至少记录四项：偏差发生时间、确认的主因、采取的处置动作、恢复时点。若团队使用统一平台跟踪测试计划，这些记录可与执行状态、阻塞原因留在同一测试计划下，下一次出现偏差时直接比对历史数据。ONES 测试管理提供测试情况概览，可快速了解测试计划的进度和通过率，并支持用例属性筛选，便于回看当时的执行与阻塞情况。
