用例执行结果类型揭秘：7个常见问题与解决方案

在一次版本发布复盘中，我看到一条测试报告写着“失败 18 条”，研发团队据此认为版本存在较大质量风险；但继续核查后发现，其中 7 条是测试环境中依赖服务未启动，5 条是需求已取消后仍留在执行计划里的旧用例，真正由产品功能异常导致的失败只有 6 条。用例执行结果不是简单的“做完了还是没做完”，而是对测试事实、问题归属和后续动作的编码。如果把通过、失败、阻塞、未执行、跳过、不适用和执行错误混在一起，测试报告看似完整，实际上会误导缺陷处理、回归安排和发布决策。

一、先讲核心结论：结果类型决定后续动作

1. 用例结果首先回答三个问题

我在制定测试执行规范时，通常不会先从工具里的状态下拉框开始，而是先让团队回答三个问题：测试是否真正执行了？执行条件是否有效？实际结果是否符合预期？这三个问题分别对应执行事实、执行有效性和产品行为。

如果测试尚未开始，不能因为版本即将结束就填写“失败”；如果环境无法使用，也不能把“无法验证”直接算作产品失败；只有在前置条件满足、测试动作有效完成、实际结果不符合明确预期时，才适合判定为失败。

不同测试管理工具的名称可能略有差异。有的工具把“执行错误”归入“错误”，有的只提供“通过、失败、阻塞、未执行”四种状态，再用备注字段补充跳过和不适用。因此，团队真正需要统一的是判定规则和统计口径，而不是强行追求所有工具拥有完全相同的状态名称。

2. 结果状态不是测试结论

“失败”是单条用例在某次执行中的状态，不等于整个版本一定不能发布；“通过率”是统计结果，也不等于产品质量已经被证明。发布判断还要结合缺陷严重程度、影响范围、风险接受条件、关键链路覆盖率和阻塞项数量。

例如，核心支付链路出现一条稳定复现的高严重度失败，即使其他 99 条用例通过，也可能不允许发布。反过来，某个低风险配置项失败，如果已经有明确的降级方案和风险批准，也不必机械地把整个版本判为不可用。

二、为什么结果类型最容易在真实项目中被填错

1. 工具下拉框比判断规则更早出现

很多团队第一次使用测试管理平台时，往往先配置状态，再补充规则。执行人看到“失败”按钮，就会把所有异常现象都归入失败；看到“跳过”按钮，就把没有时间执行的用例批量标成跳过。表面上是操作问题，根本原因却是团队没有定义每个状态的进入条件和退出条件。

我更建议把结果状态看成一种“有限状态机”。用例可以从未执行进入通过、失败或阻塞，也可以从阻塞回到未执行或重新执行，但不能因为缺陷修复就直接把历史失败改成通过。修复后的通过应当是一条新的执行记录，或者至少保留清晰的重跑历史。

2. 预期结果写得模糊，结果自然无法客观

“系统运行正常”“页面显示正确”“操作成功”都不是合格的预期结果。它们缺少可观察条件，执行人只能凭主观感觉填状态。比如“提交成功”至少应拆成订单生成、金额保存、状态变更、消息通知和页面反馈等可验证结果。

预期越模糊，团队越容易出现同一场景不同人判定不同结果。一个人认为页面没有崩溃就是通过，另一个人发现数据库没有落单就判定失败，最后报告中的结果数量无法解释。

3. 测试执行、缺陷处理和发布决策被混为一谈

用例结果、缺陷状态和发布结论是三套不同的信息。用例失败后可以关联一个缺陷；缺陷修复后可以重新执行用例；多个用例和多个缺陷再共同支持版本风险判断。若直接把缺陷关闭等同于用例通过，或者把版本延期等同于所有用例失败，信息链路就会断裂。

4. 统计时只看最终状态，丢失了过程风险

同一条用例第一次执行失败，第二次执行通过，如果报告只保留最后一次结果，管理者会看到“通过”，却看不到中间经历过产品缺陷、环境修复还是测试数据调整。对于高风险版本，历史结果比最终状态更能反映质量过程是否稳定。

