测试用例失效率的核心算法是“失效用例数÷执行用例数×100%”。要让这个比例可复算、可解释，统计前需要先固定三件事：失效的判定标准、统计时间窗、分母是否只计已执行用例。本文围绕用例设计与内容质量，给出从口径定义到结果解读的完整方法，并说明分母为零、跨期不可比等情况的处理方式。
要点总览（TL;DR）
- 失效率＝失效用例数÷执行用例数×100%，分子按用例去重，分母只计已执行用例，阻塞、跳过、未执行均排除。
- 统计前先固定失效判定规则、时间窗和分母口径，并用字段口径表写明来源与缺失处理，保证不同人算出同一结果。
- 整体失效率用总失效数除以总执行数，不能把各模块失效率简单平均；分母为零时显示为“—”，不能记为0%。
- 判断高低以历史基线、同类模块对比和趋势变化为参照，同时看失效原因构成，用例缺陷占比高才指向设计质量问题。
- 失效率是描述性指标，用例基数小、口径中途变更或用于绩效排名都会导致误读，需结合缺陷密度、覆盖率等证据共同判断。
统计前先定评估目标：失效率要回答什么问题
失效率是一个比例，本身不说明问题出在哪里。统计之前先明确它服务于哪个判断，才能决定统计粒度和拆分维度。常见的目标有三类：发现用例设计的薄弱模块、评估用例维护投入是否合理、验收测试资产的整体质量。目标不同，统计的粒度和使用人差别很大。
| 评估目标 | 统计粒度 | 主要使用人 | 关注重点 |
|---|---|---|---|
| 发现设计薄弱模块 | 按模块、按用例类型拆分 | 测试负责人、模块负责人 | 哪些模块失效率明显高于同类 |
| 评估用例维护投入 | 按版本周期、按失效原因拆分 | 测试负责人 | 因用例本身错误导致的失效占比 |
| 验收测试资产质量 | 按版本整体、按优先级拆分 | 质量工程师、项目负责人 | 整体失效率与历史基线的偏离 |
本文讨论的范围限于用例设计及内容质量，包括用例步骤、预期结果、前置条件是否准确完整。测试脚本实现层面的问题、跨项目用例资产复用策略不在本文展开。明确这个边界，可以避免把自动化脚本缺陷或资产迁移问题混入失效率，导致结论失真。
失效判定标准与统计范围
失效判定不一致，是不同人算出不同失效率的首要原因。建议在统计前形成一份书面规则，逐条写明什么情况计为失效、什么情况不计入，并在团队内统一执行。
失效判定规则清单
- 执行结果与预期结果不符，且经复核确认预期结果正确，计为失效。
- 用例本身存在错误，例如步骤缺失、预期结果写错、前置条件不成立，导致无法按用例正常执行，计为失效，并单独标记为“用例缺陷”。
- 因环境不可用、测试数据缺失导致用例无法执行，归为阻塞，不计入失效，也不计入分母。
- 同一用例在同一统计周期内多次执行均失败，按用例去重计一次失效；如需反映稳定性问题，另设“失效次数”指标单独统计。
- 需求变更导致预期结果失效、用例尚未更新的，先标记为“待更新”，在用例修订完成前不计入失效，避免把需求变化误判为设计质量问题。
纳入与排除范围
分母只纳入已执行用例，即实际运行并产生明确结果的用例。未执行、阻塞、跳过、重复登记的用例均排除在分母之外。按用例类型、优先级、模块划分统计单元时，每个统计单元内部同样遵循这一纳入排除规则，保证分项之和与整体口径一致。
数据口径：分子、分母与时间窗
口径固定后，任何人拿同一批原始记录都应算出相同结果。建议用一张字段口径表把每个字段的定义、来源和缺失处理写清楚，作为统计脚本或报表配置的依据。
| 字段名 | 定义 | 来源 | 缺失处理 |
|---|---|---|---|
| 失效用例数（分子） | 统计周期内判定为失效的用例数，按用例去重 | 用例执行记录中的执行结果与复核结论 | 执行结果为空的不计入，标记待补录 |
| 执行用例数（分母） | 统计周期内实际执行并产生明确结果的用例数，不含阻塞与跳过 | 用例执行记录 | 结果状态缺失的按未执行处理，不计入分母 |
| 统计时间窗 | 版本周期、迭代周期或自然月，三者择一并全程保持一致 | 版本计划或迭代计划 | 跨窗口执行的用例归入结果产生时点所在窗口 |
| 失效原因 | 用例缺陷、产品缺陷、环境问题、需求变更等分类 | 执行记录备注或关联缺陷单 | 未填写的归入“未分类”，单独列示 |
时间窗的选择影响可比性。按版本周期统计适合版本质量验收，按迭代统计适合过程改进，按自然月统计适合跨团队横向对比。三种窗口的数值不能直接混用，跨期比较时必须保持同一窗口类型。数据缺失或口径变更导致不可比时，应在报表中注明变更点和生效时间，必要时对历史数据按新口径重算后再比较。
计算步骤与公式
失效率的计算公式为：失效率＝失效用例数÷执行用例数×100%。分子分母均以“用例”为单位，按去重口径计数，结果以百分比表示，保留一位小数即可满足多数场景。
分步计算流程
- 确定统计时间窗，从执行记录中筛出该窗口内产生结果的用例。
- 剔除阻塞、跳过、未执行的记录，得到执行用例数，作为分母。
- 按失效判定规则逐条复核失败记录，确认后按用例去重，得到失效用例数，作为分子。
- 按模块、版本等维度分别计算分项失效率，再用同一口径计算整体失效率。
- 同步统计失效用例绝对数和失效原因分布，与失效率一并输出。
分项计算与汇总计算需要区分：整体失效率应直接用总失效数除以总执行数，不能把各模块失效率简单平均，否则执行量小的模块会被过度放大。分项失效率用于定位问题模块，整体失效率用于对外汇报，两者口径一致但计算路径不同。
分母为零时，失效率无定义，报表中应显示为“—”，并注明该单元本期无执行记录，不能记为0%。0%会被误读为全部通过，与实际情况相反。配套指标建议至少包含失效用例绝对数、失效原因分布两项，前者反映问题规模，后者反映问题性质，二者与失效率结合才能支撑判断。
一个可复算的统计例子
以下为演示情景，数据为示例，非真实项目数据。某版本按模块统计执行与失效情况，失效原因分为用例缺陷、产品缺陷、环境问题三类。
| 模块 | 执行用例数 | 失效用例数 | 失效率 | 用例缺陷 | 产品缺陷 | 环境问题 |
|---|---|---|---|---|---|---|
| 模块A | 120 | 18 | 15.0% | 3 | 13 | 2 |
| 模块B | 80 | 4 | 5.0% | 1 | 2 | 1 |
| 模块C | 50 | 9 | 18.0% | 6 | 2 | 1 |
| 合计 | 250 | 31 | 12.4% | 10 | 17 | 4 |
整体失效率为31÷250×100%＝12.4%，由合计行直接相除得到。若把三个模块的失效率简单平均，会得到约12.7%，与真实值存在偏差，这正是汇总需用总量相除的原因。分模块看，模块C失效率最高，但其失效中6例为用例缺陷，说明该模块用例设计需要优先修订；模块A失效率次之，失效主要来自产品缺陷，改进方向在产品侧而非用例侧。失效原因拆分让同样的比例指向了不同的行动。
失效率高低如何判断
失效率没有通用达标线，判断高低需要参照系。可用的参照有三类：历史基线、同类模块对比、趋势变化。历史基线取同一模块前几个版本的失效率中位数，偏离基线一定幅度再结合绝对数判断；同类模块对比适合在模块间定位异常；趋势变化看连续多个窗口的走向，单期波动不足以说明问题。
| 参照系 | 适用条件 | 判断方式 |
|---|---|---|
| 历史基线 | 模块稳定、口径未变更 | 与近几个版本中位数比较，结合失效绝对数 |
| 同类模块对比 | 模块规模、复杂度相近 | 找出明显偏离群体水平的模块 |
| 趋势变化 | 连续三个以上统计窗口 | 看方向而非单点，区分偶发与持续 |
判断时需区分失效原因构成。用例缺陷占比高，指向设计质量问题；产品缺陷占比高，说明用例在有效发现问题；环境问题占比高，则反映执行条件不稳定，与用例质量关系不大。单指标不能代表整体质量，应结合缺陷密度、用例覆盖率、执行完成率等证据共同判断。结论表述建议采用“在某参照系下，某模块失效率为X%，高于基线Y个百分点，其中用例缺陷占Z例，建议优先修订该模块用例”的格式，写明参照系、数值和依据，并安排第二人复核原始记录，减少口径误读。
解读限制与常见统计误区
失效率是描述性指标，反映的是执行结果分布，不能直接推出设计质量结论。以下误区在统计实践中较为常见，使用前应逐条核对。
- 把失效率高直接等同于设计质量差。失效可能来自产品缺陷或环境问题，需先看失效原因构成再下结论。
- 分母口径中途变化导致跨期不可比。例如某期开始把阻塞用例计入分母，前后数值不能直接比较，需注明变更或重算历史数据。
- 用例基数小或执行不充分时结果不稳定。执行几十条用例得出的比例波动很大，不宜作为模块间比较依据。
- 把指标用于绩效排名。失效率受模块复杂度、需求变更频率影响，脱离上下文排名会诱导规避执行或挑选用例，反而损害数据真实性。
- 忽略未分类失效。失效原因未填写的记录应单独列示并推动补录，直接并入某一类会扭曲原因分布。
在统计流程落地时，执行记录与缺陷的关联质量直接决定口径能否执行。ONES TestCase 支持用例分配执行人，未通过的用例可快速创建缺陷任务，用例与需求、任务关联，测试计划与迭代关联，使执行结果、失效记录与缺陷处理处在同一条流程中；其质量统计报表与测试报告可承载执行进度和通过率等数据，测试报告模板支持按业务场景自定义组装。失效率的具体计算规则仍需团队按本文口径定义，报表字段是否覆盖失效率及模块、版本拆分维度，建议在配置阶段实际核验后再确定。
常见问题
同一用例在一个统计周期内多次执行都失败，失效率里算几次？
按去重口径计一次。失效率的分子是“失效用例数”，单位是用例，同一用例在周期内多次失败仍只计一条，否则执行次数多的用例会不成比例地拉高比例。如果需要反映稳定性，另设“失效次数”指标单独统计，与失效率并列展示，两者口径不同，不能混用。
这个规则要在统计前写进口径表，并保证分模块、分版本计算时同样执行，否则分项之和会与整体值对不上。
用例因为需求变更而过时，执行失败算不算失效？
建议先标记为“待更新”，在用例修订完成前不计入失效。需求变更导致预期结果不再成立，属于用例需要维护的信号，与用例设计质量问题是两回事。直接计入失效会推高失效率，让改进方向偏向错误的结论。
如果这类情况较多，可以单独统计“待更新用例数”作为配套指标，反映需求变更对用例资产的冲击程度，并推动用例同步修订的节奏。
不同版本或不同团队的失效率可以直接比较吗？
只有在口径一致时才可比。需要核对三点：分母是否都只计已执行用例、失效判定规则是否相同、时间窗类型是否一致（版本周期、迭代、自然月三者不能混用）。任何一项变化都会让数值失去可比性。
口径确实调整过，应在报表中注明变更点和生效时间，必要时按新口径重算历史数据再比较。模块复杂度、需求变更频率差异较大的团队之间，也建议先看趋势和原因构成，再谈数值高低。
执行用例很少的模块，失效率波动很大，怎么处理？
用例基数小时比例不稳定，几十条用例的失效率容易因个别结果大幅跳动，不宜直接用于模块间排名。处理方式有三种：一是同时给出失效绝对数，让读者看到规模；二是合并多个统计窗口看累计值；三是设定最小样本量，低于该量只展示数据不做高低判断。
样本量门槛由团队按自身执行规模确定，写进口径说明即可，不需要统一标准。
失效率统计落地时，执行记录和缺陷怎么关联比较省事？
关键是让执行结果、失效记录和缺陷处理处在同一条流程里。ONES TestCase 支持用例分配执行人，未通过的用例可快速创建缺陷任务，用例与需求、任务关联，测试计划与迭代关联（claim F1、F2）；质量统计报表与测试报告可承载执行进度和通过率等数据，测试报告模板支持按业务场景自定义组装（claim F3、F4、F5）。
失效率的具体计算规则仍需团队按本文口径定义，报表字段是否覆盖失效率及模块、版本拆分维度，建议在配置阶段实际核验后再确定。
