评估测试执行进度，单看“已执行多少”容易高估进展：大量失败或阻塞的执行也会被算作已完成。更稳妥的做法是在同一时间窗内，用执行完成率、通过率、阻塞率和剩余工作量四项指标交叉判断，并事先固定分母（计划用例数或计划执行记录数）、统计口径和数据来源。本文给出可直接复算的指标定义、取数规则、计算步骤与示例，帮助测试负责人、项目经理在站会、阶段评审和发布判断中使用同一套口径。
要点总览（TL;DR）
- 评估测试执行进度需要四项指标交叉判断：执行完成率看做了多少，通过率看做得怎么样，阻塞率看为什么停，剩余工作量看还要多久。
- 每项指标都要固定分子、分母、单位和统计时间窗；分母通常取同一用例集、同一轮次内的计划用例数，范围不同结果不可比。
- 口径分歧集中在按用例计还是按执行记录计、重跑是否重复计数、中途增删用例是否调整分母，评估前应书面固定规则。
- 计算按五步走：锁定范围与时间窗、清洗执行记录并归类状态、代入公式、用近期日均执行量估算完成时间、交叉解读形成结论。
- 执行完成率高不代表质量达标，不同用例集与轮次之间不宜直接比较，数据滞后会直接影响判断。
评估测试执行进度要回答什么问题
测试执行进度评估要回答两个问题：测试是否按计划在推进，以及按当前节奏剩余工作能否按期完成。第一个问题看已经做了多少、做得怎么样，第二个问题看还剩多少、需要多久。评估对象是测试用例的执行过程与运行状态，包括用例是否已执行、执行结果如何、哪些被阻塞、还有多少未执行。
这个边界需要说清楚：缺陷修复闭环、缺陷验证跟踪、测试报告的最终质量结论，属于相邻环节，本篇不展开。执行进度回答的是“测试跑到哪一步了”，不回答“版本能不能发”这类综合质量判断。两者数据相关，但结论不能互相替代。
评估结果的使用者通常有三类。测试负责人和项目经理在每日站会上用它发现阻塞、调整当天分工；在阶段评审中用它判断测试阶段是否可进入下一环节；在发布前判断中，它作为输入之一，与缺陷状态、风险评估一起使用。明确使用场景，才能决定统计时间窗取当天、本周还是整个测试轮次。
用哪些指标和范围衡量执行进度
建议固定使用四项指标，每项都明确分子、分母、单位和统计时间窗。四项指标回答不同问题：执行完成率回答“做了多少”，通过率回答“做得怎么样”，阻塞率回答“为什么停”，剩余工作量回答“还要多久”。
| 指标 | 计算公式 | 分母 | 单位 | 统计时间窗 |
|---|---|---|---|---|
| 执行完成率 | 已执行用例数 ÷ 计划用例数 × 100% | 同一用例集、同一轮次内的计划用例数 | 百分比 | 截至统计时点，覆盖本轮次全部计划用例 |
| 通过率 | 通过用例数 ÷ 已执行用例数 × 100% | 已执行用例数（不含未执行、跳过） | 百分比 | 与执行完成率同一时点 |
| 阻塞率 | 阻塞用例数 ÷ 计划用例数 × 100% | 计划用例数 | 百分比 | 与执行完成率同一时点 |
| 剩余工作量 | 计划用例数 − 已执行用例数（或剩余未执行用例的预估工时） | 不适用，为绝对量 | 条或人时 | 统计时点至本轮次计划结束 |
统计范围要在计算前锁定三件事：用例集范围（本轮次纳入哪些用例库或测试计划）、执行轮次范围（首轮、回归轮还是全部轮次合并）、环境范围（哪个测试环境下的执行记录）。范围不同，结果不可比。例如首轮执行完成率与回归轮执行完成率放在一起看，会掩盖回归轮的实际压力。
四项指标需要组合阅读。执行完成率高但通过率低，说明执行动作在推进，但大量用例未通过，实际可交付的验证覆盖有限；执行完成率高但阻塞率也高，说明不少用例被环境或前置依赖卡住，进度数字含有水分。剩余工作量则把百分比还原成具体条数或工时，用于估算完成时间。任何单项指标都不足以单独支撑进度结论。
数据口径与证据从哪里来
取数来源主要有三处：测试用例库提供计划用例清单与用例状态；执行记录提供每次执行的执行时间、执行人、所属轮次和结果；缺陷关联记录提供未通过用例对应的缺陷编号，用于区分“失败待修”和“失败已修待验证”。三处数据按用例编号关联，才能保证同一口径下可复算。
关键字段至少包括：用例编号、用例状态（未执行、通过、失败、阻塞、跳过）、执行时间、执行人、所属轮次、阻塞原因。缺少执行时间就无法按时间窗截取，缺少轮次字段就无法区分首轮与回归，缺少阻塞原因则阻塞率只能给出数字、无法指导处理。
口径分歧最常见的有三类，需要在评估前书面固定规则：
- 按用例计还是按执行记录计。按用例计，一条用例无论执行几次只算一次，适合看覆盖进度；按执行记录计，每次执行都计入，适合看执行投入量。进度评估通常按用例计，执行量分析可按记录计，两者不要混用。
- 重跑是否重复计数。失败后修复重跑并通过的用例，最终状态记为通过，但执行记录有两条。按用例计时只取最终状态；若统计“执行次数”则两条都计。规则要写清楚，否则同一批数据会算出两个完成率。
- 中途新增或删除用例是否调整分母。测试过程中补充用例是常态。建议分母取统计时点的计划用例数，并在报告中注明期间新增、删除的条数，便于对比前后两天的数字变化来源。
缺失值与特殊状态的归类也要统一：未执行单独统计，不计入已执行；跳过需注明原因（如功能裁剪、环境不支持），不计入通过率分母，但计入计划用例数；阻塞计入已执行还是单列，取决于团队定义，建议单列并同时给出阻塞率，避免把阻塞混入“已完成”抬高完成率。
计算与评估步骤
按以下五步执行，每一步都有明确产物，便于他人复核。
步骤一：锁定统计范围与时间窗。确定用例集、执行轮次、测试环境和统计截止时点，写成一句话记录，例如“截至3月12日18:00，订单模块回归轮，测试环境A”。产物是范围声明，后续所有数字都基于它。
步骤二：清洗执行记录，去重并归类状态。按用例编号取每条用例在统计时点的最终状态；同一用例多次执行时，以最后一次有效执行结果为准；把状态归入通过、失败、阻塞、跳过、未执行五类。产物是一张用例级状态清单。
步骤三：按公式计算四项指标。从状态清单中分别统计各状态条数，代入上一节的公式。计算时保留原始条数，百分比保留一位小数即可，便于核对。产物是指标计算表。
步骤四：结合剩余工作量估算完成时间。用剩余未执行用例数除以近几个统计周期的日均有效执行量，得到预计所需天数。日均有效执行量取近三天或近一周的实际执行条数，剔除阻塞导致的停滞日。估算结果要标注前提，例如“按近三日日均执行40条估算”。
步骤五：交叉解读并形成结论。把四项指标放在一起看：完成率与剩余工作量判断进度位置，通过率与阻塞率判断进度质量，再结合估算完成时间与计划结束时间比较，得出“可按期完成”“存在风险”“需要调整资源”等结论，并写明主要风险来源。
一个可复算的例子
以下为演示情景，数字为假设。某轮次计划用例数200条，截至统计时点：已执行150条，其中通过120条、失败20条、阻塞10条；未执行50条；跳过0条。近三日日均有效执行量为30条。
逐项代入公式：
- 执行完成率 = 150 ÷ 200 × 100% = 75.0%
- 通过率 = 120 ÷ 150 × 100% = 80.0%
- 阻塞率 = 10 ÷ 200 × 100% = 5.0%
- 剩余工作量 = 200 − 150 = 50条
- 预计完成时间 = 50 ÷ 30 ≈ 1.7天，即约两个工作日
解读这组数字：完成率75%看起来推进正常，但通过率80%意味着已执行的150条中有30条未通过（20条失败、10条阻塞），实际验证通过的用例只占计划的60%（120 ÷ 200）。如果计划结束时间只剩一天，按日均30条估算需要约1.7天，存在延期风险；同时10条阻塞用例需要先解决环境或前置依赖，否则剩余执行量还会被拉低。结论应写成“进度存在风险，主要来自阻塞用例与失败待修用例，建议优先处理阻塞原因并评估是否补充执行人力”。
边界情形要单独处理。分母为零时，例如计划用例尚未导入或轮次未启动，完成率与阻塞率没有意义，应输出“未开始”而不是0%或100%。全部用例阻塞时，完成率若把阻塞计入已执行会显示100%，此时必须同时看阻塞率100%和通过率0%，结论是“执行未实质推进”。跳过用例较多时，通过率分母缩小，百分比波动会被放大，报告中应同时给出绝对条数。
如何解读结果与避免误判
执行完成率高不等于质量达标。完成率只说明执行动作覆盖了多少计划用例，通过率和阻塞率才反映执行结果。发布前判断应把三项指标与缺陷状态一起看，任何单项指标都不构成对交付质量的保证。
不同用例集、不同轮次之间不宜直接比较。用例难度、环境稳定性、回归范围都会影响执行节奏，首轮完成率60%与回归轮完成率60%代表的压力完全不同。跨团队比较更需谨慎，除非用例设计粒度和统计口径一致。
数据滞后会直接影响判断。执行记录若每天只同步一次，站会上看到的数字可能落后半天；临近发布时建议提高更新频率，并在报告中注明数据截止时点。阻塞原因未及时登记时，阻塞率会偏低，剩余工作量估算也会偏乐观。
评估结果最终要落到行动：完成率落后且剩余量大，考虑调整排期或补充执行人力；阻塞率高，优先协调环境和前置依赖；通过率低且失败集中，回到开发修复与用例评审。把这些动作写进站会记录和阶段评审结论，下一轮统计时才能验证调整是否有效。
在测试执行记录与状态管理这一层，ONES 测试管理支持测试计划的规划和执行，提供测试情况概览以查看测试计划的进度和通过率，并支持将用例分配执行人、把用例与需求任务关联、将测试计划与迭代关联。对于需要按轮次跟踪执行状态、把执行结果与需求上下文对应的团队，这些能力可以作为上述口径的承载方式；具体指标字段与统计规则仍以团队事先约定的口径为准。
常见问题
计划用例数在测试过程中发生变化，分母应该怎么处理？
建议分母取统计时点的计划用例数，并在报告中注明统计期间新增和删除的条数。这样前后两天的完成率变化可以拆成两部分：一部分来自实际执行推进，另一部分来自用例范围调整。如果分母一直沿用轮次启动时的初始值，中途补充的用例会让完成率虚高；如果每次调整都重算历史数据，又会导致前后数字无法对比。固定“取统计时点值并披露变动”这一条规则，既能保持可复算，也能解释波动来源。
阻塞用例算不算已执行？会怎样影响完成率？
这取决于团队定义，但建议单列，不混入“已完成”。如果把阻塞计入已执行，完成率会偏高，而实际验证覆盖并没有增加；此时必须同时给出阻塞率，读者才能看出进度数字中的水分。若团队把阻塞视为已执行，应在报告中明确写出该口径，并保证跨周期一致。无论哪种处理，阻塞原因都要登记，否则阻塞率只能给出数字，无法指导环境协调和前置依赖处理。
用日均执行量估算完成时间，遇到执行停滞的日期怎么办？
估算时应剔除因环境故障、版本未提测等原因造成的停滞日，只取正常推进日期的执行条数，否则日均值会被拉低，完成时间被高估。同时要标注估算前提，例如“按近三日日均执行30条估算”，并说明数据截止时点。如果剩余用例中包含大量阻塞用例，先解决阻塞再估算更可靠；阻塞未解除时，按当前日均推算出的天数只能作为下限参考。
执行完成率和通过率都很高，是否可以直接判断测试阶段可以结束？
不能直接下结论。两项指标高说明执行覆盖和执行结果较好，但测试阶段能否结束还要看剩余未执行用例的性质、失败用例的修复与验证状态、以及缺陷的整体分布。执行进度指标反映的是测试运行过程，发布判断需要与缺陷状态、风险评估一起使用。此外，如果统计范围只覆盖了部分用例集或单一环境，指标再高也不代表全量验证完成，范围声明要和指标一起呈现。
团队刚开始做执行进度度量，指标和数据从哪里起步比较现实？
先从用例状态和执行记录两类数据起步：确保每条用例有明确状态（未执行、通过、失败、阻塞、跳过）、执行时间和所属轮次，这三项字段齐全就能算出四项指标。执行记录可以从测试用例管理工具中导出，ONES 测试管理支持测试计划的规划和执行，提供测试情况概览以查看测试计划的进度和通过率，并支持将用例分配执行人、把用例与需求任务关联、将测试计划与迭代关联，可作为执行状态与轮次的承载方式。指标字段与统计规则仍以团队事先约定的口径为准，起步阶段不必追求报表自动化，先保证口径一致、数据可复算。