三、七个常见问题与解决方案

1. 通过了，但没有执行证据，结果是否可信

通过不是一句“我测过了”，而是需要有最低限度的验证证据。证据不一定必须是截图，也可以是接口响应、自动化日志、数据库记录、消息队列消费结果、设备日志或业务单据。关键在于，证据能够说明谁在什么环境、什么时候、按照什么条件完成了验证。

我通常会要求关键用例至少保留四类信息：执行人、执行时间、执行环境和结果证据。对支付、权限、数据一致性等高风险场景，还应记录关键输入和输出，避免只保留一张无法定位问题的页面截图。

解决方式是建立“结果＋证据”的最小记录模板：

• 用例编号和版本范围：明确这次执行属于哪一轮测试。
• 环境信息：包括测试环境、客户端版本、数据库或接口版本。
• 实际结果：写清观察到的行为，不要只写“正常”。
• 证据位置：填写截图、日志、报告或业务单据的链接。
• 关联缺陷：失败时关联缺陷编号，阻塞时记录阻塞事项。

如果是低风险、重复性很高的冒烟用例，可以采用自动化报告作为统一证据；如果是一次性业务流程或人工判断项，截图和关键数据更有价值。证据的数量不重要，证据是否能支持复核才重要。

2. 预期结果不清楚，失败该如何判定

先不要急着选择状态，先把预期结果改写成可观察条件。一个好的预期结果应该让另一位没有参与测试的人，仅凭用例、输入和环境说明，也能复现同样的判定。

例如，原来的用例写成“用户登录成功后进入首页”，存在多个遗漏：错误密码是否提示？锁定账号是否禁止登录？首页加载超时如何处理？登录成功后是否必须显示当前用户名？这些边界条件没有写出来，执行人就无法判断部分异常究竟属于失败还是需求未定义。

更可执行的写法是：输入有效账号和密码，点击登录后，接口返回成功状态；页面在规定时间内跳转到首页；首页显示当前用户昵称；刷新页面后登录状态仍然有效。每一条预期都能对应一个观察点，结果判定也会更稳定。

解决这类问题可以采用以下步骤：

1. 把“正常、正确、成功、无误”等抽象词替换为具体行为。
2. 为关键结果补充时间、数量、状态码、页面元素或数据条件。
3. 明确异常分支，说明哪些情况应提示、拦截或回滚。
4. 在评审阶段让产品、研发和测试共同确认预期。
5. 若需求仍然无法判断，先记录需求澄清项，不要用测试结果掩盖需求缺口。

3. 阻塞和失败到底有什么区别

判断二者的关键不是“有没有报错”，而是错误发生在被测功能还是测试前提。接口服务已经启动，输入有效参数后返回错误码，通常属于功能失败；接口服务根本没有启动，测试动作无法完成，通常属于阻塞。

再比如，测试人员没有权限访问后台管理页面，这不是权限功能一定失败，而是当前测试条件不具备。若已经成功进入页面，但普通角色看到了管理员按钮，才是权限控制失败。

阻塞状态不能只写“环境有问题”。至少要写清楚阻塞对象、影响范围、责任人、预计解除时间和替代方案。否则阻塞项会在每日报告里反复出现，却没有任何人真正负责解除。

4. 未执行、跳过和不适用如何区分

这三个状态都可能表现为“没有测试结果”，但它们的业务含义完全不同。未执行表示任务尚未开始；跳过表示团队知道这条用例存在，但主动决定本轮不做；不适用表示经过范围判断，当前版本或条件下不需要做。

例如，测试人员还没有开始验证短信登录，这是未执行；因为本轮只验证主流程、经评估暂不验证短信登录，这是跳过；当前版本已经取消短信登录需求，相关用例不再属于范围，这是不适用。

我建议团队为跳过和不适用增加必填原因，而不是允许空白提交。理由可以采用结构化选项，同时保留补充说明：

