判断测试用例失效率高低，前提是先固定统计口径：失效率等于统计窗口内执行结果为失败的用例执行次数除以同期有效执行次数，未执行、阻塞、跳过的记录不计入分母。口径统一后，再按用例、模块、版本分层计算，与自身历史基线和同类模块基线对比，并结合失败原因归类解读。单次比例不足以直接下结论，样本量、时间窗和分母完整性都会影响判断。下文给出一套可复算的统计与评估方法。
要点总览（TL;DR）
- 判断失效率高低，先固定口径：失效率=统计窗口内失败执行次数÷同期有效执行次数，未执行、阻塞、跳过不计入分母，同一用例多次执行按次数计。
- 整体比例不足以说明高低，需按用例、模块、版本分层计算，并与自身历史基线、同类模块基线对比，同时说明分母规模和时间窗。
- 失败原因归类决定解读方向：产品缺陷、用例过时、环境或数据问题、步骤歧义各自占比不同，对应的改进动作也不同。
- 失效率不等同产品缺陷率，也不设通用达标线；阈值应基于团队自身历史数据和风险容忍度设定，并注明适用版本与范围。
评估目标：判断失效率高低要回答什么
“失效率高不高”本身是一个比较问题，需要先明确比较对象和比较基准。同一个比例，放在单个用例、一个模块或一个版本上，含义完全不同；与上月比、与同类模块比、与发布前风险容忍度比，结论也可能相反。评估开始前，先把问题转化为可回答的形式，后续取数和计算才有方向。
失效率同时承载两类信号，解读时要分开看。一类反映用例内容质量：步骤描述含糊、预期结果不明确、测试数据过期，都会让用例在执行时被判失败，但产品本身可能正常。另一类反映产品缺陷暴露：用例设计准确，执行失败说明产品在该场景下确实存在问题。两类信号混在一个比例里，直接说“失效率高”容易把设计问题和质量问题混为一谈。
评估结论的用途也决定了判断标准。如果目的是改进用例设计，关注点应放在失败原因中“用例过时”“步骤歧义”的占比，以及这些用例集中在哪些模块、哪些编写批次。如果目的是版本质量预警，关注点应放在排除用例自身问题后，由产品缺陷导致的失败比例及其变化趋势。两种用途可以共用一套原始数据，但判断阈值和分层方式不同。
开始统计前，建议先填写一份评估目标清单：
- 评估对象：用例集、模块、版本，还是三者的组合；
- 比较基准：自身历史同期、上一版本、同类模块，或发布准入要求；
- 结论用途：用例设计改进、版本质量预警，或两者兼有；
- 责任角色：谁负责确认失败原因归类，谁负责对结论做最终判断；
- 输出形式：分层统计表、失败原因分布，还是趋势对比。
这份清单不需要复杂，但要在取数前确定，避免统计完成后发现口径与用途不匹配、需要重算。
指标与范围：失效率的分子、分母与统计边界
本文采用的失效率定义如下：
失效率 = 统计窗口内执行结果为失败的用例执行次数 ÷ 同期有效执行次数 × 100%
分子是执行结果为“失败”的执行记录条数，分母是同一统计窗口内所有有效执行记录条数，包括通过和失败。单位是百分比，也可以同时给出绝对次数，便于判断样本规模。这个定义以“执行次数”为计数单位，同一用例在不同轮次、不同环境、不同版本中多次执行，每次都单独计入。它与“用例数口径”不同：用例数口径统计的是“有多少条用例至少失败过一次”，适合看问题覆盖面；执行次数口径统计的是“失败发生在多少次执行中”，适合看执行稳定性。两种口径不能混用，报告中应注明采用哪一种。
纳入与排除规则需要在统计前写清楚：
| 执行结果 | 是否计入分子 | 是否计入分母 | 说明 |
|---|---|---|---|
| 通过 | 否 | 是 | 有效执行 |
| 失败 | 是 | 是 | 有效执行，需记录失败原因 |
| 未执行 | 否 | 否 | 尚未产生执行结果 |
| 阻塞 | 否 | 否 | 因前置条件不满足无法执行，单独统计阻塞率 |
| 跳过 | 否 | 否 | 按计划不执行，不计入有效性判断 |
| 重复执行 | 按每次结果分别计 | 按每次执行分别计 | 回归、复测均视为独立执行记录 |
统计时间窗和版本范围同样属于口径的一部分。时间窗可以是单个迭代、一个发布周期或固定自然周，窗口过短会让比例随个别用例波动。版本范围要明确是某一个版本的全部执行记录，还是包含补丁版本和回归轮次；跨版本汇总时，应确认各版本的用例集和执行范围可比，否则比例差异可能来自用例构成变化，而非质量变化。
数据口径与证据：从哪里取数、如何保证可比
失效率的计算依赖执行记录，取数前先确认记录中包含以下字段，缺字段会导致分子分母无法准确还原：
| 字段 | 用途 | 缺失时的处理 |
|---|---|---|
| 用例标识 | 区分用例，支持按用例维度聚合 | 无法按用例分层，只能做整体统计 |
| 所属模块 | 支持模块维度对比 | 模块对比不可用，需补充映射关系 |
| 所属版本或迭代 | 确定统计范围 | 版本维度结论不可靠 |
| 执行时间 | 划定统计窗口 | 无法按时间窗截取，需改用其他边界 |
| 执行结果 | 区分通过、失败、阻塞、跳过 | 指标无法计算 |
| 执行人 | 辅助核查记录真实性 | 不影响计算，但降低可追溯性 |
| 失败原因分类 | 区分产品缺陷与用例自身问题 | 只能看比例，无法解释高低来源 |
失败原因分类字段是解读失效率的关键。建议至少区分四类：产品缺陷、用例过时、环境或数据问题、步骤歧义。分类由执行人在提交失败结果时选择，测试负责人定期抽查一致性。没有这个字段，失效率只能作为总量信号，无法回答“高是因为产品问题多，还是用例需要维护”。
分母为零和数据缺失要单独处理。某个模块在统计窗口内没有有效执行记录时，失效率无定义，应标注“无有效执行”，不能记为0%，否则会拉低整体比例。执行结果字段为空或状态不明的记录，应先清理再统计，并在报告中说明清理条数。跨模块、跨版本比较前，逐项核对用例集范围、执行轮次、失败原因分类标准是否一致；口径不一致时，先对齐再比较，或只做同口径内的对比。
在测试管理工具中，执行记录通常与用例、计划、版本关联保存。以ONES测试管理为例，用例可分配执行人，未通过的用例可快速创建缺陷任务，测试计划与迭代关联，测试情况概览中提供进度和通过率信息；用例属性支持自定义和筛选，可用于标记失败原因分类等字段。具体报表字段和统计口径需按实际环境确认，失效率通常需要在执行记录基础上按上述公式自行汇总或配置。
计算与评估步骤：从统计到高低判断
计算按以下步骤推进，每一步都保留中间结果，便于复核和解释。
第一步，确定统计范围和窗口。选定版本或迭代，划定起止时间，导出该范围内的全部执行记录，按纳入排除规则清理无效记录，得到有效执行总数，即分母。
第二步，计算整体失效率。统计失败执行次数作为分子，代入公式得到整体比例。同时记录分母规模，分母过小时比例参考价值有限。
第三步，按用例、模块、版本分层计算。用例维度看哪些用例反复失败，模块维度看失败是否集中，版本维度看趋势变化。分层后每层都保留分子、分母和比例三项，避免只看比例忽略样本量。
第四步，与基线对比。基线有两类：自身历史基线，即同一模块或同一用例集在过去若干窗口的失效率；同类模块基线，即当前版本内其他模块的中位水平或分布区间。对比时使用相同口径和相近窗口长度。没有历史数据时，可以先建立当前窗口的模块分布，把明显偏离分布主体的模块列为观察对象，而不是直接判定高低。
第五步，判断波动是否显著。分母较小或窗口较短时，个别失败就能让比例大幅变化。可以把当前窗口与基线的差异同历史窗口间的正常波动范围比较；差异落在正常波动范围内，暂不判定为异常，继续观察。样本量很小时，优先看绝对失败次数和失败用例清单，比例仅作参考。
第六步，按失败原因归类后再判断。把失败执行按原因分类统计。产品缺陷类失败占比高，说明失效率反映的是产品质量信号；用例过时、步骤歧义类占比高，说明用例内容需要维护；环境或数据问题占比高，说明执行条件需要治理。归类后的结论比整体比例更能指导行动。
完成六步后，形成分层结果表，每行包含对象、分子、分母、失效率、基线值、差异和主要失败原因。判断结论写成“某模块失效率高于自身历史基线，主要由用例过时导致，建议优先维护该批用例”，比“失效率偏高”更有可执行性。
例子：一个版本失效率的计算与解读
以下为演示情景，数据为虚构，仅用于说明计算过程。
某版本测试窗口内，模块A共有执行记录500条，其中通过420条、失败50条、阻塞20条、跳过10条。按纳入排除规则，阻塞和跳过不计入分母，有效执行次数为470次，失败执行次数为50次。
整体失效率 = 50 ÷ 470 × 100% ≈ 10.6%。
进一步按失败原因归类：产品缺陷30条、用例过时12条、环境或数据问题5条、步骤歧义3条。按原因折算，产品缺陷导致的失效率约为30 ÷ 470 ≈ 6.4%，用例自身问题导致的失败约为15 ÷ 470 ≈ 3.2%。
再看分层。模块A内部，子模块A1执行120次、失败28次，失效率约23.3%；子模块A2执行200次、失败14次，失效率7.0%；子模块A3执行150次、失败8次，失效率约5.3%。A1明显高于同模块其他部分。查看A1的失败清单，28次失败中有16次集中在3条用例上，且这3条用例的失败原因均标记为“用例过时”，原因是产品界面改版后预期结果未更新。
解读结论：模块A整体失效率10.6%，高于A2、A3的水平，但主要拉高因素来自A1的3条过时用例。排除这部分后，A1由产品缺陷导致的失败为12次，失效率约10%，与模块整体水平接近。因此，该版本的判断是：用例维护问题突出，产品缺陷信号处于常规范围；行动上优先更新A1的过时用例，复测后重新计算，再判断是否需要扩大缺陷排查。
这个示例的适用边界需要说明：数据规模、原因分类比例和基线水平均为演示设定，实际项目中分母构成、失败原因分布和基线值都会不同；示例展示的是计算和归因方法，不能把10.6%或23.3%当作通用参考线。
解读与限制：哪些情况不能只看失效率
失效率是一个结果指标，它把多种原因压缩成一个比例，单独使用容易误判。以下情形需要结合配套证据再下结论。
- 用例过时造成的假失败。产品迭代后界面、流程、数据要求变化，用例未同步更新，执行时被判失败。这类失败推高失效率，但不代表产品质量下降。配套证据：失败原因分类、用例最近更新时间、失败是否集中在少数用例。
- 环境与数据问题造成的失真。测试环境不稳定、依赖服务不可用、测试数据被污染，会让本应通过的用例失败。配套证据：环境可用性记录、同一用例在其他环境的执行结果、失败时间分布。
- 步骤歧义导致的执行差异。不同执行人对同一用例的理解不同，结果不一致。配套证据：执行人分布、失败复现情况、用例评审记录。
- 分母构成变化。新增大量简单用例或减少高风险场景用例，都会改变整体比例，与质量变化无关。配套证据：用例集版本对比、执行范围说明。
- 样本量不足。分母很小或窗口很短时，比例波动大。配套证据：绝对失败次数、历史窗口波动范围。
失效率不能等同产品缺陷率。缺陷率通常以缺陷数量与需求、代码量或测试工作量之比衡量，失效率衡量的是执行结果中失败所占比例，两者统计对象不同。用例设计得越严格，执行失败可能越多，但产品缺陷未必更多；反之，用例覆盖不足时失效率可能很低，却掩盖了未测到的风险。判断产品质量需要把失效率与缺陷分布、需求覆盖率、遗留缺陷等指标一起看。
本文不设通用达标线。不同团队、不同模块的历史水平和风险容忍度差异很大，阈值应基于自身历史数据设定，并注明适用的版本、模块和时间窗。阈值一旦设定，也应定期复核，避免把早期基线固化为长期标准。失效率适合作为观察和归因的起点，配合失败原因分类、分层数据和趋势对比，才能支撑用例设计改进和版本质量判断。
常见问题
统计窗口内某个模块没有执行记录，失效率应该记为0%吗？
不应记为0%。分母为零时失效率无定义，记为0%会拉低整体比例，造成质量良好的假象。建议在报表中标注“无有效执行”，并在汇总时单独列出这类模块，说明其未纳入整体计算。若该模块本应有执行计划却未执行，这本身是需要跟进的执行缺口，可与阻塞率、执行进度一起看。
同一用例在回归中多次执行，失败一次通过两次，失效率怎么算？
按执行次数口径，这条用例贡献3次有效执行，其中1次失败，失效率为1÷3≈33.3%。如果采用用例数口径，它只算1条失败用例，比例是1÷1=100%。两种口径回答的问题不同：执行次数口径看执行稳定性，用例数口径看问题覆盖面。报告中注明采用哪一种，跨版本对比时保持同一口径，避免因口径切换造成趋势误读。
团队第一次统计失效率，没有历史基线，怎么判断高低？
可以先建立当前窗口的模块分布：把各模块的失效率按数值排序，观察分布主体和明显偏离的少数模块，把偏离者列为观察对象，而非直接判定异常。同时保留分子、分母和失败清单，作为下一窗口的基线。积累两到三个窗口后，用历史窗口间的波动范围判断当前变化是否显著。首次统计的结论宜写成观察项和改进项，暂不下质量定论。
失效率下降是否说明用例质量或产品质量变好了？
需要看下降的来源。如果失败原因中用例过时、步骤歧义的占比同步下降，说明用例维护到位；如果分母中新增了大量简单用例、高风险场景用例被移出执行范围，比例下降可能与质量无关。建议同时对比用例集版本、执行范围和失败原因分布，确认下降来自真实改善而非统计构成变化。
在测试管理工具里，失效率能直接生成吗？
多数工具提供执行记录、通过率概览和测试报告，失效率是否作为现成指标提供，取决于具体产品的报表字段和口径配置。以ONES测试管理为例，测试情况概览提供测试计划的进度和通过率，用例属性支持自定义和筛选，可用于标记失败原因分类；失效率通常需要在执行记录基础上按本文公式汇总或配置报表。具体字段和统计口径建议在实际环境中确认后再固化到报告中。
