测试通过率是某一统计范围内通过状态的测试用例（或测试执行记录）占已执行用例的比例，核心公式为：通过率＝通过用例数÷已执行用例数×100%。这个比例要能被人复算，前提是先固定统计对象、状态判定规则、时间窗和版本范围，并单独说明阻塞、未执行与重测用例的处理方式。本文围绕当前测试轮次或版本结论展开，组织级趋势与发布门禁不在讨论范围；ONES在测试执行记录与口径文档的承载上可作为落地参考。
要点总览（TL;DR）
- 测试通过率＝通过用例数÷已执行用例数×100%，统计前先固定统计对象、状态判定规则、时间窗和版本范围，结果才能被他人复算。
- 阻塞、未执行、跳过与重测用例要单独归类：阻塞是否计入分母由团队约定并在报表注明，未执行与跳过不计入分母但单列数量，重测取最新一次或按轮次统计，全表统一。
- 按模块、优先级、轮次分组计算，能定位失败集中区域；与上一轮次或上一版本对比时使用相同口径，并同时列出两期分母。
- 通过率只说明执行面上的即时状态，需结合缺陷严重程度与用例覆盖度解读，不能替代缺陷密度、逃逸缺陷，也不能单独作为发布放行依据。
- 口径文档写明公式、分子分母、纳入排除清单与状态规则，由测试负责人编写、相关方评审并做版本管理，执行记录与异常处理一并留痕，保证多轮次可比。
评估目标：通过率要回答哪个问题
通过率本身只是一个比例，它回答什么问题，取决于统计前写下的目标。同一批执行记录，用来判断“本轮测试能不能收尾”和用来判断“这个版本质量是否稳定”，需要的分母、分组和对比基准并不相同。目标不写清，报表就容易把不同用途的数据混在一起，出现同一版本两个通过率、谁也说不清差异来源的情况。
常见用途可以分成三类。第一类是当前测试轮次结论，关注本轮计划内的用例执行到什么程度、失败集中在哪些模块，服务于测试收尾判断。第二类是版本质量结论，关注跨轮次、跨模块的整体表现，服务于版本评审时的质量说明。第三类是组织级趋势，关注多个版本、多个团队随时间的变化。本文只覆盖前两类，组织级趋势的度量体系与发布门禁规则属于其他主题。
评估前建议写一句目标陈述，把对象、时间窗和用途固定下来。可用的模板是：“本次统计对象为〔版本号〕在〔起止时间〕内〔测试轮次〕的〔用例/执行记录〕，用于判断〔本轮测试是否具备收尾条件/该版本质量是否达到评审要求〕。”这句话写进统计说明，后续取数、分组和汇报都围绕它展开，口径争议会明显减少。
指标与范围：分子、分母和统计边界
通过率的计算结构可以拆成一张定义卡，把公式、分子、分母和纳入排除清单一次写清。分子是通过状态的用例数或执行记录数，分母是已执行数，两者单位必须一致：按用例统计就以用例条数为单位，按执行记录统计就以执行记录条数为单位，结果统一用百分比表达，并保留一位小数或按团队约定取整。
| 定义项 | 内容 | 需要写清的细节 |
|---|---|---|
| 公式 | 通过率＝通过数÷已执行数×100% | 分子分母同单位，结果保留位数 |
| 分子 | 状态为“通过”的用例或执行记录 | “通过”的判定标准由谁确认 |
| 分母 | 已执行数，即实际产生执行结果的数量 | 是否含重测、是否含阻塞 |
| 纳入范围 | 指定版本、轮次、模块、优先级、时间窗 | 范围条件逐项列出 |
| 排除清单 | 未执行、跳过、范围外用例 | 排除原因与数量单独记录 |
统计对象有三种常见选择：测试用例、测试执行记录、需求覆盖的用例。按用例统计适合看覆盖面上的通过情况，同一用例多轮执行只算一次；按执行记录统计适合看执行工作量与稳定性，重测会产生多条记录；按需求覆盖统计适合向版本结论汇报，但需要先建立需求与用例的关联。三种口径的结果通常不同，选哪一种要在定义卡里写明，不能在同一张报表里混用。
范围边界要落到可筛选的条件上：版本号、测试轮次、模块、优先级、时间窗。阻塞、未执行、跳过和重测这四类需要单独归类。阻塞表示因环境或依赖问题无法执行，通常不计入分母，但要在报表中单列数量；未执行和跳过不计入分母，同样单列；重测按口径二选一，要么取该用例最新一次执行结果，要么按轮次分别统计，选定后整份报表保持一致。把这些规则写进定义卡，是让不同人算出相同结果的最直接办法。
数据口径与证据：状态怎么判、数据从哪来
状态判定标准决定分子，取数来源决定分母，两者都要有明确依据。用例状态通常包括未执行、通过、失败、阻塞、跳过几类，判定人一般是用例执行人，复核人可以是测试负责人。判定标准要写到可操作的程度，例如“实际结果与预期结果一致记为通过；出现与预期不符的现象记为失败并关联缺陷单；因环境或前置依赖缺失无法执行记为阻塞”。标准写在口径文档里，执行人按同一套规则标记，结果才可比。
取数来源建议固定为测试管理工具中的执行记录，辅以缺陷单和构建版本号。执行记录提供用例状态与执行时间，缺陷单提供失败原因的严重程度，构建版本号把执行结果绑定到具体产物上。三者对不上时，以执行记录为准，并在异常记录中说明差异。数据缺失、状态未更新、跨版本复用用例是三类高频问题：缺失的记录标记为待补，不默认计入通过；状态未更新的记录在统计前统一回访执行人；跨版本复用的用例按当前版本重新执行后再纳入，不能直接沿用上一版本结果。
同一用例多次执行时，取值规则要提前定。取最新一次执行结果，适合判断当前状态；按轮次分别统计，适合观察修复效果和回归稳定性。两种做法都合理，关键是全表统一，并在报表脚注中注明。异常处理要留痕，包括缺失记录清单、状态修正记录和跨版本复用说明，这些留痕在下一轮次对比时就是口径一致性的证据。
计算与评估步骤：从取数到结论
计算过程按固定步骤执行，结果才能被他人复算。建议的顺序是：锁定范围、导出执行记录、清洗状态、计算分子分母、分组汇总。每一步都产出可检查的中间结果，复核人按同样步骤走一遍，应当得到相同数字。
- 锁定范围：写下版本号、轮次、模块、优先级和时间窗，形成筛选条件清单。
- 导出执行记录：从测试管理工具导出用例编号、状态、执行人、执行时间、关联缺陷和构建版本号。
- 清洗状态：按判定标准核对状态，处理缺失与未更新记录，把阻塞、未执行、跳过单独标记。
- 计算分子分母：统计通过数与已执行数，按公式计算总体通过率，同时记录排除数量。
- 分组汇总：按模块、优先级、轮次分别计算，形成分组表。
分组计算的用途各不相同。按模块分组能定位失败集中的区域，指导修复资源投放；按优先级分组能看出高优先级用例的通过情况，判断核心功能是否稳定；按轮次分组能观察修复后的回归效果。分组表建议包含分组名、已执行数、通过数、失败数、阻塞数、通过率和排除数，便于横向比较。
分母为零或样本过小时，不直接给出百分比。分母为零的分组标注“无执行”，样本量低于约定阈值（例如少于十条执行记录）的分组标注样本量并谨慎解读，避免用一两条记录的比例下结论。与上一轮次或上一版本对比时，必须使用相同口径：相同的统计对象、相同的状态规则、相同的范围条件，对比表同时列出两期的分母，防止分母变化被误读为质量变化。
例子：一个版本轮次的通过率计算
以下为演示情景，数据为示例，用于说明计算过程与口径差异。某版本第一轮测试共规划用例200条，实际执行160条，其中通过120条、失败28条、阻塞12条，另有未执行40条。
按“已执行数”作分母：通过率＝120÷160×100%＝75.0%。阻塞的12条已产生执行结果但未通过，计入分母；未执行的40条不计入分母，单独记录。若团队约定阻塞不计入分母，则分母为148，通过率＝120÷148×100%≈81.1%。两种口径都成立，差异来自阻塞归类规则，报表中必须注明采用哪一种。
| 模块 | 已执行 | 通过 | 失败 | 阻塞 | 通过率 |
|---|---|---|---|---|---|
| 订单 | 60 | 52 | 6 | 2 | 86.7% |
| 支付 | 50 | 30 | 14 | 6 | 60.0% |
| 账户 | 50 | 38 | 8 | 4 | 76.0% |
| 合计 | 160 | 120 | 28 | 12 | 75.0% |
分组后可以看到，总体75.0%掩盖了支付模块60.0%的明显偏低，失败与阻塞都集中在支付。若只看总体数字，容易得出“本轮基本稳定”的判断；结合分组，结论应改为“支付模块需优先修复并安排重测”。同一批数据在两种口径下的差异（75.0%与81.1%）也说明，汇报时只给一个百分比而不说明分母构成，读者无法判断结果含义。
解读与限制：通过率能说明什么、不能说明什么
通过率反映的是已执行用例中通过的比例，它说明执行面上的即时状态，不能单独说明质量水平。通过率高，可能因为用例设计偏浅、覆盖的场景有限；通过率低，也可能因为本轮集中执行了高风险用例。解读时要同时看缺陷严重程度和用例覆盖度：失败用例关联的缺陷中是否有阻断级问题，规划用例是否覆盖了核心业务流程，这两点决定了通过率的实际含义。
用例设计质量和执行深度直接影响结果。用例粒度粗、预期结果写得模糊，执行人容易判为通过；执行只走主流程、不做边界和异常验证，通过率会偏高。反过来，用例设计严格、执行包含探索性验证，通过率可能偏低但更接近真实风险。因此通过率不能替代缺陷密度、逃逸缺陷等指标，也不能作为个人绩效的唯一依据。发布放行需要结合缺陷收敛情况、回归结果和风险评审，单一比例不足以支撑放行决定。
汇报时的表述建议固定包含三部分：范围、分母构成、异常说明。例如“本版本第一轮测试，已执行160条，通过120条，通过率75.0%，其中阻塞12条计入分母，未执行40条未纳入；支付模块通过率60.0%，失败集中在退款流程”。这样的表述让读者能自行判断结果的可信度，也便于下一轮次同口径对比。
把口径落到协作流程里：记录、复核与留痕
口径写在文档里只是第一步，执行记录、状态和版本信息要在同一处关联，统计才有稳定来源。测试用例与需求、任务关联，测试计划与迭代关联，执行记录带上构建版本号，失败用例能快速转为缺陷任务并在测试与研发之间流转，这些动作把通过率的分子分母固定在可追溯的记录上。ONES测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，支持为用例分配执行人，未通过的用例可快速创建缺陷任务；测试情况概览可查看测试计划的进度和通过率，测试报告支持自动生成与自定义模板组装。通过率的具体计算口径仍需团队在口径文档中自行约定，并在实际配置中确认状态字段与分组维度。
口径文档本身也需要版本管理。文档中写明公式、分子分母、纳入排除清单、状态判定标准和取值规则，由测试负责人编写、研发与产品负责人评审，口径调整时更新版本号并记录变更原因。测试结论在版本评审中交接时，附上口径文档版本和统计范围，评审人据此确认结论是否成立。执行记录、异常处理记录和口径文档版本一并留痕，下一轮次对比时直接引用同一版本的口径，避免因规则漂移导致数字不可比。
常见问题
同一用例在多轮测试中反复执行，通过率应该怎么算？
先确定统计对象。按用例统计时，同一用例多轮执行只算一次，适合看覆盖面上的通过情况；按执行记录统计时，每次重测产生一条记录，适合看执行工作量与回归稳定性。选定后整份报表保持一致，并在脚注注明。若关注修复效果，可以按轮次分别统计，把每轮的通过率并列展示，避免把不同轮次的数据混在一个比例里。
阻塞用例到底算不算进分母？
两种做法都成立，取决于团队约定。把阻塞计入分母，通过率反映“已产生执行结果的全部用例”中通过的比例；把阻塞排除在分母外，通过率更接近“可正常执行的用例”的通过情况。关键是口径文档写明采用哪一种，报表中单列阻塞数量，并在与上一轮次对比时沿用同一规则。规则中途变更会让两期数字不可比，变更时需记录原因。
分母很小或某个模块本轮没有执行，报表怎么呈现？
分母为零的分组标注“无执行”，不给出百分比；样本量低于团队约定阈值（例如少于十条执行记录）的分组，标注样本量并谨慎解读，避免用一两条记录的比例下结论。这类分组可以保留在分组表中作为执行覆盖情况的说明，但不参与总体结论的推导。
通过率数据从测试管理工具导出后，发现状态与实际不符怎么办？
以执行记录为准，统计前统一回访执行人核对状态，修正过程留痕，包括修正清单、修正人和修正时间。数据缺失的记录标记为待补，不默认计入通过；跨版本复用的用例按当前版本重新执行后再纳入。这些异常记录在下一轮次对比时就是口径一致性的证据，也能帮助发现执行流程中的薄弱环节。
ONES 测试管理里的通过率能直接用于版本评审汇报吗？
ONES 测试管理提供测试情况概览，可查看测试计划的进度和通过率，测试报告支持自动生成与自定义模板组装。具体通过率按什么分子分母与状态规则计算，官网资料未说明，需要在选型核验或实际配置中确认。用于版本评审时，建议在报告中同时写明统计范围、分母构成和异常说明，使读者能判断结果含义。