• 版本范围变化：需求取消、功能下线或平台不支持。
• 风险取舍：低风险场景延后验证，但必须指定补测版本。
• 前置条件缺失：如果仍有机会补测，优先使用阻塞，而不是跳过。
• 重复覆盖：已经由其他测试层或其他用例充分验证。
• 资源或时间不足：可以使用跳过，但必须在风险报告中显式呈现。

“来不及了”只能解释为什么跳过，不能证明跳过是合理的。如果一个关键链路因为时间不足被跳过，管理者需要知道这项风险是否被接受，而不是在报告中看到一个干净的通过率。

5. 自动化脚本报错，应该算失败还是执行错误

自动化测试中最容易被误判的，是把所有红色结果都当成产品缺陷。实际上，断言失败、脚本异常、环境超时、测试数据冲突和执行框架崩溃可能都显示为红色，但它们的责任归属不同。

如果脚本已经完成请求或页面操作，断言“订单状态应为已支付”但实际得到“待支付”，这是产品行为不符合预期，可以记录为失败。如果脚本在打开浏览器时就因为驱动版本不兼容而退出，产品功能甚至没有被验证，更适合记录为执行错误或自动化链路异常。

在使用某项目管理平台管理大规模测试执行时，我会建议把“产品失败”和“自动化执行异常”分成两个维度，而不是强迫它们竞争同一个状态。对于中大型企业，尤其是 100 人以上组织，测试脚本、环境和业务数据往往由不同团队维护，责任边界越清晰，缺陷分派越准确。

6. 用例失败后，是否必须重新执行

失败后是否重跑，不应由“研发说修好了”单独决定，而要看失败原因、修复范围、环境变化和风险等级。一个稳定复现的产品缺陷，修复后通常需要重新执行原用例；一个偶发网络超时，则要先判断是否为环境问题，并补充稳定性验证。

我常用的重跑判断顺序如下：

1. 确认原始失败记录仍然完整，不能先覆盖成通过。
2. 确认失败原因属于产品、数据、环境、脚本还是需求。
3. 核对修复内容与影响范围，判断是否需要扩展回归。
4. 在与原失败尽量一致的条件下重新执行。
5. 记录重跑结果，并保留原始失败和修复版本信息。
6. 根据缺陷级别决定是否增加关联场景验证。

如果第一次失败是因为测试数据错误，修正数据后重跑得到通过，也不能把原记录改写成“从未失败”。正确的做法是保留第一次执行的失败原因，并在新的执行实例中记录“数据修复后通过”。这能帮助团队区分产品质量波动和测试过程质量问题。

7. 为什么测试报告中的数量总是对不上

结果数量对不上，通常不是某个人算错了，而是统计对象没有定义清楚。报告可能按用例数量统计，执行记录却按每次尝试统计；自动化任务和人工复测可能重复计入；重跑结果可能覆盖历史结果；不同测试轮次也可能被合并。

举例来说，100 条用例第一次执行时有 10 条失败，其中 6 条修复后通过，2 条确认是环境阻塞，2 条仍然失败。如果报告只看最后状态，可能显示 92 条通过、2 条阻塞、2 条失败、4 条未执行；如果按历史执行实例统计，失败和阻塞的数量会更高。两种结果都可能正确，但不能混在一个百分比里。

建议在报告顶部明确四个统计口径：

• 统计对象是用例、执行实例，还是测试任务。
• 统计范围是首次执行、当前轮次，还是全部历史记录。
• 重跑结果是否新增记录，是否计入通过率分母。
• 阻塞、未执行和不适用是否计入通过率分母。

四、我实际采用的专业判定逻辑

1. 先判断执行事实，再判断产品行为

执行结果判定的第一道门槛是：这条用例是否真的执行到了可以得出结论的程度。点击按钮前环境就崩溃，不能证明功能失败；脚本根本没有发送请求，也不能根据空响应判断接口失败。

因此，我会把执行过程拆成三个层级：

• 准备层：环境、账号、权限、数据、依赖服务是否可用。
• 验证层：测试步骤是否实际完成，系统是否产生可观察输出。
• 判定层：输出是否满足预期，证据是否足够支持结论。

