测试通过率、失败数和阻塞数经常被误读，根源往往在统计口径：分母选谁、失败与阻塞怎么分、重跑和未执行算不算，不同人各按一套算法，同一批数据就会得出不同结论。本文给出一套可复算的统计规则，包括指标定义、四类结果的互斥归类、计算公式和一个算例，并说明这些数字能说明什么、不能说明什么。
要点总览（TL;DR）
- 通过率建议以有效执行用例数（通过+失败+阻塞）为分母，同时并列给出计划用例数作为执行完成度参照，两个数一起看才能避免“没跑”被误读成“质量差”。
- 失败与阻塞按“能否执行”区分：断言不通过计为失败，因环境、依赖或前置数据无法执行计为阻塞，阻塞不计入失败。
- 重跑用例按去重后的用例计数，并注明重跑次数；分母为零时标注“无有效执行”，不输出0%或100%。
- 报表固定呈现计划数、有效执行数、通过数、失败数、阻塞数、未执行数、通过率和重跑次数，缺项会让读者自行补算得出不同结论。
- 这三个指标描述执行过程，不能单独当作质量结论；跨轮次、跨团队比较前先对齐分母、重跑规则和阻塞判定。
评估目标：这三个数字要回答什么问题
通过率、失败数、阻塞数分别服务于不同的判断，混用会让结论失真。统计之前先明确每个指标要回答的问题，再决定怎么算。
- 通过率回答“本轮执行到什么程度、质量趋势如何”。它适合看同一口径下的轮次变化，或同一版本内不同模块的相对表现。
- 失败数回答“还有多少用例需要修复或复测”。它直接对应待处理范围，是安排修复和回归排期的依据。
- 阻塞数回答“有多少用例因为环境、依赖或前置条件无法执行”。它暴露的是执行条件问题，指向环境准备和跨团队依赖。
三者不能互相替代：通过率高可能只是大量用例未执行，失败数少可能因为阻塞太多根本没跑，阻塞数上升也不代表代码质量下降。它们也不能合成一个“质量总分”，因为每个数字背后的原因不同，合并会掩盖需要分别处理的问题。
指标与范围：统计对象、时间窗和分母
同一批数据算出不同结果，通常差在三个地方：统计对象、时间窗和分母。把这三项写进指标定义，结果才可复算。
统计对象：执行记录还是用例
按“用例执行记录”统计，一条用例重跑三次就产生三条记录，通过率会被重跑次数影响；按“用例去重”统计，一条用例只算一次，反映的是用例维度的覆盖情况。失败数和阻塞数建议按去重后的用例计数，单位为例，这样数字直接对应待处理清单的长度。通过率的分母则要明确是记录数还是用例数，并在报表中注明。
时间窗：按轮次、按自然日还是按版本截止
按测试轮次统计适合判断单轮执行质量；按自然日统计适合看每日进展，但跨日重跑会让同一用例出现在多天；按版本截止时间统计适合发布判断，需要明确截止时点之后的结果是否回填。三种口径都可用，关键是同一份报告内保持一致，跨报告比较前先对齐。
分母：计划数、已执行数与有效执行数
| 分母口径 | 含义 | 适用判断 |
|---|---|---|
| 计划用例数 | 本轮纳入范围的用例总数 | 执行完成度，反映还有多少没跑 |
| 已执行用例数 | 已有结果记录的用例数，含失败和阻塞 | 执行进度，但会把阻塞算进“已执行” |
| 有效执行用例数 | 通过 + 失败 + 阻塞，不含未执行与跳过 | 通过率的分母，反映真正跑出结果的用例 |
通过率建议用有效执行数作分母，同时并列给出计划用例数作为完成度参照。只用计划数作分母时，未执行越多通过率越低，读者容易把“没跑”误读成“质量差”；只用有效执行数作分母时，又要防止大量阻塞被排除后通过率虚高，所以两个数要一起看。
未执行和跳过的用例不计入有效执行数，但在报表中单列数量。跳过需要注明原因（如功能裁剪、环境不支持），否则跳过会被当成隐性通过。
数据口径：四类结果如何互斥归类
通过、失败、阻塞、未执行四类结果必须互斥，合计等于统计范围内的用例数。归类规则先定清楚，分子分母才能一致。
阻塞的判定条件
用例因环境不可用、依赖服务未就绪、前置测试数据缺失而无法执行时，计为阻塞。判定要点是“无法开始执行或无法完成执行”，并且原因不在用例本身。执行人应在结果中记录阻塞原因和关联的依赖项，便于后续追踪解除条件。
失败与阻塞的边界
用例能够执行、断言结果不符合预期，计为失败；用例无法执行，计为阻塞。边界情形按以下方式处理：
- 执行到一半环境中断，已执行步骤未发现断言失败：计为阻塞，并注明中断位置。
- 前置数据错误导致断言不通过：先确认是用例数据问题还是产品问题，属于测试数据缺陷的修正后重跑，属于产品问题的计为失败。
- 依赖接口返回异常导致用例无法继续：计为阻塞，关联依赖项；若接口异常本身是本次版本引入的缺陷，另行记录缺陷，不改变该用例的阻塞归类。
阻塞不计入失败。把阻塞算进失败会放大缺陷范围，让修复排期失真；把失败算进阻塞会掩盖真实缺陷。
重跑与状态未更新
重跑结果需要事先约定取值规则：以最后一次执行结果为准，或保留首次结果并单独记录重跑。无论哪种，统计时一条用例只计一次，并注明重跑次数。状态未更新或结果缺失的用例，按未执行处理并在报表中标注，不能默认计为通过。
计算步骤：公式、单位与去重规则
归类完成后按以下步骤计算，每一步都保留分子、分母和单位，方便他人复算。
- 确定统计范围：选定测试轮次或版本截止时间，列出纳入的用例清单，得到计划用例数（单位：例）。
- 去重归类：每条用例取约定的结果值，归入通过、失败、阻塞、未执行四类之一，四类之和等于计划用例数。
- 计算有效执行数：有效执行数 = 通过 + 失败 + 阻塞，不含未执行与跳过。
- 计算通过率：通过率 = 通过用例数 ÷ 有效执行用例数 × 100%。同时给出计划用例数作参照。
- 统计失败数与阻塞数：按去重后的用例计数，单位为例，并附重跑次数和阻塞原因分布。
- 处理分母为零：有效执行数为零时标注“无有效执行”，不输出0%或100%，避免被读成全部失败或全部通过。
报表中建议固定呈现：计划数、有效执行数、通过数、失败数、阻塞数、未执行数、通过率、重跑次数。缺任何一项，读者都可能自行补算并得出不同结论。
一个算例：同一批数据的不同读法
以下为演示情景，数字为说明口径差异而构造，非真实项目数据。某轮测试计划用例100例，执行后结果为：通过70例，失败10例，阻塞8例，未执行12例，其中3例失败用例各重跑一次后通过。
按计划数为分母
通过率 = 70 ÷ 100 × 100% = 70%。这个数字同时包含了“没跑”的部分，读者容易理解为三成用例质量不达标。
按有效执行数为分母
有效执行数 = 70 + 10 + 8 = 88例，通过率 = 70 ÷ 88 × 100% ≈ 79.5%。这个数字反映的是已跑出结果的用例中通过的比例，配合“未执行12例、阻塞8例”一起看，才能判断本轮的真实状态：执行尚未完成，且有一成用例受环境或依赖影响。
重跑去重前后的失败数
若按执行记录统计，3例重跑通过会产生额外的通过记录，失败记录仍保留首次结果，失败数显示为10例；按用例去重、以最后一次结果为准，这3例计为通过，失败数为7例。两种算法都合理，但必须在报表中注明取值规则，否则同一轮数据会出现10和7两个失败数。本算例采用去重后口径：通过73例，失败7例，阻塞8例，有效执行数88例，通过率约83.0%。
解读与限制：哪些结论不能从这三个数得出
这三个指标描述的是测试执行过程，不能直接当作质量结论。解读时注意以下边界。
- 通过率高不代表缺陷少。用例覆盖不到的场景不会产生失败记录，需要结合缺陷数据、缺陷严重程度分布和新增缺陷趋势一起判断。
- 阻塞数不能直接归因于质量。阻塞受环境可用性、依赖排期和测试数据准备影响，应作为执行条件问题单独跟进。
- 样本量小时比率波动大。十几例用例的通过率变化几个百分点没有太多含义，应同时给出绝对数，必要时按模块拆分看。
- 跨轮次、跨团队比较要先对齐口径。分母选择、重跑规则、阻塞判定不一致时，比较结果没有意义。
- 指标用于过程跟踪，不单独作为绩效结论。把通过率与个人考核直接挂钩，容易诱导回避难用例或把失败改记为阻塞。
当团队需要把这套口径固定下来时，可以把用例执行记录、结果状态和重跑记录放在同一处承载，让统计直接取自执行数据。ONES TestCase 支持测试计划的规划和执行，可多维度概览测试计划进度，并提供测试情况概览以了解测试计划的进度和通过率；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。这样，通过率、失败数与阻塞数的口径就落在同一份执行记录上，报表中的分母和排除项也有据可查。具体报表字段和状态分类粒度以团队实际配置为准，跨版本比较前仍需确认口径一致。
常见问题
如果本轮测试有大量用例未执行，通过率应该怎么报才不误导？
建议同时报两个数：以有效执行用例数为分母的通过率，以及计划用例数、未执行数。只报计划数为分母的通过率，未执行越多数字越低，容易被读成质量差；只报有效执行数为分母的通过率，又会掩盖执行尚未完成的事实。两个数并列，读者才能区分“没跑”和“跑了没通过”。
同一条用例重跑后通过，失败数应该算一次还是两次？
按用例去重计数，一条用例只算一次，单位为例。取值规则需事先约定：以最后一次执行结果为准，或保留首次结果并单独记录重跑。无论选哪种，都要在报表中注明规则和重跑次数，否则同一轮数据会出现两个不同的失败数。若按执行记录统计，重跑产生的额外记录会改变分子分母，比较时需先对齐。
阻塞用例在修复依赖后重新执行，历史阻塞数要回填修改吗？
建议保留历史轮次的原始记录，不回填修改。阻塞解除后重新执行的结果计入新的执行记录，并在报表中说明该用例此前处于阻塞状态。回填会让同一轮次的历史报表前后不一致，跨轮次比较时也无法还原当时的执行条件。若需要看阻塞解除情况，可单独统计阻塞用例的解除数量和平均解除时长。
团队规模小、用例数量少时，通过率还有参考价值吗？
样本量小时比率波动大，十几例用例的通过率变化几个百分点含义有限。此时应同时给出绝对数（通过几例、失败几例、阻塞几例），必要时按模块拆分看。通过率更适合看同一口径下的趋势变化，而非单轮绝对值的高低。用例数量少的团队可以把关注点放在失败和阻塞的具体清单上，逐条跟进。
把通过率、失败数、阻塞数放进同一份执行记录里统计，工具上怎么落地？
关键是让统计直接取自执行数据，避免人工二次汇总。ONES TestCase 支持测试计划的规划和执行，可多维度概览测试计划进度，并提供测试情况概览以了解测试计划的进度和通过率；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。这样通过率、失败数与阻塞数的口径落在同一份执行记录上，报表中的分母和排除项有据可查。具体报表字段和状态分类粒度以团队实际配置为准。
