测试执行暂停恢复要解决的是执行过程被打断后如何有序收口、再安全接续的问题。本文按“管什么—怎么做—谁负责—怎么示范—如何检查”的顺序，给出可落地的流程、角色分工与检查清单，适用于测试计划已进入执行阶段、因环境、版本或依赖问题需要中断的场景。
要点总览（TL;DR）
- 暂停恢复要管住四类对象：执行批次、用例执行状态、环境与版本、阻塞项；暂停记录至少写明原因、时点、已完成与未完成用例、阻塞项负责人、恢复条件和环境版本快照。
- 暂停由测试负责人依据约定触发条件宣布，执行人发现异常先上报；局部用例阻塞可先标记，是否升级为批次暂停由测试负责人判断。
- 恢复前逐项核验三件事：阻塞解除证据、环境与版本一致性、用例状态是否被误改；核验不通过就回到阻塞项处理，不进入续跑。
- 恢复后从断点续跑未完成用例，并对暂停期间的需求或版本变更做影响分析，补测清单要落到具体用例编号。
- 角色上区分测试执行人、测试负责人、环境/配置管理员、需求与开发接口人，以暂停单、恢复核验单、执行状态记录作为交付物，决策与核验保持可追溯。
暂停与恢复要管住哪些对象和状态
暂停恢复管理的范围是测试运行过程本身，核心对象有四类：执行批次、用例执行状态、环境与版本、阻塞项。执行批次指一次测试计划下正在推进的那一轮执行，暂停时要明确这一轮里哪些用例已执行、哪些未执行、哪些执行中被中断。用例执行状态是暂停期间最容易被误改的数据，需要区分“通过、失败、阻塞、未执行”并保留暂停时点的快照。环境与版本决定恢复后结果是否可比，暂停时必须记录当时使用的环境标识、被测版本号与必要的配置信息。阻塞项则是暂停的直接原因，需要登记负责人和解除条件。
围绕这四类对象，暂停记录至少应包含以下字段，团队可按实际裁剪：
| 字段 | 填写内容 | 作用 |
|---|---|---|
| 暂停原因 | 环境故障、版本变更、关键依赖阻塞、数据或账号不可用等 | 判断恢复条件是否具备 |
| 暂停时点 | 日期时间与当前执行批次 | 界定冻结范围的时间边界 |
| 已完成用例 | 用例编号与执行结果 | 恢复后不重复执行 |
| 未完成用例 | 用例编号与中断时的状态 | 确定续跑起点 |
| 阻塞项负责人 | 具体到人 | 推动解除，避免悬空 |
| 恢复条件 | 可核验的解除标准 | 作为恢复决策依据 |
| 环境与版本快照 | 环境标识、被测版本、关键配置 | 保证恢复后结果可比 |
需要划清边界：暂停恢复管的是“执行能不能继续、从哪里继续”，缺陷的修复与验证闭环属于缺陷管理流程，测试报告的汇总与质量评估属于报告输出环节，两者都不在本流程内展开。暂停记录中出现的失败用例可以关联缺陷，但缺陷状态流转不决定测试执行能否恢复。
核心步骤：从触发暂停到恢复续跑
整个流程分四步，每步都有明确的输入、动作、输出和完成标志，缺一项就容易在恢复时出现口径不一致。
第一步：触发与决策
输入是执行过程中出现的异常信号，例如环境不可用、被测版本被替换、关键依赖方未交付、测试数据或账号失效。动作是由测试负责人依据事先约定的触发条件判断是否暂停，并宣布暂停范围（整个批次还是部分用例）。输出是暂停决定与暂停范围说明。完成标志是执行人收到暂停通知并停止新增执行。决策权应集中在测试负责人，执行人发现异常时上报，不自行决定全批次暂停；局部用例因单点数据问题无法执行时，可由执行人标记阻塞并上报，是否升级为批次暂停由测试负责人判断。
第二步：暂停执行
输入是暂停决定。动作包括三项：冻结执行范围，停止对未完成用例的继续执行；保存执行进度，把已完成与未完成用例清单固化下来，形成暂停时点的状态记录；登记阻塞项与环境快照，写明阻塞项负责人、恢复条件和当前环境版本信息。输出是暂停单与执行状态记录。完成标志是暂停单字段填写完整、执行人确认状态已冻结、阻塞项已有明确负责人。
第三步：恢复前核验
输入是阻塞项负责人提交的解除说明。动作是逐项核验三件事：阻塞解除证据是否齐备，例如环境恢复的确认、版本回退或重新发布的记录；环境与版本是否与暂停时一致，若已发生变更，是否完成了变更影响分析；用例状态是否被误改，将当前状态与暂停时点快照比对。输出是恢复核验单，逐项写明核验结论。完成标志是三项核验全部有结论，且由测试负责人签字确认可以恢复。核验不通过时回到阻塞项处理，不进入恢复执行。
第四步：恢复执行
输入是已确认的恢复核验单。动作是从断点续跑，先执行暂停时未完成的用例，再处理暂停期间的变更影响：若需求或版本在暂停期间发生变更，需分析受影响的用例并纳入补测范围；补测范围要写明具体用例编号，避免只写“相关用例”。输出是续跑记录与补测清单。完成标志是未完成用例全部执行完毕、补测清单中的用例执行完毕、执行状态记录更新到最新。
角色分工与交付物
暂停恢复涉及四类角色，职责要分开，尤其决策与核验不宜由同一人独自承担。团队规模较小时可以合并角色，但暂停决策人和恢复核验人应保持可追溯。
| 角色 | 主要职责 | 产出 |
|---|---|---|
| 测试执行人 | 发现异常并上报，执行暂停动作，冻结并保存执行进度，恢复后从断点续跑 | 执行状态记录、续跑记录 |
| 测试负责人 | 依据触发条件决定暂停与恢复，确认暂停范围，审核恢复核验结论 | 暂停决定、恢复确认 |
| 环境/配置管理员 | 提供环境与版本快照，处理环境故障，出具阻塞解除证据 | 环境版本记录、解除说明 |
| 需求与开发接口人 | 说明暂停期间的需求或版本变更，配合完成变更影响分析 | 变更说明、影响分析输入 |
交付物有三份，归属和流转要固定下来。暂停单由测试执行人填写、测试负责人确认，作为暂停时点的正式记录。恢复核验单由测试负责人组织填写，环境/配置管理员和需求接口人提供核验证据，测试负责人确认后方可恢复。执行状态记录贯穿全程，由执行人维护，恢复完成后归档。交接时点有两个：暂停宣布时，执行人向测试负责人交接执行进度；恢复确认时，测试负责人向执行人交接核验结论。确认方式建议采用书面确认，例如在记录中留下确认人和确认时间，口头通知只作为即时提醒。
当团队使用 ONES 承载测试计划执行时，用例可分配执行人，测试计划与迭代关联，执行进度可在计划视图中查看；暂停单与恢复核验单可借助文档协作记录，并通过为测试计划单独配置权限控制谁能修改执行状态。这样暂停时点的状态记录与恢复核验结论有统一的存放位置，交接时不必依赖个人记忆。
示例：一次环境故障导致的暂停与恢复
以下为演示情景，用于说明字段填写与判断过程，不代表真实项目数据。
暂停触发与记录
某迭代测试计划进入执行第二天，测试执行人在执行登录相关用例时发现测试环境无法访问，多次重试仍失败。执行人上报测试负责人，测试负责人判断该环境故障影响本批次全部用例，宣布暂停整个执行批次。暂停单记录如下：暂停原因为测试环境不可用；暂停时点为执行第二天上午；已完成用例 42 条，其中通过 38 条、失败 4 条；未完成用例 26 条，状态为未执行；阻塞项负责人为环境/配置管理员；恢复条件为环境恢复可访问并通过冒烟验证；环境与版本快照记录环境标识与被测版本号。执行人确认状态已冻结，未完成用例保持未执行状态。
恢复前核验
环境/配置管理员提交解除说明，称环境已恢复并完成冒烟验证。测试负责人组织核验：阻塞解除证据方面，冒烟验证记录齐备，核验通过；环境与版本一致性方面，环境标识与暂停时一致，被测版本未发生替换，核验通过；用例状态复核方面，将当前状态与暂停时点快照比对，发现 4 条失败用例中有 1 条被改为通过但无执行记录，判定为误改，要求恢复为失败状态并补充执行记录。三项核验完成后，测试负责人确认可以恢复。
续跑范围与补测处理
恢复后执行人先续跑 26 条未完成用例，再处理暂停期间的变更：开发接口人说明暂停期间有一个需求小改动已合入当前版本，影响 3 条用例的预期结果。测试负责人据此将这 3 条用例纳入补测清单，并同步更新其预期结果。续跑与补测完成后，执行状态记录更新为最新，暂停单与恢复核验单归档。
完成检查：暂停恢复是否做到位
一次暂停恢复是否执行到位，可以从记录完整性、恢复核验证据和补测范围三方面逐项核对。以下清单可用于自查或评审。
| 检查项 | 通过标准 |
|---|---|
| 暂停原因是否明确 | 写明具体原因类别，不停留在“有问题” |
| 暂停时点与执行批次是否记录 | 可据此界定冻结范围 |
| 已完成与未完成用例清单是否完整 | 数量与状态可核对 |
| 阻塞项是否有负责人和恢复条件 | 负责人具体到人，恢复条件可核验 |
| 环境与版本快照是否留存 | 环境标识、被测版本、关键配置齐全 |
| 阻塞解除是否有证据 | 有可查的验证记录，非口头说明 |
| 环境与版本是否一致或已完成影响分析 | 不一致时有变更影响分析结论 |
| 用例状态是否与暂停时点快照一致 | 无误改，异常改动有说明 |
| 续跑是否从断点开始 | 未完成用例全部执行，无重复执行 |
| 补测范围是否明确到用例 | 列出具体用例编号，非笼统表述 |
常见遗漏集中在三处。状态误改：暂停期间有人调整了用例状态却未留执行记录，恢复时若不比对快照就会把误改当作已完成。版本不一致：恢复时环境或被测版本已变化，却直接沿用暂停前的执行结果，导致结论不可比。补测范围遗漏：只续跑未完成用例，忽略了暂停期间需求或版本变更带来的影响，补测清单缺失。检查时对这三项应重点核对，发现遗漏先补齐再宣布恢复完成。
常见问题
暂停期间有人改了用例状态，恢复时怎么处理？
恢复前把当前用例状态与暂停时点快照逐条比对，发现与快照不一致且没有执行记录的改动，先恢复为暂停时的状态，再补执行记录或说明。比对结果写入恢复核验单，作为恢复确认的一部分。若改动确实来自暂停期间的有效执行，应补充执行时间、执行人和结果，再更新快照口径，避免把误改和真实执行混在一起。
恢复时发现被测版本已经变了，还能直接续跑吗？
不能直接沿用暂停前的执行结果。先确认版本变更的范围和内容，由需求与开发接口人提供变更说明，测试负责人组织分析受影响的用例，把需要重新执行或调整预期结果的用例列入补测清单。已完成用例中受变更影响的，也要重新执行；未受影响的用例可以保留原结果。版本不一致且未完成影响分析时，恢复核验不通过。
团队规模小，角色可以合并吗？
可以合并。执行人较少时，测试负责人可能同时承担部分执行工作，环境问题也可能由同一人协调。合并后仍要保证两点：暂停决定和恢复确认留下书面记录，写明确认人和时间；决策与核验不由同一人在无记录的情况下独自完成。这样即使角色重叠，事后也能追溯谁在什么时点做出了暂停或恢复判断。
暂停只影响部分用例，也要走完整流程吗？
按影响范围分级处理。单条用例因数据或账号问题无法执行时，执行人标记阻塞并上报，记录阻塞原因和负责人即可，不必宣布批次暂停。当阻塞影响到同一批次的多数用例，或环境、版本层面出现问题，再由测试负责人宣布批次暂停并走完整记录与核验流程。分级标准建议在团队内事先约定，避免每次临时判断。
暂停单和恢复核验单用什么承载比较合适？
关键是让记录有固定存放位置、可追溯到人。可以用团队已有的文档或工作项承载，字段按本文清单裁剪。当测试计划在 ONES 中执行时，用例可分配执行人，测试计划与迭代关联，执行进度可在计划视图中查看；暂停单与恢复核验单可借助文档协作记录，并通过为测试计划单独配置权限控制谁能修改执行状态。这样交接时不必依赖个人记忆。