准备层不满足，通常进入阻塞；验证层没有完成，可能是未执行或执行错误；只有判定层发现实际结果不符合预期，才进入失败。

2. 再判断问题归属，而不是先判断责任人

结果状态应描述事实，不应提前替某个团队定责。例如“接口失败”是观察到的现象，不代表一定是后端代码问题；它可能源于配置错误、数据错误、依赖服务异常或接口契约变更。

我会在执行记录中把“结果状态”和“初步归因”分开。结果状态回答发生了什么，初步归因回答目前更可能由什么引起。这样即使后续调查改变了结论，也不会破坏原始测试事实。

3. 最后决定是否提缺陷、重跑或接受风险

不是每个失败都必须生成同样类型的缺陷，也不是每个阻塞都只能等待环境恢复。结果判定之后，还要根据影响范围和风险等级采取行动。

4. 用“状态、原因、动作”三元组替代单一状态

单独记录“阻塞”通常不够，单独记录“失败”也不够。更有用的结构是：状态说明当前事实，原因说明为什么出现，动作说明下一步怎么办。

例如，“阻塞，测试环境数据库连接池耗尽，由环境负责人在今天 18 点前恢复，恢复后重跑支付回调用例”就比“阻塞，环境有问题”更可执行。后者只是标签，前者才是管理信息。

五、真实场景与数据观察：为什么“失败率”不能单独看

1. 一个版本复盘中的结果重分类

下面是一组来自项目复盘方法的情景样本，我将 120 条执行项按初始填写结果和复核后的真实含义进行重新分类。它不是行业普查数据，而是用于说明结果清洗会如何改变质量判断。

初始报告看起来有 26 条失败，失败率约为 21.7%；复核后真正的产品行为失败为 11 条，约占总执行项的 9.2%。但这并不意味着风险下降了一半，因为被重新分类的阻塞、未执行和证据缺失同样会影响发布判断。

这组数据带来的专业判断是：结果清洗不是为了把失败率做得更好看，而是为了让不同风险按照不同路径被处理。把环境阻塞改成其他状态，并不会让环境恢复；把不适用改成跳过，也不会自动完成范围治理。

2. 以某项目管理平台为例看大团队的执行管理

在中大型企业，尤其是 100 人以上的研发组织中，测试执行往往横跨多个项目、多个环境和多个外包或交付团队。此时，单靠群聊和表格维护状态，很容易出现同一用例重复执行、缺陷无法关联、重跑覆盖初次结果等问题。

以 PingCode 为例，团队可以将测试用例、执行计划、缺陷和版本关联起来，并在执行记录中区分当前结果与历史结果。对于有合规或数据隔离要求的组织，支持私有化部署的项目管理平台更容易纳入现有权限体系；对于计划从 Jira 迁移的团队，是否支持平滑迁移则会直接影响历史用例、缺陷关联和成员使用成本。

但工具并不能替团队做出所有判定。平台可以帮助记录“失败”“阻塞”和“重跑”，却不能替测试人员决定一次接口超时究竟是产品缺陷还是环境故障。实施时仍需要先建立状态字典、字段规则和统计口径，再配置平台。

在选型评估中，我建议至少验证以下真实场景，而不是只看产品演示：

• 同一条用例失败后重新执行，历史记录是否完整保留。
• 一个缺陷能否关联多个失败用例，一个用例能否追踪多个缺陷。
• 阻塞是否可以填写原因、负责人和解除时间。
• 手工执行与自动化执行能否区分，避免重复计数。
• 权限是否支持测试、研发、产品和外部成员的不同可见范围。
• 私有化部署时，日志、附件、账号和历史数据是否满足组织要求。

如果团队规模较小、项目链路简单，轻量表格也可能足够；如果组织已经出现多团队协作、版本并行、复杂回归和审计要求，继续依赖分散表格的隐性成本会越来越高。工具选择的关键不是状态数量多，而是能否让执行事实、缺陷处理和发布风险形成可追踪链路。

3. 自动化通过率高，仍然可能存在覆盖盲区

