测试执行阻塞和测试暂停都表现为“测试没有继续往下走”，但成因和处置方式不同：阻塞是某条用例或某个测试任务因外部条件缺失而被动卡住，暂停是团队主动决定停止一段测试活动。两者混用，团队就看不清该等谁、该催什么。本文围绕测试运行过程，给出两者的定义口径、同维度对照、各自应记录的字段，以及统一团队理解的落地做法。
要点总览（TL;DR）
- 测试执行阻塞是外部条件缺失导致用例或任务无法继续推进，由执行者上报、责任方解阻；测试暂停是团队主动决定停止一段测试活动，由负责人决定并确认恢复。
- 区分两者看三个判断点：触发方式、责任归属、状态流转；退出条件未满足描述的是测试结果未达通过标准，与能否继续执行是两回事。
- 阻塞状态应记录原因分类与描述、受影响范围、责任方与期望解阻时间、解阻条件与验证方式、升级路径；暂停状态应记录决定人与时间、暂停范围与生效时点、恢复条件与审批人、已执行结果的处理方式。
- 统一口径靠状态字典、字段模板、变更确认动作和定期核对，把状态入口固定在测试任务流转中，减少各说各话。
- 按场景使用：依赖外部环境或数据时用阻塞，计划性停止或范围调整时用暂停；两种同时出现时先确认暂停范围，再处理范围内的具体卡点。
阻塞与暂停的核心区别
判断一个状态该记成阻塞还是暂停，先看“是谁让测试停下来的”。外部条件缺失、执行者无法自行解决，属于阻塞；团队基于计划、范围或资源判断主动叫停，属于暂停。前者是被动卡住，后者是主动控制。
阻塞的典型情形包括：测试环境不可用、测试数据未就绪、依赖版本未发布、上游接口未联调完成、第三方服务不可访问。执行者发现无法继续时上报阻塞，责任落在提供该条件的一方，状态持续到解阻条件满足为止。
暂停的典型情形包括：本轮测试范围调整、版本计划变更、集中资源处理更高优先级事项、等待一次计划内的环境切换窗口。暂停由测试负责人或项目负责人决定，责任落在决策方，状态持续到恢复条件成立并完成恢复确认。
三个判断点可以帮助快速归类：
- 触发方式：阻塞由外部条件缺失触发，执行者只能上报；暂停由团队决定触发，负责人可以发起。
- 责任归属：阻塞要找到提供条件的责任方并跟踪解阻；暂停由决策人对停止范围和恢复时点负责。
- 状态流转：阻塞的出口是“解阻→恢复执行”，通常不需要审批；暂停的出口是“满足恢复条件→恢复确认→继续执行”，需要决策人或其授权人确认。
还需要把两者与“退出条件未满足”分开。退出条件未满足指测试已经执行，但结果没有达到既定通过标准，例如用例失败、缺陷未关闭、覆盖率不达标。它描述的是测试结果的质量判断，测试本身仍在推进或已执行完毕；阻塞和暂停描述的是测试能否继续执行。把失败用例标成阻塞，会让进度统计失真，也会让缺陷跟踪失去入口。
同一维度下的差异对照
团队理解不一致，往往是因为各自只记住了某一个侧面。把阻塞、暂停、退出条件未满足放在同一组维度下对照，讨论时就有了共同参照。
| 维度 | 测试执行阻塞 | 测试暂停 | 退出条件未满足 |
|---|---|---|---|
| 触发来源 | 外部依赖缺失，执行者无法自行推进 | 团队基于计划、范围或资源作出的决定 | 测试已执行，结果未达到既定通过标准 |
| 决策角色 | 执行者上报，责任方解阻 | 测试或项目负责人决定，必要时经审批 | 评审人依据通过标准判定 |
| 状态持续时间 | 从上报到解阻条件满足，时长取决于外部方 | 从暂停生效到恢复确认，时长由计划决定 | 从判定不通过到缺陷关闭或重新验证通过 |
| 恢复方式 | 补齐条件后直接恢复执行，记录解阻验证结果 | 满足恢复条件并经恢复确认后继续 | 修复缺陷、补充用例或调整标准后重新验证 |
| 必填记录字段 | 阻塞原因、影响范围、责任方、期望解阻时间、解阻条件 | 决定人与时间、暂停范围、恢复条件、恢复审批人 | 未通过项、判定依据、关联缺陷或整改项 |
| 对进度与报告的影响 | 计入未执行或受阻，单独统计受阻数量与时长 | 计入计划性停止，说明暂停区间与影响版本 | 计入已执行结果，体现在通过率与缺陷数据中 |
这张表可以直接作为团队讨论的底稿。对照时重点确认两件事：受阻的用例是否被算进了“已执行”，暂停的区间是否被误算成“执行中”。这两处口径一旦统一，测试进度和测试报告的数字才能对得上。
阻塞状态应记录的边界信息
阻塞状态的价值在于支撑跟进和交接。只标一个“阻塞”标签，接手的人不知道卡在哪、该找谁、什么时候能好。建议在状态之外补齐以下字段，团队可按流程裁剪，但原因、范围、责任方三项建议保留。
- 阻塞原因分类与描述：先选分类，如环境、数据、依赖版本、接口联调、第三方服务、权限账号，再用一句话写清具体现象，例如“预发环境数据库连接数耗尽，批量用例无法执行”。分类便于汇总，描述便于定位。
- 受影响范围：写明涉及的用例编号或模块、测试任务、版本或迭代。范围决定了解阻后的重跑量，也决定了是否需要通知其他测试人员。
- 责任方与期望解阻时间：责任方写到具体角色或人员，例如环境管理员、后端接口负责人；期望解阻时间给出日期或时间点，便于判断是否需要升级。
- 解阻条件与验证方式：写清什么情况算解除阻塞，例如“环境恢复且冒烟用例通过”，以及由谁验证、验证结果记在哪里。没有验证方式的阻塞容易长期挂着。
- 上报与升级路径：约定超过期望解阻时间仍未解决时向谁升级，例如测试负责人或项目经理。升级路径提前写进团队约定，比临时找人更有效。
填写时注意两点：阻塞原因描述写现象，避免只写“环境问题”这类无法行动的表述；影响范围尽量落到用例或任务层级，便于解阻后精准安排回归。
暂停状态应记录的边界信息
暂停是团队决定，记录的重点是“谁决定的、停到哪、什么条件下恢复”。这些信息让暂停在事后可追溯，也避免恢复时出现范围争议。
- 暂停决定人与决定时间：记录发起暂停的负责人和具体时间。暂停影响计划承诺，需要能追溯到决策来源。
- 暂停范围与生效时点：写清暂停覆盖哪些测试计划、用例集或版本，从哪个时间点开始生效。范围之外仍在执行的测试不受影响，避免一刀切造成误判。
- 恢复条件与恢复审批人：恢复条件可以是“新版本提测通过”“环境切换完成”“范围变更评审通过”；恢复审批人明确到角色，恢复时由其确认后状态才变更。
- 暂停期间已执行结果的处理方式：说明已执行用例的结果是否保留、是否需要在新范围下重跑、未执行部分如何重新排期。这一项常被忽略，恢复后容易出现结果归属不清。
暂停字段与阻塞字段的差别在于记录对象：阻塞记录的是“缺什么、找谁要”，暂停记录的是“谁决定停、凭什么恢复”。两类字段不要混填在同一个自由文本里，否则统计和检索都会失效。
团队如何统一状态口径
状态含义不一致，靠开会口头强调很难持久。更稳的做法是把定义、字段和变更动作固定下来，让状态在流转中自然被约束。
第一步，编写状态字典。为每个状态写一句定义、一个典型例子、一条排除说明。例如阻塞条目下写明“失败用例不属于阻塞，应进入缺陷跟踪”，暂停条目下写明“单个用例等待数据不属于暂停，按阻塞处理”。字典放在团队可随时查阅的位置，新成员入职时作为必读材料。
第二步，配套字段模板。把上一节列出的字段做成状态变更时的填写项，标记为阻塞或暂停时必须补齐关键字段。字段不必一次求全，先保证原因、范围、责任方或决定人这几项可用。
第三步，约定状态变更的确认动作。阻塞上报后由测试负责人确认分类是否准确；暂停生效和恢复由决定人或其授权人确认。确认动作可以很轻，一次评论或一次状态变更记录即可，关键是留下痕迹。
第四步，在测试任务流转中固定状态入口。把状态变更放在任务或计划的固定位置，执行者按流程操作，减少自由发挥。ONES TestCase 支持测试计划与迭代关联、用例分配执行人，并支持自定义用例属性与按用户组配置权限，团队可以据此承载状态字段和变更权限的约定；具体状态类型与必填校验需按实际配置确认。
第五步，定期核对。在每日站会或每周测试例会上抽查几条阻塞和暂停记录，看原因是否具体、责任方是否明确、超期是否升级。核对发现的问题回流到状态字典，逐步收敛口径。
适配场景与选择建议
两类状态并非二选一，而是按场景分别使用。以下建议帮助团队在具体情形下快速判断。
- 依赖外部环境或数据时优先用阻塞：环境不可用、测试数据未准备、依赖版本未发布，都属于执行者无法自行解决的情形。标阻塞并补齐责任方和解阻条件，跟进才有抓手。
- 计划性停止或范围调整时用暂停：版本计划变更、测试范围收缩、资源集中调配，由负责人决定暂停并记录恢复条件。这类停止是管理动作，用阻塞表达会误导团队去找“外部原因”。
- 两种状态同时出现时先处理暂停：如果团队已决定暂停某段测试，期间个别用例的环境问题不再单独升级，随暂停一并记录；恢复后再按阻塞流程处理仍未解决的条件。顺序上先确认范围，再处理范围内的具体卡点。
- 与测试报告口径衔接：报告中把受阻数量与受阻时长、暂停区间与影响版本分开呈现，失败用例单独计入执行结果。ONES TestCase 支持自定义组装测试报告模板，报告字段与状态口径的对应关系需按模板配置确认。
如果团队当前只有一种“卡住”状态，可以先从拆分字段开始：保留原状态，增加原因分类和影响范围，观察一段时间后再决定是否拆成阻塞与暂停两个状态。状态数量增加会带来维护成本，拆分的判断标准是团队是否真的需要区分“等外部条件”和“主动停止”这两种处置方式。
常见问题
一条用例执行失败，应该标阻塞还是走缺陷跟踪？
执行失败说明测试已经跑完，只是结果没有达到通过标准，属于退出条件未满足，应进入缺陷跟踪流程，记录未通过项、判定依据和关联缺陷。阻塞描述的是测试无法继续执行，例如环境不可用、数据未就绪。把失败用例标成阻塞，会让受阻数量虚高，也会让缺陷失去跟踪入口。
阻塞超过期望解阻时间还没解决，团队该怎么处理？
按事先约定的升级路径处理：由测试负责人或项目经理联系责任方确认进展，评估是否需要调整测试计划或先执行不受影响的用例。升级动作和新的期望解阻时间应回写到阻塞记录中，保持状态与实际进展一致。如果阻塞长期无法解除且影响版本交付，团队可以评估是否将相关测试范围转为暂停，由负责人决定并记录恢复条件。
暂停期间已经执行的用例结果还有效吗？
取决于暂停范围和恢复条件。如果暂停只涉及范围调整，已执行结果通常保留，恢复后补充未执行部分；如果暂停伴随版本变更或环境切换，已执行结果可能需要在新条件下重跑。建议在暂停记录中明确写出已执行结果的处理方式，恢复时按记录执行，避免结果归属不清。
团队现在只有一种“卡住”状态，需要马上拆成阻塞和暂停吗？
不必一步到位。可以先保留原状态，增加原因分类和影响范围字段，观察一段时间内“卡住”的实际构成。如果记录显示相当一部分停止来自团队主动决定，拆分才有实际收益；如果绝大多数都是外部条件缺失，先完善阻塞字段和升级路径更划算。状态数量增加会带来维护成本，拆分标准是团队是否真的需要区分“等外部条件”和“主动停止”这两种处置方式。
在测试管理工具里落地这套口径，需要关注哪些配置点？
重点看三处：状态或属性字段能否承载原因分类、责任方、解阻条件等信息；状态变更时能否要求补齐关键字段；不同角色能否按权限执行上报、确认和恢复操作。ONES TestCase 支持自定义用例属性、按用户组配置权限，并支持测试计划与迭代关联、用例分配执行人，可作为承载状态字段与变更权限的基础；具体状态类型与必填校验需按实际配置确认。
