制定测试暂停与恢复准则，关键是把“什么情况下停、谁来定、停到什么程度、满足什么条件才能恢复”写成可执行的判定规则。本文按触发信号、角色分工、暂停期间动作、恢复准入和记录留痕五个环节展开，并给出可直接套用的条件表、职责表与检查表，帮助测试负责人起草一份能落地的准则。
要点总览（TL;DR）
- 准则最小结构包含六类要素：暂停触发条件、决策人、通知范围、暂停期间动作、恢复准入条件、记录留痕，每类落到可填写字段。
- 暂停条件从缺陷、环境、阻塞、门槛四类信号定义，阈值按项目风险等级分档设定，并注明批准人与复核周期。
- 测试负责人提出暂停建议并核对恢复条件，项目经理确认暂停与恢复并通知干系人，开发负责人评估修复与环境恢复；紧急情况可先行暂停、事后补记追认。
- 暂停期间把受影响任务标记为暂停或阻塞、补齐缺陷记录、完成影响评估并准备恢复所需的环境复测与回归范围。
- 恢复须逐项核对阻塞缺陷处理、环境复测、冒烟验证与回归范围确认，记录恢复时间与决策人并向同一范围发出恢复通知。
暂停与恢复准则要写清哪几件事
一份可执行的准则，最小结构应包含六类要素：暂停触发条件、决策人、通知范围、暂停期间动作、恢复准入条件、记录留痕。这六类要素分别回答“何时停”“谁拍板”“告诉谁”“停着做什么”“凭什么恢复”“事后怎么查”六个问题，缺任何一项，准则在执行时都会退回到个人判断。
建议以字段表的形式组织准则文档，每类要素落到可填写、可勾选的具体字段，避免只写原则性描述。下表给出要素与字段的对应关系。
| 要素 | 建议字段 | 填写要求 |
|---|---|---|
| 暂停触发条件 | 信号类别、阈值、适用范围（项目风险等级）、判定人 | 每类信号至少一条可量化或可核验的条件 |
| 决策人 | 建议人、确认人、参与评估人、紧急情况授权人 | 写明角色而非姓名，姓名随项目任命更新 |
| 通知范围 | 通知对象、渠道、时限、通知模板 | 区分内部测试团队与跨团队干系人 |
| 暂停期间动作 | 任务状态标记、缺陷记录要求、影响评估项、恢复准备项 | 每项动作有责任人和完成标志 |
| 恢复准入条件 | 阻塞缺陷状态、环境复测结果、冒烟通过标准、回归范围 | 逐项可验证，核对通过才宣布恢复 |
| 记录留痕 | 暂停时间、触发信号、决策人、影响评估、恢复时间、恢复依据 | 与测试计划、缺陷记录相互关联 |
准则需要与两份既有文档衔接：在测试计划中引用准则编号，说明本项目适用的阈值等级；在缺陷管理流程中约定严重度分级口径，使“致命/严重缺陷数量”这类阈值有统一的统计基础。两处口径不一致，阈值判定就会失真。
暂停条件怎么定：从缺陷、环境、阻塞和门槛四类信号入手
“问题严重就停”无法执行，需要把四类信号转成可判定的条件。阈值设定的一般方法是：先按项目风险等级划分适用档位，再为每档给出具体数值或状态描述，最后指定判定人。核心交易类、对外发布类项目取严档，内部工具类项目可取宽档，同一份准则内分档列出，避免一刀切。
| 信号类别 | 可判定条件示例 | 判定人 |
|---|---|---|
| 缺陷类 | 出现致命缺陷且无临时规避方案；或严重缺陷在核心模块集中出现并超过本档阈值 | 测试负责人 |
| 环境类 | 测试环境不可访问、版本部署失败、测试数据不可信导致用例无法有效执行 | 测试负责人与环境负责人共同确认 |
| 阻塞类 | 关键路径依赖的接口或模块未交付，导致本迭代核心用例无法执行 | 测试负责人提出，项目经理确认 |
| 门槛类 | 冒烟通过率低于本档设定值；或回归通过率持续低于准入门槛 | 测试负责人 |
阈值设定有三点需要注意。第一，缺陷类阈值应同时看数量与分布，核心模块集中出现的严重缺陷比分散出现更值得暂停。第二，环境类条件要写清“不可用”的具体表现，例如部署失败、数据错乱、依赖服务不可达，便于现场判断。第三，门槛类数值需注明适用版本与复核周期，项目风险等级变化时同步调整。阈值本身是管理约定，不是行业标准，准则中应写明由谁批准、何时复核。
谁来决定暂停与恢复：角色分工与决策机制
决策权要落到角色上。常规分工是：测试负责人提出暂停建议并给出触发信号依据，项目经理确认暂停对进度与范围的影响后拍板，开发负责人参与评估缺陷修复与环境恢复的可行性。恢复决策沿用同一链条，由测试负责人核对准入条件、项目经理确认，再对外通知。
| 角色 | 暂停阶段职责 | 恢复阶段职责 |
|---|---|---|
| 测试负责人 | 识别触发信号、提出暂停建议、标记任务状态 | 逐项核对恢复准入条件、确认回归范围 |
| 项目经理 | 确认暂停、评估进度与范围影响、通知干系人 | 确认恢复、更新计划与里程碑 |
| 开发负责人 | 评估缺陷修复方案与环境修复时间 | 提供修复验证结果、确认阻塞解除 |
紧急情况需要一条快速通道：当环境整体不可用或出现数据损坏风险时，测试负责人可先行宣布暂停并立即通知，事后一个工作日内补记触发信号与决策记录，由项目经理追认。这条规则的价值在于避免因等待确认而继续执行无效用例、产生误导性的测试结论。
通知应明确对象、渠道与时限：测试团队内部即时通知，项目经理与开发负责人在约定时限内知会，跨团队干系人由项目经理统一发出。意见不一致时，升级至项目决策层裁定，裁定结论与理由一并记入暂停记录，作为后续复盘的依据。
暂停期间做什么：工作项状态、缺陷记录与影响评估
暂停是切换到受控状态，测试团队仍有明确动作。执行清单如下：
- 将受影响的测试任务与用例执行状态标记为暂停或阻塞，注明暂停原因与时间，避免后续统计把未执行用例误算为通过。
- 对暂停前已发现的缺陷完成记录与分级，补充复现步骤与环境信息，确保开发侧可以直接处理。
- 评估暂停对进度、范围与交付节点的影响，形成影响评估记录，包含预计恢复时间与需要调整的测试范围。
- 开展恢复准备：跟踪环境修复进展并安排复测验证，准备测试数据，梳理恢复后需要重跑的回归范围与优先级。
影响评估记录建议采用固定格式：暂停起止时间、触发信号、受影响用例与模块清单、进度偏差、范围调整建议、恢复前置事项。这份记录既是恢复决策的输入，也是版本复盘时说明质量风险的证据。
在工具层面，暂停期间的状态标记与缺陷流转需要有承载。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代。这些能力可以把暂停期间的用例状态、缺陷记录与迭代进度放在同一处，便于恢复时核对阻塞缺陷的处理结果。准则中的暂停状态如何映射到具体工作项状态，需结合团队现有的状态配置确定。
恢复条件怎么设：可验证的准入与回归范围
恢复判断应逐项核对，全部满足才宣布恢复。建议的准入检查表如下：
| 检查项 | 通过标准 | 核对人 |
|---|---|---|
| 阻塞缺陷处理 | 触发暂停的缺陷已关闭，或经评估降级并有明确的规避方案与跟踪计划 | 测试负责人 |
| 环境复测 | 环境可正常访问、版本部署成功、测试数据可用，复测结果记录在案 | 测试负责人与环境负责人 |
| 冒烟验证 | 核心路径冒烟用例执行通过，达到本档设定标准 | 测试负责人 |
| 回归范围确认 | 明确恢复后需重跑的用例范围与优先级，覆盖受影响模块及关联功能 | 测试负责人与项目经理 |
回归范围的确定方法是：以暂停期间受影响的模块为主线，向外扩展一层关联功能，再叠加本迭代的核心路径用例。重测优先级按业务影响排序，核心交易路径优先于辅助功能。恢复决策完成后，记录恢复时间、核对结果与决策人，并向暂停通知的同一范围发出恢复通知，保持信息闭环。
示例：一次因阻塞缺陷触发的暂停与恢复全过程
以下为演示情景，用于说明记录链条的写法，不代表真实项目数据。
某迭代进入系统测试第三天，测试负责人在执行核心路径用例时发现支付回调接口返回异常，导致订单状态无法更新，相关用例全部阻塞。按准则判定：该缺陷为致命级、位于核心模块、无临时规避方案，满足缺陷类暂停条件。测试负责人提出暂停建议，项目经理确认后于当日 10:30 宣布暂停，通知测试团队、开发负责人与产品干系人，受影响用例标记为阻塞状态。
暂停期间，测试团队完成三件事：将支付相关缺陷补充复现步骤与环境信息并提交；评估影响范围为订单、退款两个模块共若干条用例，预计恢复时间取决于修复进度；梳理恢复后需重跑的回归范围，包括支付回调、订单状态流转与退款流程。开发负责人当日完成修复并部署至测试环境。
次日 14:00，测试负责人按准入检查表逐项核对：阻塞缺陷已关闭并验证；环境复测通过；核心路径冒烟用例执行通过；回归范围已确认。项目经理确认后宣布恢复，记录恢复时间、核对结果与决策人，并向同一通知范围发出恢复通知。整条记录包含触发信号、决策人、影响评估、恢复依据四个部分，可直接作为版本复盘的输入。
准则落地后的检查与维护
准则发布后需要验证它是否真的被使用。执行检查可围绕以下条目展开：
- 本周期内发生的暂停是否都有触发信号记录与决策人签字，是否存在未记录的口头暂停。
- 暂停期间的任务状态标记是否与实际执行情况一致，未执行用例是否被误计为通过。
- 每次恢复是否都有准入核对记录，恢复通知是否覆盖暂停通知的同一范围。
- 阈值是否与实际风险匹配，是否出现长期不触发或频繁触发两种极端。
修订周期建议为每季度一次，并在重大版本发布后追加复核。修订内容包括阈值数值、风险等级分档、角色任命与通知渠道。常见失效情形有三类：阈值过松导致该停未停，决策人缺位导致暂停无人拍板，恢复无记录导致事后无法追溯。排查时逐条对照检查清单，把发现的问题写入修订记录，注明修订项、修订理由与生效时间。
准则中的暂停与恢复记录，最终要沉淀为可检索的决策证据。ONES 测试管理支持自动生成测试报告并提供项目缺陷分布统计，支持自定义组装测试报告模板，可将暂停期间的缺陷分布与恢复后的测试结果纳入同一份报告；权限可按用户组及用例库、测试计划分别配置，便于控制谁能发起暂停记录、谁能确认恢复。将准则字段与这些记录方式对应起来，暂停与恢复就不再依赖个人记忆，而成为版本质量档案的一部分。
常见问题
准则里的暂停阈值应该由谁批准，多久复核一次？
阈值属于管理约定，建议由测试负责人起草、项目经理批准，并在测试计划中注明本项目适用的档位。复核周期可定为每季度一次，重大版本发布后追加复核；项目风险等级变化时同步调整档位。修订时记录修订项、理由与生效时间，避免阈值长期沿用却与实际风险脱节。
紧急情况下可以先暂停再补流程吗？
可以，但需要限定条件。当测试环境整体不可用或存在数据损坏风险时，测试负责人可先行宣布暂停并立即通知相关方，事后一个工作日内补记触发信号与决策记录，由项目经理追认。补记内容应包含暂停时间、触发信号、影响范围和已采取的动作，使记录链条保持完整。
暂停期间未执行的用例，在统计时怎么处理？
应把受影响的测试任务与用例执行状态标记为暂停或阻塞，并注明原因与时间。这样在统计通过率时，未执行用例不会被误算为通过，恢复后也能据此确定重跑范围。若状态标记与实际执行不一致，恢复决策和版本复盘都会失去可靠依据，因此这项动作需要指定责任人并在恢复前核对一次。
恢复后回归范围怎么确定，是否需要全量重跑？
通常不必全量重跑。建议以暂停期间受影响的模块为主线，向外扩展一层关联功能，再叠加本迭代的核心路径用例；重测优先级按业务影响排序，核心交易路径优先于辅助功能。回归范围由测试负责人确认、项目经理认可后写入恢复记录，作为后续验证的依据。
准则发布后怎么判断它真的在被执行？
可从记录入手检查：本周期内的暂停是否都有触发信号记录与决策人，是否存在未记录的口头暂停；暂停期间的任务状态是否与实际执行一致；每次恢复是否都有准入核对记录，恢复通知是否覆盖暂停通知的同一范围。再结合阈值表现判断，长期不触发或频繁触发都提示阈值需要调整。检查结果写入修订记录，形成闭环。