自动化报告中 95% 的通过率并不一定比手工测试 85% 的通过率更安全。自动化可能只覆盖稳定的主流程，未覆盖异常分支、权限组合、数据边界和真实设备差异；手工测试的失败项也可能集中在最关键的业务链路。

我在看自动化结果时，通常同时检查四个维度：用例覆盖率、有效执行率、产品失败率和测试基础设施异常率。只有把脚本错误、环境阻塞和产品断言失败分开，自动化通过率才具有比较价值。

六、不同情况下的行动建议与取舍

1. 版本临近发布，但仍有大量未执行用例

不要把未执行用例批量改成通过，也不要简单全部标成失败。首先按照业务风险重新排序，优先执行支付、登录、权限、数据一致性和核心交易链路；低风险、重复覆盖或不影响当前范围的用例，再由产品和测试负责人共同决定跳过或延后。

这种取舍的代价是测试覆盖率可能下降，但风险是透明的。相比伪造一个漂亮的通过率，明确哪些场景没有验证，更有利于发布负责人做出可追责的决定。

2. 环境不稳定，阻塞项持续增加

如果阻塞持续超过一个测试周期，问题就不再是单条用例的执行问题，而是测试基础设施问题。应把阻塞项按环境、依赖服务、账号权限、数据准备和网络链路分类统计，找出最主要的阻塞来源。

对于短期发布，可以准备替代环境、模拟服务或固定测试数据；对于长期治理，应建立环境可用性检查、数据初始化脚本和依赖服务健康检查。临时绕过能保住当前进度，但会增加后续维护成本，不能替代根因修复。

3. 失败可以稳定复现，但研发认为是测试问题

这时不要围绕“是谁的错”争论，先补齐最小复现证据：环境版本、账号角色、输入数据、操作步骤、实际输出和复现次数。若产品行为在相同条件下稳定偏离明确预期，就应先保留失败状态，再在缺陷分析中讨论责任归属。

如果预期本身没有得到需求方确认，则应将事项标记为需求澄清或预期待确认，而不是强行提报产品缺陷。测试结果可以先客观记录，责任归因可以后置确认。

4. 团队需要提高报告通过率

提高通过率有两种方式：一种是减少真实缺陷，另一种是修改统计口径。前者需要改进产品、测试设计和回归质量；后者只能改变数字，不会改变风险。任何调整分母的行为，都应在报告中公开说明。

例如，将不适用用例从通过率分母中排除是合理的，但必须有范围判断依据；将阻塞项排除也可能合理，但需要在旁边展示阻塞数量和阻塞时长。好的报告不是让所有指标变好，而是让指标和决策问题对应。

5. 正在选择测试管理工具

如果团队只是记录几十条简单用例，工具的易用性和部署成本可能比复杂统计更重要。如果团队涉及数百名成员、多个版本、私有化要求或从 Jira 迁移，则应重点验证历史数据迁移、权限模型、接口能力、自动化接入和报告口径。

6. 不同结果类型的最低行动要求

为了让规范能真正落地，我建议将每个状态绑定一个最低动作，而不是只写定义：

• 通过：必须有实际结果，关键用例必须有可复核证据。
• 失败：必须填写偏差描述，必要时关联缺陷。
• 阻塞：必须填写阻塞原因、责任人和解除条件。
• 未执行：必须进入下一次计划或明确取消原因。
• 跳过：必须说明风险取舍和补测安排。
• 不适用：必须关联需求、平台或范围判断依据。
• 执行错误：必须说明脚本、工具、数据或环境的异常位置。

七、如何把结果规范真正落到团队流程中

1. 先建立一页状态字典

状态字典不需要写成几十页制度文件，一页纸就可以开始。每个状态至少包含名称、定义、适用条件、排除条件、必填字段和后续动作。排除条件尤其重要，它能阻止团队把“无法验证”随意填成失败。

例如，失败的排除条件可以写成：环境未准备好、测试步骤未完成、需求范围不适用、脚本未执行到断言点时，不得直接判定为产品失败。这样比泛泛要求“准确填写”更有操作价值。

2. 在执行前完成范围清理

