测试执行中被标记为“阻塞”，记录重点在于界定卡点、责任与解除条件：卡在哪条用例或哪个环境、由谁负责解除、满足什么条件可以恢复、何时复核。把这些边界信息写清楚，团队才能对阻塞状态形成一致理解，并与主动暂停、整体准出未达标区分开。本文给出必填字段、状态流转要求和一个填写示例。
要点总览（TL;DR）
- 阻塞状态记录的核心是界定卡点、责任与解除条件，建议固定六类必填信息：阻塞对象与范围、原因类别、责任方与解除条件、时间边界、影响范围、复核与解除记录。
- 阻塞、暂停、退出条件未满足分属三个层级：单条测试任务状态、执行批次状态、质量准出结论，判断关键是“谁造成的、谁能解除”。
- 解除条件要写成可验证的标志，例如“沙箱账号开通并能完成一笔测试支付”，避免“等环境好了”这类无法核验的表述。
- 阻塞处理按标记、复核、解除、留痕四个动作流转，复核节点防止长期挂起，解除依据保留下来才能支撑阻塞时长统计与复盘。
阻塞状态要记录哪些边界信息
阻塞状态的记录目标，是让任何一个接手的人都能判断“这条测试现在能不能动、要等谁、等到什么程度算解除”。字段不必多，但每项都要能支撑一个具体判断。以下六类信息建议设为必填。
| 字段 | 含义 | 填写要求 | 示例 |
|---|---|---|---|
| 阻塞对象与范围 | 明确被阻塞的具体对象 | 写到用例或测试任务粒度，并注明所属版本、环境 | 支付退款用例（用例ID），V2.3版本，预发布环境 |
| 阻塞原因类别 | 卡点的性质分类 | 从约定类别中选择，并附一句具体描述 | 环境不可用：支付网关沙箱未开通 |
| 责任方与解除条件 | 谁负责解除、解除的可验证标志 | 写具体角色或人员，解除条件要能被他人核验 | 支付平台组；沙箱账号开通且能完成一笔测试支付 |
| 时间边界 | 标记阻塞的时间与预计复核时间 | 记录标记时间，并约定下一次复核的具体日期 | 3月4日标记，3月6日复核 |
| 影响范围 | 受牵连的用例、需求或版本 | 写受影响用例数量及关联需求编号 | 影响退款相关用例6条，关联需求REQ-118 |
| 复核与解除记录 | 解除的确认过程 | 记录确认人、确认时间、判断依据 | 3月6日由测试负责人确认，附沙箱支付成功截图 |
其中“解除条件”最容易被写空。写成“等环境好了”无法判断，写成“沙箱账号开通并能完成一笔测试支付”则可以由任何人验证。原因类别的作用是让统计有意义：环境不可用、依赖系统未就绪、测试数据缺失、需求或接口未确认，这几类卡点的处理路径和等待时长差别很大，混在一起统计就看不出问题集中在哪里。
影响范围字段常被省略，但它决定了阻塞解除后的排期。一条用例被卡住和六条用例被卡住，对测试计划的影响不同；如果阻塞对象关联了需求或版本，解除后还需要确认这些需求的验证是否整体延后。
阻塞、暂停与退出条件未满足的边界
团队对状态理解不一致，多数情况是把三个不同层级的概念混用了。阻塞描述单条测试任务为什么动不了，暂停描述执行活动被主动停下，退出条件未满足描述整体测试是否达到准出标准。三者触发方、所处层级和解除方式都不同。
| 概念 | 定义 | 触发方 | 所处层级 | 解除方式 |
|---|---|---|---|---|
| 阻塞 | 外部依赖未满足，导致该测试无法继续执行 | 执行人提交，依赖方解除 | 单条测试任务或用例 | 依赖满足并经确认后，回到待执行或执行中 |
| 暂停 | 主动停止执行，如版本冻结、优先级调整、资源调配 | 测试负责人或项目管理者决定 | 执行批次或测试计划 | 恢复时需重新排期，确认执行窗口与人员 |
| 退出条件未满足 | 测试整体未达到准出判断所要求的标准 | 测试负责人依据准出规则判定 | 质量准出结论 | 补齐未达标的验证项后重新评估 |
区分的关键在“谁造成的、谁能解除”。阻塞的成因在测试执行之外，执行人自己无法消除；暂停是管理侧的主动决定，恢复也由管理侧安排；退出条件未满足则是汇总层面的判断，它可能由若干阻塞、缺陷或覆盖不足共同导致，但本身不针对某一条用例。
状态转换也要按层级处理。阻塞解除后，任务回到待执行或执行中，原阻塞记录保留，用于统计阻塞时长；暂停恢复后，执行批次需要重新确认排期，而不是简单地把状态改回执行中；退出条件未满足的结论在补齐验证后重新评估，不通过修改单条任务状态来“消掉”。
阻塞状态的记录机制与流转
边界信息只有在流转中被持续维护才有价值。建议把阻塞处理拆成标记、复核、解除、留痕四个动作，每个动作对应明确的记录要求。
标记：执行人提交阻塞
执行人在确认无法继续后提交阻塞，一次性填写对象范围、原因类别、责任方、解除条件、影响范围和预计复核时间。标记动作要求执行人先做基本排查，排除自身操作或数据准备问题，避免把执行障碍误报为外部阻塞。
复核：按约定周期确认依赖状态
到达预计复核时间，由执行人或测试负责人确认依赖是否已满足。复核结果有两种：依赖仍未满足，更新复核时间并说明进展；依赖已满足，进入解除动作。复核节点的作用是防止阻塞长期挂起而无人跟进。
解除：确认依据后关闭阻塞
解除由责任方或测试负责人确认，必须写明判断依据，例如环境开通通知、接口文档确认记录、测试数据到位说明。仅有“已解决”三个字不构成解除依据，因为后续无法追溯当时凭什么判断可以恢复。
留痕与异常处理
保留每次阻塞的起止时间、复核记录和解除依据，便于按原因类别统计阻塞时长和集中卡点。当责任方在约定时间内无法确认解除时，执行人应将阻塞升级至测试负责人或项目管理者，由其在跨团队层面协调，并在记录中注明升级时间和协调结果。
这些字段和流转动作需要有承载位置。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例可分配执行人，便于把阻塞记录挂在具体用例和测试计划上；同时支持自定义用例属性，团队可结合实际配置核验是否用于记录阻塞原因等字段。多维度概览测试计划的能力，也有助于在计划层面看到阻塞对进度的影响。具体状态字段与提醒机制以实际产品配置为准。
一个具体例子与常见误解
以下为演示情景，用于说明字段如何填写，不代表真实项目数据。
某支付退款用例在预发布环境执行时，发现支付网关沙箱尚未开通，无法发起退款请求。执行人提交阻塞：对象为退款相关用例6条，版本V2.3，预发布环境；原因类别为环境不可用，具体描述为支付网关沙箱未开通；责任方为支付平台组；解除条件为沙箱账号开通并能完成一笔测试支付；标记时间为3月4日，预计3月6日复核；影响范围为退款相关用例6条，关联需求REQ-118。3月6日复核时依赖已满足，测试负责人确认解除，记录确认时间和沙箱支付成功的验证结果，用例回到待执行。
对照这个例子，可以检查四类常见误解：
- 把暂停当阻塞：因版本冻结主动停测，却记成阻塞，会让阻塞数量和时长虚高，掩盖真正的依赖问题。判断方法是问一句“是外部依赖卡住了，还是我们主动停的”。
- 只写“环境问题”不写解除条件：记录无法判断何时能恢复，阻塞长期挂起。解除条件要写成可验证的标志。
- 把退出条件未满足记成单条任务阻塞：整体准出未达标是汇总判断，逐条标阻塞会让统计口径混乱，也无法反映真实缺口。
- 解除后不记录依据：事后无法追溯当时凭什么判断依赖已满足，复盘阻塞时长和原因时缺少证据。
把这六类字段固定为阻塞状态的必填项，并在复核和解除环节保留记录，团队对“阻塞”的理解就能落到同一套可核验的信息上，阻塞统计也才有比较和复盘的基础。
常见问题
阻塞解除后，原来的阻塞记录要不要删除？
建议保留，不要删除。阻塞记录中的起止时间、原因类别和解除依据是后续统计阻塞时长、识别集中卡点的原始数据。删除后，这条用例在报表里看起来从未被卡过，阻塞统计就会失真。状态上把任务改回待执行或执行中即可，历史记录作为过程留痕保留。
执行人自己就能解决的问题，还需要标阻塞吗？
不需要。标记阻塞前，执行人应先做基本排查，排除自身操作、数据准备或脚本配置的问题。阻塞的成因在测试执行之外，执行人自己无法消除，例如环境未开通、依赖系统未就绪、需求未确认。把自身可解决的问题标成阻塞，会让阻塞数量虚高，也会让依赖方收到无效的协调请求。
责任方一直不确认解除，阻塞记录该怎么处理？
按约定时间复核后依赖仍未满足，先更新复核时间并说明进展。当责任方在约定时间内无法确认解除时，执行人应将阻塞升级至测试负责人或项目管理者，由其在跨团队层面协调，并在记录中注明升级时间和协调结果。升级动作本身也要留痕，否则复盘时看不出这条阻塞曾经被推动过。
一个阻塞影响多条用例，是逐条标记还是合并记录？
两种做法可以结合。在阻塞对象与范围字段中写清受影响的用例数量和关联需求，同时在每条受影响用例上保留可追溯的关联，这样既避免重复填写相同的原因与责任方，又能在用例粒度上看到哪些执行被卡住。影响范围字段直接决定阻塞解除后的排期，一条用例被卡和六条用例被卡，对测试计划的影响不同。
团队对阻塞原因的分类不一致怎么办？
先约定一组固定的原因类别，例如环境不可用、依赖系统未就绪、测试数据缺失、需求或接口未确认，要求填写时从类别中选择并附一句具体描述。分类统一后，按类别统计阻塞时长才有比较意义；这几类卡点的处理路径和等待时长差别很大，混在一起统计就看不出问题集中在哪里。类别数量不宜过多，能覆盖主要卡点即可，后续按实际统计结果调整。
