测试暂停与恢复准则要回答四件事：什么情况下停、谁来定、停到什么程度、满足什么条件才能恢复。本文给出一份假设项目的完整填写示例，以阻断缺陷、环境不可用、需求变更三类触发条件为例，逐项写出阈值、责任人、暂停范围、恢复前置条件和记录字段，并解释每条写法背后的取舍。准则落地时需要缺陷状态、测试执行记录和评审留痕，ONES可作为承载这类记录与流转的工具之一。
要点总览（TL;DR）
- 测试暂停与恢复准则要写清四件事：触发条件、决策人、暂停范围、恢复条件，四者缺一执行时就会卡在争论上。
- 示例用阻断缺陷、环境不可用、需求变更三类触发条件，阈值写成缺陷数量、持续时长、影响用例比例等可核对的事实，避免“严重”“明显”这类感受性描述。
- 暂停分全量与局部两档：致命缺陷、环境整体不可用走全量暂停，单模块缺陷集中或单功能变更走局部暂停，把代价控制在必要范围内。
- 恢复条件先于暂停条款确定，每条都指向缺陷单状态、部署记录、回归执行记录等证据，恢复评估变成核对清单。
- 示例为假设情景，性能、安全等测试类型以及团队规模、发布节奏不同时，需调整阈值与责任分工后再使用。
这份示例要解决什么问题
很多团队的测试计划里写了“发现严重问题暂停测试”，执行时却卡在三个地方：什么算严重、谁来宣布暂停、暂停后哪些工作还能继续。准则的价值在于把这些判断提前写成条款，让测试负责人、开发负责人和项目经理在同一套口径下行动，减少临时争论。
本文示例设定如下，均为假设情景，不对应任何真实客户：某产品团队采用两周一个迭代，测试阶段分为冒烟测试、系统测试和回归测试三段；测试负责人一名，开发负责人一名，项目经理一名；缺陷分为致命、严重、一般、轻微四级；发布准入要求致命和严重缺陷清零。示例准则覆盖四个判定环节：触发条件、决策与通知、暂停范围、恢复条件与验证。
读者可以从本文拿走三样东西：一份可直接参照修改的准则全文、每条阈值和条件的写法解释、以及迁移到自己项目时需要调整的部分。示例不涉及测试脚本编写、攻击技术或行业标准结论。
完整示例：一份测试暂停与恢复准则
以下为已填写的准则全文，条款编号便于引用和后续修订。
第一条 暂停触发条件
出现下列任一情形，启动暂停评估：
- 冒烟测试阶段发现致命缺陷1个及以上，或系统测试阶段致命缺陷累计达到2个；
- 严重缺陷在24小时内新增达到5个，且其中至少2个集中在同一核心模块；
- 测试环境不可用连续超过4小时，或环境不可用影响超过50%的测试用例执行；
- 迭代内需求变更涉及已进入系统测试的核心功能，且变更范围超过该功能验收点的三分之一；
- 测试数据或测试账号出现错误，导致已执行用例的结论需要整体复核。
第二条 暂停决策与通知
测试负责人发现触发条件后，在2小时内发起暂停评估，参与人为测试负责人、开发负责人、项目经理。暂停由测试负责人宣布，项目经理确认对迭代计划的影响。宣布后30分钟内在团队测试群和项目管理工具中同步暂停通知，内容包括触发条款编号、暂停范围、初步预计时长和下一次评估时间。开发负责人对缺陷修复排期负责，项目经理对是否调整迭代范围负责。
第三条 暂停范围界定
暂停分为全量暂停和局部暂停。全量暂停适用于致命缺陷、环境整体不可用、测试数据整体失效三类情形，暂停期间停止所有测试执行，保留缺陷复现和日志收集工作。局部暂停适用于单一模块的严重缺陷集中、单一功能的需求变更，暂停范围限定为该模块或该功能的测试执行，其余模块按原计划继续。范围界定由测试负责人在暂停通知中写明，范围调整需重新通知。
第四条 恢复前置条件与恢复验证
恢复需同时满足以下条件，并以可核查的证据为准：
- 触发暂停的缺陷已修复，且修复版本已部署到测试环境，附缺陷单状态和部署记录；
- 修复缺陷完成回归验证，回归用例执行通过率100%，附执行记录；
- 环境不可用情形下，环境恢复后完成一次冒烟验证，冒烟用例全部通过；
- 需求变更情形下，变更后的需求说明和验收点已更新并经项目经理确认；
- 暂停期间受影响的已执行用例完成复核，复核结论记录在测试执行记录中。
恢复由测试负责人宣布，宣布前需完成一次恢复评估，参与人与暂停评估相同。恢复通知中写明恢复范围、恢复依据的证据编号和后续补测安排。
第五条 记录与留痕
每次暂停与恢复需记录以下字段：暂停编号、触发条款编号、触发时间、发现人、决策参与人、暂停范围、暂停时长、恢复时间、恢复依据的证据编号、受影响用例数量、补测安排、复盘结论。记录保存在测试计划文档的对应章节，并与缺陷单、测试执行记录相互引用。
逐条解释：每个阈值和条件为什么这样写
条款的写法直接影响执行时是否会产生分歧。下面逐项说明示例中的取值理由、可替代口径和常见误写。
阻断缺陷阈值
示例把冒烟阶段的致命缺陷阈值设为1个，原因是冒烟测试验证的是主流程能否走通，主流程中断意味着后续系统测试无法有效开展，继续执行的用例结论可信度低。系统测试阶段设为累计2个，是因为系统测试覆盖面更广，单个致命缺陷可能只影响局部路径，允许在隔离该路径后继续其他模块。替代口径可以是“致命缺陷修复前不进入下一测试阶段”，适合发布节奏较慢的项目。常见误写是只写“发现严重缺陷暂停”，没有区分阶段和数量，执行时每个人对严重的理解不同。
环境不可用的时长与影响面
示例同时设置时长和影响面两个条件，是因为只看时长会漏掉短时但影响面大的中断，只看影响面又难以在中断初期判断。4小时和50%两个数值可按团队实际调整：每日可测试时间较短的团队可以缩短时长阈值，用例集中在少数模块的团队可以降低影响面比例。常见误写是只写“环境故障暂停”，没有说明故障持续多久才触发，导致每次短时抖动都引发讨论。
需求变更的暂停边界
示例用“已进入系统测试的核心功能”加“变更范围超过验收点三分之一”两个条件界定边界。前一个条件限定变更发生的时点，后一个条件控制变更的规模。这样写的目的是避免任何小改动都触发暂停，同时保证影响验收结论的变更不被漏掉。替代写法可以是按变更涉及的人天估算设阈值，适合变更频繁的项目。常见误写是把“需求变更”整体列为暂停条件，执行中要么频繁暂停，要么被习惯性忽略。
恢复条件写成可验证的证据
示例的恢复条件都指向具体记录：缺陷单状态、部署记录、回归执行记录、冒烟结果、需求确认记录。这样写的原因是“问题解决了”属于主观判断，不同角色容易给出不同结论；指向证据后，恢复评估变成核对清单，争议减少。常见误写是写“确认问题已解决后恢复”，没有说明由谁确认、依据什么确认。
责任人与升级路径
示例把暂停宣布权给测试负责人，把迭代范围调整权给项目经理，把修复排期权给开发负责人，是按各自掌握的信息和权限划分。升级路径可以补一条：暂停超过一个工作日未达成恢复条件时，升级至项目负责人决策是否缩减迭代范围。常见误写是暂停和恢复都由同一人独自决定，缺少交叉确认，容易在压力下提前恢复。
从这份示例可以迁移的填写规律
把示例抽象一层，可以得到以下可复用的编写规律，适用于功能测试为主的迭代项目，其他场景需按实际情况调整。
- 触发条件写成可观测事实。用缺陷数量、持续时长、影响用例比例、变更范围这类可计数或可核对的事实，替代“严重”“较多”“明显”这类感受性描述。每条触发条件都应能被第三方复核。
- 暂停与恢复成对设计。先确定恢复需要哪些证据，再倒推暂停条款需要记录什么。示例中恢复条件要求回归执行记录，暂停条款就要求保留受影响用例清单，两者对应。
- 区分全量暂停与局部暂停。全量暂停代价高，只在影响整体结论时使用；局部暂停把影响限制在模块或功能内，让其余测试继续推进。范围要在通知中写明，避免执行时各自理解。
- 与缺陷分级、发布准入保持口径一致。准则中的致命、严重等级别应与团队缺陷分级定义一致，恢复条件中的清零要求应与发布准入标准一致，否则会出现准则允许恢复但发布准入不通过的情况。
- 记录字段服务于复盘。暂停编号、触发条款、时长、受影响用例数量这些字段，既支撑当次恢复评估，也为季度复盘提供数据，用来判断阈值是否需要调整。
准则落地后，暂停通知、缺陷状态、回归执行记录和恢复评估需要在同一处可查。ONES支持缺陷工作项的状态流转、测试用例与执行记录管理，以及文档评审留痕，团队可以把上述条款对应的记录放在同一项目空间中，恢复评估时直接核对证据编号，减少在多个工具间来回查找。
适用边界与需要按项目调整的部分
示例面向功能测试为主的迭代项目，直接照搬到其他场景会出现条款不匹配。以下部分需要按项目调整。
| 调整维度 | 示例写法 | 调整方向 |
|---|---|---|
| 测试类型 | 以功能缺陷数量和用例通过率为触发与恢复依据 | 性能测试可改为响应时间超标比例、错误率阈值；安全测试可改为高危问题数量，恢复条件对应复测通过 |
| 团队规模 | 测试负责人、开发负责人、项目经理三方评估 | 小团队可合并角色但保留交叉确认；多团队协作需明确跨团队缺陷的归属和升级路径 |
| 发布节奏 | 两周迭代，阈值按单迭代设定 | 每日发布的团队需缩短评估时限、降低单次暂停的容忍时长；月度发布的团队可适当放宽数量阈值 |
| 环境条件 | 4小时、50%影响面 | 共享环境或依赖外部系统的项目，需补充外部依赖故障的判定口径 |
准则需要定期复盘的信号包括：同一触发条款在一个季度内被触发多次但从未真正暂停，说明阈值与实际不符；恢复后短期内再次因同类问题暂停，说明恢复条件不够充分；暂停评估经常超时，说明决策参与人或时限设置不合理。建议每季度结合暂停记录复盘一次，修订后更新版本号和生效日期。
本文示例为假设情景下的填写范例，用于说明准则的写法和取舍，不构成行业标准、认证依据或对特定项目的推荐结论。各团队应结合自身缺陷分级、发布准入和测试类型，调整阈值与责任分工后再投入使用。
常见问题
准则里写了暂停条件，但执行时大家还是争论要不要停，问题出在哪？
常见原因是触发条件停留在感受性描述，比如“发现严重问题暂停”，没有说明哪个阶段、几个缺陷、谁来判定。可以按示例的做法改成可观测事实：冒烟阶段致命缺陷1个及以上、系统测试阶段累计2个、严重缺陷24小时内新增5个且集中在同一核心模块。每条条件都能被第三方复核，争论就会从“算不算严重”转为“是否满足条款”。
另一个原因是缺少决策人。条款里写明由测试负责人发起评估并宣布暂停，项目经理确认迭代影响，参与人固定为三方，执行时就不需要每次重新商量流程。
局部暂停和全量暂停怎么选，选错了会有什么后果？
判断依据是问题是否影响整体测试结论。致命缺陷导致主流程中断、环境整体不可用、测试数据整体失效，这些情形下继续执行其他用例的结论可信度低，适合全量暂停。单一模块严重缺陷集中、单一功能发生需求变更，影响范围可以隔离，适合局部暂停，其余模块按原计划推进。
选错方向的代价不对称：该局部暂停却全量暂停，会浪费可继续执行的测试时间；该全量暂停却局部暂停，可能让受影响的用例结论混入整体结果，恢复后需要大范围复核。范围要在暂停通知中写明，调整范围时重新通知。
恢复条件写成“确认问题已解决”为什么不够用？
“已解决”是主观判断，测试、开发、项目经理可能给出不同结论，压力大时容易提前恢复。示例把恢复条件逐条指向证据：缺陷单状态与部署记录、回归用例执行通过率100%的执行记录、环境恢复后的冒烟结果、变更后需求说明的项目经理确认、受影响用例的复核结论。
这样写之后，恢复评估变成逐项核对证据编号，恢复通知中写明依据的证据编号和补测安排，事后复盘也有据可查。恢复评估的参与人与暂停评估保持一致，形成交叉确认。
小团队人手少，三方评估的流程能不能简化？
可以合并角色，但建议保留交叉确认这一环。示例中的测试负责人、开发负责人、项目经理在小型团队中可能由两人甚至一人兼任，此时至少保证暂停宣布与恢复宣布不由同一人在无复核的情况下独自完成，恢复前由另一位成员核对证据清单。
评估时限也可以按团队节奏调整：示例要求2小时内发起评估、30分钟内同步通知，节奏更快的团队可缩短，节奏较慢的团队可适当放宽，但时限本身要写进条款，避免评估无限期拖延。
准则制定后多久复盘一次，什么信号说明阈值需要改？
建议每季度结合暂停记录复盘一次，修订后更新版本号和生效日期。值得关注的信号有三类：同一触发条款在一个季度内多次触发但从未真正暂停，说明阈值与实际不符；恢复后短期内再次因同类问题暂停，说明恢复条件不够充分；暂停评估经常超出规定时限，说明决策参与人或时限设置不合理。
复盘时同时核对准则与缺陷分级、发布准入的口径是否仍然一致，避免出现准则允许恢复但发布准入不通过的情况。测试类型发生变化时，触发条件也要同步调整，例如引入性能测试后补充响应时间与错误率的判定口径。