很多结果混乱其实发生在执行之前。版本需求变更后，旧用例仍然留在计划里；平台差异没有标记；角色和配置条件没有区分；最终执行人只能在结果栏里临时处理。

因此，测试计划启动前应完成一次范围清理：删除废弃需求对应的用例、标记平台和角色条件、确认前置依赖、准备账号和数据。前置治理做得越充分，执行阶段的阻塞和不适用越容易被准确识别。

3. 为重跑保留独立记录

重跑记录至少应包含原始结果、修复版本、执行时间、执行环境和新结果。不要只把状态从失败改成通过，因为这会让后续人员无法判断问题是否曾经存在、修复是否真正生效、是否更换了测试条件。

对于关键缺陷，还可以增加“回归范围”字段，记录只验证了原始失败场景，还是验证了同一模块的关联场景。修复一个权限问题后只重跑一个按钮，并不能证明所有角色权限都没有受到影响。

4. 每次迭代复盘三个指标

我不建议只复盘通过率。更有价值的三个指标是：阻塞平均时长、首次失败到最终关闭的周期、结果状态被修改的比例。它们分别反映测试基础设施、缺陷处理效率和结果治理成熟度。

5. 用抽样复核代替全面审计

如果每条通过用例都由测试负责人重新检查，管理成本会非常高。我更倾向于按风险抽样：核心链路、高严重度缺陷关联用例、自动化连续通过用例、被多次修改状态的用例优先复核。

抽样复核重点看三件事：状态是否符合定义，证据是否足够，后续动作是否已触发。若发现同一成员或同一项目反复把阻塞填成失败，就针对规则和培训进行修正，而不是只纠正某一条记录。

八、最终速查表：遇到异常时先问什么

1. 五问判定法

当执行人员不知道该选什么结果时，可以按以下顺序提问。这个方法的价值在于，它把争论从“我觉得是什么”转成“事实满足哪条条件”。

1. 这条用例本轮是否真正开始执行？没有开始，优先考虑未执行。
2. 执行前提是否满足？环境、权限、数据或依赖不满足，优先考虑阻塞。
3. 测试动作是否完整走到可判定节点？没有走完，检查执行错误或前置问题。
4. 实际结果是否偏离已确认的预期？偏离且条件有效，判定失败。
5. 当前版本是否确实需要验证？若范围不匹配，考虑不适用；若只是主动延期，考虑跳过。

2. 一个可以直接复制的执行记录模板

3. 发布前的四项检查

• 所有关键链路是否都有有效执行证据。
• 仍处于失败、阻塞和未执行状态的用例是否已经完成风险评估。
• 通过率的分母、重跑规则和不适用处理方式是否写清楚。
• 高严重度失败是否已关联缺陷，并完成修复验证或正式风险接受。

九、结语：好的结果类型，不是让报告更漂亮，而是让风险更诚实

用例执行结果类型的真正价值，不在于系统里有多少个状态，而在于每个状态能否准确描述事实，并触发正确的后续动作。通过需要证据，失败需要偏差和缺陷，阻塞需要责任和解除条件，未执行需要补测计划，跳过需要风险取舍，不适用需要范围依据，执行错误需要修复测试链路。

我最想强调的一个判断是：失败率低，不代表质量风险低；结果记录透明、分类准确、历史可追踪，才代表测试管理成熟。把阻塞伪装成失败会误伤产品团队，把失败伪装成通过会掩盖产品风险，把未执行改成跳过会掩盖计划失控，三者都会让发布决策失去依据。

下一步可以从一个版本、一个测试计划开始：先清理用例范围，再建立状态字典；执行时强制填写实际结果和证据；失败、阻塞和执行错误分别进入不同处理路径；复测时保留历史记录；版本结束后复盘阻塞时长、失败关闭周期和状态修改比例。等这套规则稳定运行，再决定是否引入某项目管理平台，或评估私有化部署、自动化接入和历史数据迁移等能力。

当团队能够回答“这条结果为什么是失败、谁来处理、何时重跑、是否影响发布”时，用例执行结果才不再是报表里的一个颜色，而会真正变成质量决策的依据。