测试进度跟踪的依据可以归为三层：执行事实层记录用例执行、环境和版本；计划基准层固定测试范围、轮次和里程碑；判断口径层规定进度算法、异常状态和更新频率。三层对齐后，进度数字才有可解释的比较基准。本文只讨论测试运行过程中的跟踪依据，缺陷修复闭环与测试报告另作专题。
要点总览（TL;DR）
- 测试进度跟踪的依据分三层：执行事实层记录用例状态、环境与版本；计划基准层固定范围、轮次与里程碑；判断口径层规定算法、异常状态与更新频率。
- 执行记录至少包含状态、执行时间、优先级、所属模块或需求、环境、被测版本与构建号、执行人、轮次标识，缺一项都会让进度出现可解释的偏差。
- 进度计算按用例数、按优先级加权、按需求覆盖三种口径各有适用条件，同一周期内应固定一种或明确双口径，并在结论中注明。
- 阻塞、挂起、跳过要与未执行区分，判定规则、记录人和解除条件事先写清，避免进度被高估或低估。
- 跟踪启动前和每个里程碑用检查清单核对执行记录完整性、基准与变更留痕、口径一致性，缺失严重时先补齐再发布进度结论。
跟踪测试进度前先确定哪几类依据
进度跟踪常见的失效方式，是每天收集一堆执行数据，却说不清“完成 60%”到底相对什么而言。要避免这种情况，跟踪开始前就应把依据分成三层分别准备，再建立层与层之间的对应关系。
第一层是执行事实，回答“实际发生了什么”：哪些用例执行了、结果如何、在什么环境和版本上执行、由谁在哪个轮次执行。第二层是计划基准，回答“原本打算做什么”：测试范围与用例基线、轮次划分、里程碑时点、准入准出条件。第三层是判断口径，回答“这些数据怎么换算成结论”：进度按什么单位计算、阻塞和挂起如何认定、数据多久更新一次、口径调整如何留痕。
三层之间需要建立明确的对应关系，进度才可比：执行记录中的每条用例应能追溯到计划基线中的范围；每轮执行应挂在计划定义的轮次上；统计时点应与里程碑或固定汇报节奏对齐。缺少任何一层，进度都会失真——只有执行数据没有基准，无法判断快慢；只有基准没有口径，不同人算出的进度不一致。
| 层级 | 核心问题 | 主要依据项 | 缺失后的典型表现 |
|---|---|---|---|
| 执行事实层 | 实际执行了什么 | 用例执行状态与时间、优先级与所属模块/需求、环境与版本、执行人与轮次 | 进度无法复核，数据对不上 |
| 计划基准层 | 原本计划做什么 | 测试范围与用例基线、轮次目标、里程碑、准入准出条件、变更记录 | 进度没有对照物，快慢无从判断 |
| 判断口径层 | 数据如何变成结论 | 进度计算方式、阻塞/挂起/跳过规则、更新频率与统计时点、口径变更留痕 | 同一数据得出不同结论，争议不断 |
执行事实依据：用例、环境与版本记录怎么留
执行记录是进度跟踪的原始输入，字段设计的目标是让每条记录都能被独立复核，并能按不同维度汇总。字段不必多，但下面几类缺一不可。
| 字段 | 取值示例 | 对进度判断的用途 |
|---|---|---|
| 用例执行状态 | 未执行 / 通过 / 失败 / 阻塞 / 挂起 / 跳过 | 区分真实完成量与异常量，避免把阻塞算作未开始或已完成 |
| 执行时间 | 具体日期时间 | 支撑按日/按轮次的趋势统计，识别执行停滞 |
| 用例优先级 | 高 / 中 / 低（或 P0–P3） | 支撑加权进度计算，反映核心用例的真实覆盖 |
| 所属模块或需求 | 模块名、需求编号 | 支撑按需求覆盖度统计，定位进度薄弱的范围 |
| 测试环境 | 环境名称或编号 | 区分不同环境下的执行结果，避免环境差异混入同一进度 |
| 被测版本与构建号 | 版本号 + 构建号 | 确保进度对应到具体构建，防止跨版本数据混算 |
| 执行人 | 姓名或账号 | 明确记录责任，便于核对与补录 |
| 轮次标识 | 第几轮测试 | 区分回归与首轮执行，支撑分轮次进度对比 |
字段缺失带来的偏差是具体的：没有轮次标识，首轮未执行和回归未执行会被混在一起，进度被低估；没有版本与构建号，旧构建的通过记录会被计入新构建的进度，进度被高估；没有优先级，按用例数计算的进度可能被大量低优先级用例“填满”，核心功能覆盖不足却显示接近完成；没有执行时间，就无法判断进度是持续推进还是临近节点集中补录。
记录方式上，执行状态应在执行当下填写，避免事后凭记忆批量补录。若使用测试管理工具承载执行记录，用例与需求、任务的关联能让执行数据直接落到具体需求上，减少手工汇总的误差。例如 ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，用例可分配执行人，执行记录因此能按计划和轮次归集，而不是散落在个人表格中。
计划基准依据：范围、轮次与里程碑如何设定
计划基准的作用是给执行数据提供对照物。基准应在测试开始前固定下来，之后的变化以变更记录的方式追加，而不是直接覆盖原计划，否则历史进度将无法解释。
| 基准项 | 设定内容 | 作为对照物的用法 |
|---|---|---|
| 测试范围与用例基线 | 本轮纳入的用例清单或模块范围，明确基线版本 | 进度分母的来源；范围外用例的执行不计入本轮进度 |
| 轮次划分与每轮目标 | 如首轮全量、第二轮回归、第三轮验收，各轮目标与时间窗 | 按轮次对比执行量，判断是否按节奏推进 |
| 里程碑 | 提测、测试完成、上线等关键时点 | 进度统计时点与里程碑对齐，形成阶段性判断 |
| 准入准出条件 | 如冒烟通过方可进入正式测试；高优先级用例全部通过方可退出 | 判断当前进度是否具备进入下一阶段的条件 |
| 变更记录 | 范围增减、轮次调整、里程碑顺延的原因、时间与批准人 | 解释进度基准变化，避免“计划悄悄改了”引发的争议 |
范围基线要写清“哪些用例算数”。如果只写“测试登录模块”，执行时有人测了接口、有人只测了页面，进度分母就不一致。轮次目标要可判断，例如“第二轮完成全部高优先级用例回归”，而不是“第二轮做回归”。准入准出条件与进度判断直接相关：当高优先级用例仍有失败时，即使总进度显示 90%，也不应判定为接近完成。
计划变更本身是正常管理动作，关键是留痕。每次变更记录调整前后的内容、原因和影响，进度汇报时引用当前有效版本，并说明与初始基准的差异。这样里程碑时点的进度判断既能反映最新计划，也能追溯偏差来源。
判断口径依据：进度怎么算、阻塞怎么记
同一批执行数据，按不同口径可以算出差别很大的进度。口径必须在跟踪开始前书面固定，并在同一周期内保持一致。
常见计算方式及适用条件如下：
- 按用例数计算：已执行用例数 ÷ 基线用例总数。计算简单、易核对，适合用例粒度相近、优先级分布均匀的项目。缺点是大量低优先级用例会稀释核心功能的进度信号。
- 按优先级加权：为不同优先级赋权（如高 3、中 2、低 1），以加权执行量 ÷ 加权总量计算。适合核心功能风险高、需要优先反映关键用例进展的项目。权重规则需事先公布，避免临时调整。
- 按需求覆盖计算：已完成测试的需求数 ÷ 本轮需求总数，或按需求下用例通过比例折算。适合以需求交付为管理单元的项目，能直接回答“哪些需求已验证”。前提是需求与用例的关联关系完整。
三种口径可以并存用于不同汇报场景，但同一份进度结论应注明所用口径，不能在同一张趋势图里混用。若项目同时关注总量与风险，可约定“总量按用例数、风险按优先级加权”的双口径，并分别设定判断阈值。
异常状态的判定规则同样需要统一。阻塞指因环境、依赖或数据问题导致用例无法执行，责任通常在测试之外；挂起指用例暂时停止执行、等待条件恢复；跳过指本轮明确不执行的用例，应有原因记录。三者与“未执行”必须区分：把阻塞计入未执行会低估已投入的工作，把阻塞计入已执行会高估完成度。建议在口径说明中写明每种状态的认定条件、记录人和解除条件。
数据更新频率与统计时点应固定，例如执行人每日下班前更新状态，负责人次日上午按固定时点取数。统计时点之后补录的数据计入下一周期，避免同一份日报反复变动。口径发生调整时，记录调整内容、生效时间和影响范围，历史数据按原口径保留或标注换算方式。
角色分工与交付物：谁提供依据、谁做判断
依据体系能否运转，取决于每个角色是否清楚自己交什么、什么时候交、交给谁。下表给出一种常见分工，团队可按规模调整，但“提供依据”和“做判断”两类职责应分开。
| 角色 | 提交的依据 | 时间点 | 交付物 |
|---|---|---|---|
| 测试执行人 | 用例执行状态、执行时间、环境与版本、阻塞原因 | 执行当下或每日固定时点前 | 执行记录、异常说明 |
| 测试负责人 | 计划基准、口径说明、进度判断与偏差分析 | 测试开始前设定基准与口径；按里程碑和固定节奏输出判断 | 测试计划基准表、口径说明、进度判断结论 |
| 开发方 | 被测版本与构建号、缺陷修复后的可测版本说明 | 每次提测时 | 提测说明、版本记录 |
| 环境管理方 | 环境可用状态、环境变更与故障记录 | 环境变更时及故障发生时 | 环境状态记录 |
进度判断与异常上报由测试负责人承担：负责人依据执行记录和基准做判断，对超出阈值的偏差（如高优先级用例连续两日无进展、阻塞用例超过约定时长）发起上报，并说明影响与建议。交接与评审节点建议设在每轮测试结束和里程碑时点：执行人核对记录完整性，负责人核对基准与口径，双方确认后形成该节点的进度结论。评审记录本身也是后续解释进度变化的依据。
在工具层面，角色分工可以通过权限和计划归属落地。ONES 测试管理支持为不同用户组配置不同权限，并可为用例库、测试计划单独配置权限，测试计划的规划和执行可在同一处进行，用例分配执行人后，执行记录按计划归集，负责人查看计划进度时不必再向各执行人逐个收集表格。
示例：一个迭代内的测试进度跟踪依据流转
以下为一个两周迭代的演示情景，用于说明依据从产生到形成判断的完整流转，具体数值仅作示意。
迭代开始时（第 1 天）。测试负责人确定本轮范围：三个需求模块共 240 条用例作为基线，划分两轮——首轮全量执行，第二轮回归高优先级用例；里程碑设为第 8 天完成首轮、第 12 天完成回归；准出条件为高优先级用例全部通过。同时发布口径说明：总量按用例数计算，风险按优先级加权，阻塞与挂起分别记录，执行人每日 18:00 前更新状态。产出为计划基准表和口径说明。
每日执行与汇总（第 2–7 天）。执行人按分配用例执行，逐条填写状态、时间、环境与构建号。第 3 天开发方提测新构建，执行记录切换到新构建号，旧构建数据保留但不再计入当前进度。负责人每日上午按固定时点取数，汇总执行量、失败数和阻塞数，与首轮目标对比。
中途阻塞（第 5 天）。测试环境数据库故障，涉及支付模块的 30 条用例无法执行。执行人将状态标记为阻塞并注明原因，环境管理方记录故障与恢复时间。负责人判断：这 30 条不计入已执行，也不计入未执行，单独列示；同时评估对第 8 天里程碑的影响，向项目负责人上报并给出顺延或调整范围的建议。故障恢复后，阻塞状态解除，用例重新执行。
里程碑判断（第 8 天）。负责人核对三项依据：执行记录是否完整（有无缺执行人或缺时间的记录）、基准是否有变更（范围未变，里程碑未调整）、口径是否一致（总量与加权两个口径分别计算）。核对后形成首轮进度结论：按用例数完成 92%，按优先级加权完成 88%，剩余未执行集中在低优先级用例，高优先级用例全部执行且通过，满足进入回归轮的条件。结论连同依据清单一并归档，作为第二轮跟踪的起点。
这个示例的关键在于：每个节点的进度结论都能回溯到具体记录、具体基准和具体口径，出现争议时可以逐项核对，而不是重新争论“到底完成了多少”。
完成检查：依据是否齐备、口径是否一致
跟踪启动前和每个里程碑时点，可用下面的清单逐项核对。全部通过，依据才算达到可用状态。
执行记录完整性
- 每条已执行用例都有状态、执行时间和执行人
- 每条记录都关联到具体环境、被测版本与构建号
- 记录带有轮次标识，首轮与回归可区分
- 阻塞、挂起、跳过的用例均有原因说明和记录人
- 用例与需求或模块的关联关系完整，可按范围汇总
计划基准与变更记录
- 测试范围与用例基线已固定，并注明基线版本
- 轮次划分、每轮目标和里程碑时点已明确
- 准入准出条件可判断，不依赖主观解释
- 所有计划变更均有原因、时间、批准人和影响说明
- 当前进度汇报引用的是最新有效基准，并说明与初始基准的差异
口径一致性
- 进度计算方式已书面固定，同一周期内未混用
- 阻塞、挂起、跳过的判定规则已公布，各执行人理解一致
- 数据更新频率与统计时点已约定，补录数据有归属规则
- 口径调整有留痕，历史数据按原口径保留或标注换算方式
- 同一份进度结论中，分子分母来自同一基准和同一统计时点
核对中发现缺失时，处理方式应与影响程度匹配：字段个别缺失可限期补录并标注；基准缺失或口径未定，应暂停发布进度结论，先补齐再跟踪，否则后续所有判断都建立在不可比的数据上。检查结果建议随进度结论一并归档，作为下一轮跟踪的改进输入。
常见问题
测试进度跟踪的进度百分比，按用例数算还是按优先级加权算更合适？
两种口径回答的问题不同。按用例数计算适合用例粒度相近、优先级分布均匀的项目，计算简单、便于逐条核对；按优先级加权适合核心功能风险高、需要优先反映关键用例进展的项目，但权重规则要事先公布并保持稳定。
如果团队同时关注总量和风险，可以约定双口径：总量按用例数、风险按优先级加权，分别设定判断阈值。无论选哪种，同一份进度结论都要注明所用口径，趋势图里不要混用两种算法。
阻塞用例在进度统计里应该算已执行还是未执行？
都不算。阻塞指因环境、依赖或数据问题导致用例无法执行，把它计入未执行会低估已经投入的工作，计入已执行会高估完成度。建议在口径说明中把阻塞、挂起、跳过单独列示，并写明认定条件、记录人和解除条件。
阻塞数量较多时，除了更新进度，还应评估对里程碑的影响，由测试负责人判断是否需要上报并给出顺延或调整范围的建议。
测试中途需求范围变了，进度基准要不要跟着改？
可以改，但要以变更记录的方式追加，不要直接覆盖原计划。每次变更记录调整前后的内容、原因、时间和批准人，进度汇报时引用当前有效版本，并说明与初始基准的差异。
这样里程碑时点的判断既能反映最新计划，也能追溯偏差来源。如果直接改掉原基准，后续就无法解释进度为什么突然变化，历史数据也失去比较意义。
执行记录由执行人自己填，负责人怎么保证数据可用？
靠约定和核对，而不是靠事后补录。执行状态应在执行当下填写，团队约定每日固定时点前更新完毕；负责人按固定统计时点取数，时点之后补录的数据计入下一周期。
核对时重点看几项：已执行用例是否都有状态、时间和执行人；记录是否关联到具体环境与构建号；阻塞、挂起、跳过是否都有原因说明。个别字段缺失可限期补录并标注，基准或口径缺失则应先补齐再发布结论。
用测试管理工具承载执行记录，能减少哪些手工汇总工作？
主要减少三类手工工作：一是执行记录按测试计划和轮次自动归集，不必向各执行人逐个收表格；二是用例与需求、任务关联后，执行数据可以直接落到具体需求上，按范围汇总时不用再手工匹配；三是计划进度和通过率可以在计划层面查看，负责人取数时点更稳定。
以 ONES 测试管理为例，测试用例可与需求、任务关联，测试计划与迭代关联，用例可分配执行人，并支持为用例库、测试计划单独配置权限。工具承载的是记录与归集，进度口径和异常状态规则仍需团队事先书面约定。
