测试执行跑到一半卡住，先别急着逐个重试用例。更有效的顺序是：把“执行不下去”拆成可观察的症状并界定影响范围，按环境与数据、依赖与接口、缺陷与版本、人员与权限、流程与准入逐类用证据确认原因，再按影响面选择绕行、降级、挂起或升级，最后用同一批用例复跑验证恢复。本文聚焦测试运行过程中的阻塞处置，缺陷修复闭环与测试报告结论不在展开范围。
要点总览（TL;DR）
- 先界定症状与影响范围：把环境不可用、数据缺失、依赖未就绪、用例不可执行、权限受限、准入未满足分开登记，并区分真阻塞与用例失败。
- 按先易后难排查：先排除环境与数据等可快速验证项，再查依赖与版本，最后核对流程与人员，每类结论都留下日志、快照、探测结果或记录作为证据。
- 处置按影响面选择：可绕行就标注范围与补测计划，短期无法解除则降级缩小范围，未解除的用例挂起并写明原因与责任人，影响发布或超时则升级并给出期望解除时间。
- 涉及环境配置变更、测试数据清理或重置前先备份或确认可回滚，并设定停止点，避免影响其他正在执行的用例。
- 阻塞解除后用同一批用例复跑验证，把高频阻塞项转为下一轮执行前的准入检查项，用阻塞用例数、平均解除时长、同类重复次数观察改进效果。
阻塞出现在哪一环：先界定症状与影响范围
“测试执行阻塞”是一个笼统说法，落到现场往往表现为几种完全不同的症状。先把症状归类，才能决定找谁、查什么。常见症状包括：环境不可用（服务起不来、页面打不开、部署失败）、数据缺失（前置数据不存在或被占用）、依赖未就绪（上游接口未联调、第三方服务不可达、版本未提测）、用例本身不可执行（步骤缺失、前置条件写错、断言无法判断）、权限或账号受限（登录失败、角色无操作权限）、准入条件未满足（评审未通过、提测未放行）。
归类之后要界定范围，否则容易把个别用例的问题当成整体阻塞。建议登记五项信息：受影响用例数与所属模块、对应版本与执行轮次、已阻塞时长、是否阻断发布判断。范围界定清楚了，处置的优先级和升级对象才有依据。
还要区分真阻塞与用例失败。失败是用例执行后产生了明确结果，只是结果不符合预期；阻塞是用例无法产生有效结果，执行被卡在中间。两者在记录和后续动作上完全不同：失败进入缺陷跟踪，阻塞需要先解除卡点再重新执行。把失败误记为阻塞会虚增阻塞规模，把阻塞误记为失败则会让无效结果混入通过率统计。
| 登记项 | 填写内容示例 | 用途 |
|---|---|---|
| 症状类型 | 环境不可用 / 数据缺失 / 依赖未就绪 / 用例不可执行 / 权限受限 / 准入未满足 | 决定排查方向和责任角色 |
| 用例范围 | 受影响用例数、所属模块 | 判断是个别问题还是批量问题 |
| 版本与轮次 | 被测版本号、第几轮执行 | 关联构建记录与提测记录 |
| 已阻塞时长 | 从首次无法执行到当前的时间 | 触发升级判断 |
| 影响判断 | 是否阻断发布、影响哪些测试结论 | 决定处置力度 |
逐类排查原因：假设、验证证据与排除顺序
排查的核心原则是把原因当假设，用证据确认或排除，避免凭经验直接下结论。下面按阻塞类型列出常见原因假设和对应的验证方式，现场可对照使用。
环境类阻塞
常见假设包括：部署版本与预期不一致、服务健康检查异常、配置项或证书过期、网络策略或依赖服务不可达。验证方式是先复现问题，再比对部署记录与日志。例如页面打不开时，先确认目标环境部署的是哪个构建产物，再看服务日志中是否有启动失败或连接超时的记录。日志比对能区分“环境本身坏了”和“访问路径配错了”这两种情况。
数据类阻塞
常见假设包括：测试数据缺失、数据被其他用例占用或修改、数据状态与用例前置条件不匹配。验证方式是取数据快照，逐条核对用例前置条件。比如某条用例要求订单处于“待支付”状态，实际数据已被上一轮执行改成“已支付”，这就属于状态不匹配，而非功能缺陷。
依赖类阻塞
常见假设包括：上游接口未完成联调、第三方服务不可用、依赖模块版本未提测。验证方式是直接做接口探测，并核对提测记录。接口探测能快速区分“依赖服务挂了”和“调用参数不对”；提测记录则能确认依赖方是否真的交付了可测版本。
缺陷与版本类阻塞
常见假设包括：存在阻塞性缺陷导致后续用例无法执行、构建产物错误或打包不完整。验证方式是查看缺陷单状态和构建记录。需要说明的是，本文只处理“缺陷导致执行卡住”这一环，缺陷修复后的验证跟踪属于另一主题。
人员与流程类阻塞
常见假设包括：执行账号权限不足、用例评审未通过、提测准入未放行。验证方式是核对权限清单和准入记录。这类阻塞往往最容易确认，也最容易被忽略，因为大家习惯先怀疑系统。
排查顺序建议
按先易后难推进：先排除环境和数据这类可快速验证的项，再查依赖与版本，最后核对流程与人员。这样安排的原因是环境和数据问题验证成本低、影响面往往较大，先排除可以避免在错误方向上耗费时间。每一类结论都应留下证据，例如日志片段、数据快照、接口探测结果、缺陷单编号或准入记录，便于后续复盘和交接。
| 阻塞类型 | 原因假设 | 验证证据 |
|---|---|---|
| 环境 | 部署版本不符、服务异常、配置或证书过期、网络不可达 | 复现步骤、部署记录、服务日志比对 |
| 数据 | 数据缺失、被占用、状态不匹配 | 数据快照、用例前置条件核对 |
| 依赖 | 接口未联调、第三方不可用、版本未提测 | 接口探测结果、提测记录 |
| 缺陷与版本 | 阻塞性缺陷未修复、构建产物错误 | 缺陷单状态、构建记录 |
| 人员与流程 | 权限不足、评审未过、准入未放行 | 权限清单、准入记录 |
按影响面处置：绕行、降级、挂起与升级
原因确认后，处置动作取决于影响面，而不是取决于哪个动作最省事。下面按四种处置方式说明触发条件、动作和风险边界。
可绕行：切换环境、补数据、用桩替代
当阻塞点有可用替代路径，且替代不会改变被测对象的实质时，可以选择绕行：切换到备用环境、补充或构造测试数据、用桩或模拟服务替代未就绪的依赖。绕行必须标注范围和后续补测计划，例如“本轮用桩验证了主流程，依赖真实接口的异常分支待联调后补测”。没有标注的绕行，会让后续读者误以为相关场景已被完整覆盖。
需降级：缩小范围、调整优先级
当阻塞短期内无法解除，但部分用例仍可执行时，可以缩小本轮执行范围，把不受影响的用例优先跑完，并明确哪些结论不能由本轮结果支撑。降级的要点是把“没测”和“测了通过”分开记录，避免发布判断时把未覆盖范围当成已覆盖。
需挂起：标记状态与原因
阻塞未解除时，应把相关用例标记为挂起并写明原因，而不是留空或记为通过。挂起状态需要包含阻塞类型、关联证据和责任人，这样统计通过率时不会把无效结果计入，交接时也能快速接手。
需升级：影响发布或超时
当阻塞影响发布判断，或已阻塞时长超过团队约定阈值时，应升级到对应责任角色，并给出期望解除时间。升级信息至少包含：阻塞范围、已确认的原因、已尝试的处置、需要对方做什么、期望完成时间。只报“卡住了”的升级，往往换来一轮来回确认。
风险边界与停止点
涉及环境配置变更、测试数据清理或重置的处置，动手前必须备份或确认可回滚，并设定停止点：一旦发现变更影响到其他正在执行的用例或共享环境，立即停止并回退。绕行用的桩或模拟服务也要记录启用范围和关闭时间，防止长期残留造成环境与真实依赖不一致。
| 处置方式 | 触发条件 | 关键动作 | 风险与停止点 |
|---|---|---|---|
| 绕行 | 存在可用替代路径且不改变被测实质 | 切换环境、补数据、用桩替代，标注范围与补测计划 | 桩长期残留导致环境失真，需记录启停时间 |
| 降级 | 阻塞短期无法解除，部分用例可执行 | 缩小执行范围、调整优先级，区分未测与已测 | 未覆盖范围被误当已覆盖，需在结论中显式说明 |
| 挂起 | 阻塞未解除，用例无法产生有效结果 | 标记状态、原因、证据与责任人 | 状态留空或误记通过，污染通过率统计 |
| 升级 | 影响发布判断或超过约定时长 | 升级到责任角色，给出范围、原因、诉求与期望时间 | 信息不全导致反复确认，延误解除 |
这些处置动作要落到具体记录上才有约束力。在 ONES 测试管理中，用例可以分配执行人，用例库和测试计划支持单独配置权限，便于把挂起用例的责任和可见范围界定清楚；测试计划与迭代关联，执行进度和通过率可在计划概览中查看，挂起与绕行的范围也能在进度判断中被识别。对于因缺陷导致的阻塞，未通过用例可快速创建缺陷任务并在测试与研发团队间流转，使“卡在哪、等谁处理”有明确承载。
恢复验证与复发预防
阻塞解除不等于恢复有效。验证恢复的标准是：同一批被阻塞用例重新执行后能产生有效结果。复跑时应使用与原计划一致的用例版本和环境，确认结果可判断；对绕行期间用桩或替代数据得出的结论，要核对哪些需要补测，并把补测安排写进执行记录。
记录闭环同样重要。每条阻塞应留下原因、处置方式、解除时间、影响范围和证据位置，形成可追溯的执行记录。这份记录既是本轮发布的判断依据，也是下一轮排查的参照。
复发预防的重点是把高频阻塞项前置。可以把反复出现的环境检查、数据准备、依赖提测确认、权限申请转为下一轮执行前的准入检查项，在测试计划启动前逐项核对。检查项要具体到可验证，例如“目标环境部署版本与提测单一致”“关键前置数据已准备并锁定”“依赖接口已完成联调并有探测记录”，而不是笼统写“环境正常”。
改进是否有效，可以用三个指标观察：阻塞用例数、平均解除时长、同类阻塞重复次数。如果某类阻塞重复出现而平均解除时长没有下降，说明处置停留在救火层面，需要回到准入检查项上补强。用例库支持按属性筛选、模块树状组织，便于按模块统计阻塞分布，定位高频发生的位置。
常见问题
阻塞用例和失败用例在记录上怎么区分，混在一起会有什么后果？
失败是用例执行后产生了明确结果，只是结果不符合预期；阻塞是用例无法产生有效结果，执行卡在中间。记录时，失败进入缺陷跟踪，阻塞则先标记状态、原因、证据和责任人，解除后再重新执行。
两者混记的后果很直接：把失败误记为阻塞会虚增阻塞规模，让升级判断失真；把阻塞误记为失败，无效结果会混入通过率统计，发布判断时把没测到的范围当成已测。建议在登记表里把症状类型和结果状态分成两列填写。
绕行时用桩或模拟服务替代未就绪依赖，什么情况下不能这么做？
绕行的前提是存在可用替代路径，且替代不改变被测对象的实质。如果本轮要验证的正是真实依赖的接口行为、数据一致性或异常处理，用桩替代就无法支撑这部分结论，此时应把相关用例挂起或降级，等真实依赖就绪后补测。
决定绕行时，要标注绕行范围和后续补测计划，并记录桩或模拟服务的启用范围与关闭时间，防止长期残留造成环境与真实依赖不一致。
阻塞超过多久应该升级，升级信息里必须包含什么？
升级阈值由团队约定，常见做法是把“影响发布判断”和“超过约定时长”作为两个触发条件，任一满足即升级。阈值本身没有统一标准，关键是提前约定并写进执行规范，避免每次临时判断。
升级信息至少包含：阻塞范围（受影响用例与模块）、已确认的原因及证据、已尝试的处置、需要对方做什么、期望解除时间。只报“卡住了”的升级，通常换来一轮来回确认，反而拉长解除时间。
阻塞解除后复跑，用原来的用例版本还是更新后的版本？
验证恢复是否有效，应使用与原计划一致的用例版本和环境复跑，这样结果才能和阻塞前的执行计划对应。如果阻塞期间用例本身被修订过，需要说明修订内容，并区分哪些结论来自原版本、哪些来自新版本。
对绕行期间用桩或替代数据得出的结论，复跑后要核对哪些需要补测，并把补测安排写进执行记录，避免绕行结论被当作完整覆盖。
高频阻塞项转成准入检查项后，怎么判断改进是否真的有效？
可以用三个指标观察：阻塞用例数、平均解除时长、同类阻塞重复次数。检查项上线后，如果某类阻塞重复次数下降、平均解除时长缩短，说明前置核对起了作用；如果重复次数没降、解除时长也没变化，说明处置还停留在救火层面，需要回到检查项本身补强。
检查项要具体到可验证，例如“目标环境部署版本与提测单一致”“关键前置数据已准备并锁定”“依赖接口已完成联调并有探测记录”，笼统写“环境正常”无法核对。
