测试用例失效率统计的关键，是先确定“什么算失效”和“分母取哪些用例”，再套用公式计算。分子分母需要限定在同一时间窗、同一用例版本和同一执行范围内，否则算出的比率无法复算，也难以比较。本文给出一套可直接套用的口径、公式和算例，并说明结果出来后如何判断高低、如何转化为用例维护动作。
要点总览（TL;DR）
- 失效率 = 失效用例数 ÷ 执行用例数 × 100%，分母取执行用例数，未执行、阻塞、跳过的用例不计入分母，单独统计覆盖率与阻塞率。
- 失效要先拆成执行失败、缺陷关联、内容过时、步骤错误四类分别计数，环境与脚本问题单独标记，不混入分子。
- 同一张报表只用一个时间窗，按轮次、发布周期或季度统计，并标注用例版本与执行范围，保证他人能复算。
- 失效率没有通用达标线，用历史基线、同类项目、趋势变化和失效原因构成四项参照判断高低。
- 失效率用于用例质量改进，避免直接挂钩个人绩效，否则容易诱导少报失效或减少执行。
统计失效率要先回答哪三个问题
失效率是一个比率，分子和分母都可以有多种取法。动手统计前先回答三个问题，后续数字才有解释力。
第一，这个指标要回答什么问题。失效率通常服务于三类判断：用例内容是否仍然有效、执行结果是否可信、维护投入应该投向哪里。目标不同，失效的判定口径就不同。如果关注用例内容质量，应把“用例步骤过时、预期结果写错”计入失效；如果只关注执行环节，则把环境问题和脚本缺陷单独标记，不混入用例失效。
第二，统计对象是什么。需要明确到用例版本、执行轮次和发布周期三个维度。同一条用例在版本迭代后内容会变化，跨版本合并统计会掩盖新版本引入的问题；执行轮次决定时间窗，发布周期决定汇总粒度。建议在报表上同时标注这三项，缺一项就难以复算。
第三，哪些失败要排除。脚本实现缺陷、测试环境不可用、数据准备失败导致的执行失败，反映的是执行基础设施问题，应单独标记为“环境/脚本类失败”，不计入用例失效率的分子。这样处理的目的，是让失效率指向用例本身的质量，避免把环境波动误判为用例设计问题。
这三个问题确定后，统计边界就清楚了：失效率用于用例质量改进，不用于团队绩效排名。把这一点写进统计说明，能减少后续解读时的争议。
分子分母怎么定：失效口径与计算公式
基础公式为：失效率 = 失效用例数 ÷ 执行用例数 × 100%。单位是百分比，保留一位小数即可，精度过高会放大样本波动的影响。
失效的判定口径
“失效”需要拆成可分别计数的类型，否则一个总数无法指导改进。常见分类如下：
| 失效类型 | 判定依据 | 典型改进方向 |
|---|---|---|
| 执行失败 | 按用例步骤执行，实际结果与预期不符，且确认是产品缺陷或用例预期错误 | 核对预期结果，关联缺陷 |
| 缺陷关联 | 用例执行通过，但关联缺陷显示该场景仍有未修复问题 | 补充或调整断言与检查点 |
| 内容过时 | 需求或界面已变更，用例步骤、前置条件不再适用 | 更新用例或标记废弃 |
| 步骤错误 | 用例本身描述有误，导致无法按步骤执行或结果不可判定 | 修正步骤与数据 |
四类可以合并出一个总失效率，也应分别给出分类失效率。总失效率看趋势，分类失效率看原因构成。
分母口径
分母取执行用例数，不取用例总数。用例总数包含大量未执行用例，用它做分母会把“没测”算成“没问题”，失真明显。未执行、阻塞、跳过的用例处理规则建议如下：
- 未执行：不计入分母，单独统计执行覆盖率。
- 阻塞：不计入分母，单独统计阻塞率，并注明阻塞原因。
- 跳过：因需求取消等原因主动跳过，不计入分母；因环境原因临时跳过，计入阻塞。
时间窗与单位
按执行轮次统计适合迭代内的快速反馈；按发布周期统计适合版本质量回顾；按季度统计适合观察长期趋势。三种粒度可以并存，但同一张报表内只用一种，并在标题中写明。
缺失值与重复执行
执行结果缺失的用例按未执行处理，不计入分母。同一用例在一轮内多次执行时，以最后一次有效执行结果为准；若多次执行结果不一致，标记为“结果不稳定”，单独列出，不重复计入分子。跨轮次合并统计时，按用例去重，取该时间窗内最近一次执行结果。
数据从哪里取、怎么保证可比
失效率的数据来自三处：用例管理记录提供用例ID与版本，执行记录提供执行时间与结果，缺陷管理记录提供缺陷与用例的关联关系。三处数据通过用例ID对齐。
必备字段清单
| 字段 | 用途 | 取值要求 |
|---|---|---|
| 用例ID | 唯一标识与去重 | 全局唯一，跨版本保持不变 |
| 用例版本 | 区分内容变更 | 每次内容修改递增 |
| 执行时间 | 划定时间窗 | 精确到日 |
| 执行结果 | 区分通过、失败、阻塞、跳过、未执行 | 枚举值，不允许自由文本 |
| 失效原因分类 | 支撑分类失效率 | 按上节四类加环境/脚本类 |
| 关联缺陷ID | 核对失效判定 | 可为空，非空时需有效 |
可比性处理
不同项目直接比较失效率容易得出错误结论，需要处理三类差异。用例粒度差异：一条端到端用例与一条字段校验用例的失效概率不同，比较时应按用例类型分层。项目复杂度差异：新功能密集的项目失效偏高属于正常，应与自身历史基线比较。执行覆盖率差异：覆盖率低的项目，失效率的样本代表性弱，报表中应同时展示覆盖率，覆盖率过低时标注“样本不足”。
证据留存方面，建议每轮抽取一定比例的失效用例做复核，检查判定是否一致。复核记录保留判定人和判定依据，用于校准口径，也便于新人理解标准。
统计步骤：从原始记录到失效率报表
按以下五步执行，每步都有明确产物，便于交接和复算。
- 锁定统计范围与时间窗。确定项目、用例集、执行轮次或发布周期，写进报表标题。产物：统计范围说明。
- 清洗执行记录，标记失效类型。剔除重复执行记录，按最后一次有效结果取值；把环境/脚本类失败单独标记；对失效用例逐条归类。产物：清洗后的执行明细表。
- 计算总体与分类失效率。按公式计算总失效率，再按四类失效分别计算占比。产物：总体指标与分类指标。
- 按模块、用例类型、失效原因拆分。找出失效率明显偏高的模块和用例类型，作为改进候选。产物：拆分维度表。
- 与上期基线对比并输出结论。对比上一轮或上一发布周期的同口径数据，结合失效原因构成给出结论与建议动作。产物：失效率报表与结论页。
完成标志是：他人拿到明细表和口径说明，能独立复算出相同结果。
一个算例：两轮执行的失效率对比
以下为演示数据，用于说明计算过程，不代表任何真实项目。
| 项目 | 第一轮 | 第二轮 |
|---|---|---|
| 用例总数 | 200 | 200 |
| 执行用例数（分母） | 180 | 190 |
| 未执行 | 15 | 8 |
| 阻塞 | 5 | 2 |
| 失效用例数（分子） | 27 | 19 |
| 其中：执行失败 | 12 | 8 |
| 其中：缺陷关联 | 6 | 5 |
| 其中：内容过时 | 6 | 3 |
| 其中：步骤错误 | 3 | 3 |
第一轮失效率 = 27 ÷ 180 × 100% ≈ 15.0%；第二轮失效率 = 19 ÷ 190 × 100% = 10.0%。执行覆盖率从 90% 提升到 95%。
从两轮对比可以得出：失效率下降 5 个百分点，且执行覆盖率同步提升，说明改善不是靠少执行换来的；内容过时类失效从 6 条降到 3 条，说明用例更新动作产生了效果。不能得出的是：失效率下降不等于产品质量提升，产品缺陷数量、缺陷严重程度需要另行查看；两轮用例集若有增删，需先确认口径一致再比较。
若某轮执行用例数为零，失效率无定义，报表中应显示“不适用”并注明原因，不能用 0% 代替。执行用例数少于 30 时，比率波动大，建议同时给出绝对数和“样本不足”提示。
失效率多高算高：判断方法与常见误读
失效率没有通用达标线。不同产品形态、用例粒度、执行严格程度的项目，合理区间差异很大，设定统一阈值会误导判断。可行的判断方式有四种：
- 历史基线对比：与自身前三个轮次或前两个发布周期的同口径数据比较，看是否偏离正常波动范围。
- 同类项目对比：在用例粒度、执行覆盖率相近的项目之间比较，差异才有意义。
- 趋势变化：连续多个周期持续上升，比单次偏高更值得关注。
- 失效原因构成：内容过时占比高，说明维护滞后；执行失败集中，说明产品问题或环境问题集中。
常见误读需要提前说明。把失效率当团队绩效：失效率受需求变更频率、用例编写风格影响，直接与个人绩效挂钩会诱导少报失效或减少执行。把单指标当质量全貌：失效率只反映用例执行层面的情况，缺陷逃逸率、需求覆盖率需要一起看。忽略执行覆盖率：覆盖率下降时失效率可能“变好看”，实际是测得更少。
改进动作应与原因对应：内容过时类占比高，安排用例评审与更新；步骤错误集中，补充用例编写规范与样例；执行失败集中在少数模块，优先排查这些模块的产品问题与环境配置；缺陷关联类偏高，检查用例的断言是否覆盖了缺陷场景。
把失效率纳入日常管理：记录与复盘怎么落地
失效率要持续可用，记录方式必须稳定。用例与执行结果作为工作项记录，执行结果用固定枚举值，失效原因作为独立字段，关联缺陷通过工作项关系建立。这样每轮执行结束即可按轮次汇总，不需要人工二次整理。
在 ONES 中，测试用例与测试执行可以作为工作项管理，执行结果和失效原因以字段形式记录，缺陷与用例通过关联关系连接，便于按轮次筛选后统计分子分母。复盘时按模块和失效原因查看分布，把需要更新的用例转为用例更新任务，指派给对应用例负责人，形成“执行—统计—归因—更新—再执行”的闭环。统计报表与用例库使用同一套字段，口径不会在传递中走样。
落地时建议固定三件事：每轮执行结束当天完成失效归类；每发布周期输出一次失效率报表并附原因构成；每次复盘至少产出一条明确的用例更新任务。坚持几个周期后，历史基线自然形成，高低判断就有了可靠参照。
常见问题
用例总数很多但执行量很少时，失效率还能算吗？
可以算，但要同时给出执行覆盖率，并标注样本是否充足。分母只取执行用例数，未执行用例不计入，因此执行量少时比率波动会明显放大。执行用例数少于 30 时，建议在报表中同时列出绝对数和“样本不足”提示，避免读者把偶然波动当成趋势。执行用例数为零时失效率无定义，应显示“不适用”并注明原因，不用 0% 代替。
同一条用例在一轮里执行了多次，结果不一致怎么记？
以最后一次有效执行结果为准，同时把这条用例标记为“结果不稳定”单独列出，不重复计入分子。跨轮次合并统计时按用例去重，取该时间窗内最近一次执行结果。如果结果不一致频繁出现，通常指向环境不稳定或用例步骤描述不清，可以结合失效原因分类进一步排查。
失效率下降是否说明产品质量变好了？
不能直接这样推断。失效率反映的是用例执行层面的情况，下降可能来自用例更新、执行范围调整或覆盖率变化。判断质量变化还需要看缺陷数量、缺陷严重程度、缺陷逃逸率和需求覆盖率。比较两轮数据前，先确认用例集是否有增删、执行覆盖率是否同步变化，口径一致时对比才有意义。
不同项目之间可以直接比较失效率吗？
直接比较容易得出错误结论。用例粒度、项目复杂度、执行覆盖率不同，失效率的合理区间差异很大。需要比较时，先按用例类型分层，再选择粒度与覆盖率相近的项目，并优先与自身历史基线对比。覆盖率明显偏低的项目，样本代表性弱，报表中应注明，不宜作为横向排名的依据。
失效归类由谁做，怎么保证不同人判定一致？
通常由执行该轮测试的测试人员完成归类，测试负责人或用例负责人定期复核。保证一致性靠三件事：失效原因使用固定枚举值而非自由文本；每轮抽取一定比例的失效用例复核，记录判定人和判定依据；把典型判定样例整理成说明，供新成员参照。复核结果用于校准口径，发现分歧时优先修订判定标准，再回看历史数据是否需要重算。
