测试进度跟踪要回答的是：本轮测试执行到哪一步、剩余多少工作、哪些用例被阻塞、风险何时暴露。做法是先统一跟踪对象和状态口径，再确定更新节奏与责任人，用一张看板加一份跟踪记录承载数据，最后按完成标准判断能否进入下一阶段。本文只覆盖测试运行过程的跟踪，缺陷修复闭环和测试报告分别归其他主题处理。
要点总览（TL;DR）
- 先统一跟踪口径：明确跟踪测试用例、测试轮次、测试环境和阻塞项四类对象，状态互斥可判定，进度公式在跟踪开始前写进看板说明。
- 再定节奏与分工：执行人每日更新自己用例的状态，测试负责人主持站会并做周度汇总，开发接口人和环境管理人按阻塞路径当日响应。
- 用看板承载数据：用例级跟踪表加轮次汇总视图，字段服务于判断剩余工作量和风险暴露时点，每日更新、阶段结束冻结数据。
- 偏差要落到动作：对比计划基线，分析是用例耗时、阻塞积压还是投入不足，写明调整动作，避免只描述“进度偏慢”。
- 以五项检查收口：口径一致性、更新及时性、阻塞项闭环、结论有数据支撑、记录可追溯，全部满足才可判断能否进入下一阶段。
先定跟踪口径：跟踪哪些对象、状态怎么算
跟踪口径不统一，后面每天的更新就会变成各说各话：有人按用例条数报进度，有人按执行工时报进度；有人把“失败待复测”算作已执行，有人算作未完成。开始跟踪前，测试负责人应先和团队确认三件事：跟踪哪些对象、每个对象有哪些状态、进度用什么公式计算。
跟踪对象清单
测试运行过程需要跟踪的对象主要有四类，它们各自回答一个不同的问题：
- 测试用例：本轮计划执行哪些用例，每条用例当前处于什么状态。它回答“执行到哪一步”。
- 测试轮次：当前是第几轮测试、轮次范围是什么、计划起止时间。它回答“这一轮的整体位置”。
- 测试环境：本轮依赖的环境是否可用、版本是否与待测版本一致。它回答“能不能继续执行”。
- 阻塞项：哪些用例因环境、数据、依赖未就绪而无法执行，阻塞原因和责任人是谁。它回答“卡在哪里、谁来解”。
状态定义与判定规则
状态要互斥且可判定，避免同一条用例同时落入两个状态。建议采用下表的口径，并在跟踪开始前向所有执行人说明判定规则。
| 状态 | 判定规则 | 是否计入已执行 |
|---|---|---|
| 未开始 | 尚未领取或尚未开始执行 | 否 |
| 执行中 | 已开始执行，尚未得出结果 | 否 |
| 通过 | 执行完成，实际结果符合预期 | 是 |
| 失败 | 执行完成，实际结果与预期不符，已记录问题 | 是 |
| 阻塞 | 因环境、数据或前置依赖不具备而无法执行 | 否 |
| 跳过 | 经确认本轮不执行，需注明原因 | 否，且从分母中排除 |
“失败”计入已执行，是因为执行动作已经发生、结果已经产生；它是否转为通过，属于缺陷修复与验证环节，不在本文跟踪范围内。“阻塞”不计入已执行，但必须单独统计数量，否则进度看起来正常、实际风险被掩盖。
进度计算口径
进度公式必须在跟踪开始前写进看板说明，常见两种口径：
- 按用例数计算：执行进度 =（通过 + 失败）÷（本轮计划用例总数 − 跳过数）。分母是本轮计划范围内的用例，临时追加的用例需先纳入计划再计入分母。
- 按工作量计算：执行进度 = 已完成用例的估算工作量之和 ÷ 本轮计划用例的估算工作量之和。适合用例执行耗时差异大的场景，但要求每条用例在初始化时就有估算值，并由同一角色维护。
两种口径不要混用。团队规模小、用例粒度接近时，按用例数计算更简单；用例复杂度差异明显、需要向外部准确交代剩余工时时，再引入工作量口径。无论选哪种，通过率单独统计为“通过 ÷（通过 + 失败）”，与执行进度分开看，避免执行快但质量差被进度数字掩盖。
跟踪节奏与角色分工：谁在什么时点更新什么
口径确定后，跟踪能否持续取决于更新动作是否落到具体的人和时点。测试进度跟踪通常涉及四类角色，各自负责不同的数据入口。
| 角色 | 更新内容 | 时点 | 交接方式 |
|---|---|---|---|
| 测试执行人 | 自己领取用例的状态、实际结果、阻塞原因 | 每日执行结束后，或每日站会前 | 在看板或跟踪表中直接更新，阻塞项标注原因 |
| 测试负责人 | 轮次进度汇总、偏差判断、风险上报 | 每日站会主持；每周输出周度汇总 | 站会同步结论，周度汇总发给项目相关方 |
| 开发接口人 | 阻塞项中与代码、构建相关的原因确认与修复反馈 | 收到阻塞上报后当日响应 | 在阻塞项上回复处理进展，执行人复测后更新状态 |
| 环境管理人 | 环境可用状态、版本部署情况 | 环境变更时即时更新；每日确认一次 | 环境状态在看板单独一栏呈现，异常时通知测试负责人 |
每日更新的最小内容
每日站会不必逐条过用例，最小内容控制在四项：昨日完成的用例数与通过率、今日计划执行的用例范围、新增和仍未解除的阻塞项、需要其他角色当日响应的事项。执行人只报与自己相关的状态变化，测试负责人负责把变化汇总成轮次层面的判断。
周度汇总的输入与输出
周度汇总的输入是本周每日更新记录和阻塞项处理记录，输出是一页状态说明：本轮累计执行进度与通过率、剩余用例数与预计完成时间、未解除阻塞项清单及影响范围、下周执行重点。周度汇总的作用是让项目相关方在固定时点获得一致结论，避免临时口头询问造成信息不一致。
阻塞项的上报与解除路径
阻塞项应有明确的责任路径：执行人发现阻塞后当日标注原因和影响用例范围；测试负责人判断阻塞类型，分派给开发接口人或环境管理人；责任人在阻塞项上回复处理进展；执行人复测通过后将状态改为通过或失败，阻塞项关闭。超过约定时限未解除的阻塞项，由测试负责人升级到项目层面协调，并在周度汇总中列为风险。
执行步骤：从建看板到每日更新
下面按操作顺序给出五个步骤，每步说明输入、动作和输出，可直接照做。
第一步：建立测试进度看板或跟踪表
输入：已确认的跟踪对象、状态定义和进度公式。动作：建立一张用例级跟踪表，字段至少包括用例编号、用例名称、所属模块、关联需求或任务、执行人、状态、执行日期、阻塞原因、备注；另建一个轮次汇总视图，展示计划用例数、已执行数、通过数、失败数、阻塞数、跳过数、执行进度、通过率。输出：字段说明清晰的看板，团队可访问。完成标志：每位执行人都能看到自己名下的用例，测试负责人能看到轮次汇总数字。
第二步：首轮数据初始化
输入：本轮测试计划、用例清单、环境信息。动作：把本轮计划执行的用例全部导入或登记，状态统一置为未开始；确认分母（计划用例总数）并记录跳过项及原因；登记轮次名称、起止时间和依赖环境；为每条用例指定执行人。输出：一份可开始更新的初始跟踪表。完成标志：计划用例数、执行人分配、环境状态三项齐全，分母与计划一致。
第三步：每日更新动作
输入：当日执行结果。动作：执行人逐条更新自己用例的状态和执行日期，遇到阻塞时填写阻塞原因并通知测试负责人；测试负责人核对汇总数字，检查是否有状态长期停留在“执行中”的用例；环境管理人确认环境状态。输出：当日更新后的跟踪表和阻塞项清单。完成标志：当日有执行动作的用例状态均已更新，新增阻塞项均有原因和责任人。
第四步：识别并处理进度偏差
输入：每日汇总数据和计划基线。动作：对比实际执行进度与计划进度，偏差超过约定阈值时分析原因——是用例执行耗时超出预期、阻塞项积压，还是执行人投入不足；针对原因调整执行顺序、补充人手或推动阻塞解除，并在跟踪记录中写明调整动作。输出：偏差说明与调整记录。完成标志：每项明显偏差都有原因判断和对应动作，不停留在“进度偏慢”的描述上。
第五步：阶段结束收口
输入：本轮全部用例的最终状态。动作：确认无“执行中”遗留用例，跳过项均有原因记录，阻塞项均已关闭或明确转为风险；冻结本轮跟踪数据，形成轮次结论：执行进度、通过率、未关闭风险。输出：可追溯的轮次跟踪记录和结论。完成标志：数据不再变动，结论中的每个数字都能在跟踪表中找到对应记录。
当团队希望把用例、轮次和阻塞项放在同一处跟踪时，可以用 ONES 测试管理承载这套动作：测试计划支持规划和执行，并可多维度概览全部测试计划，便于查看进度；用例可分配执行人，合作测试时各人清楚自己名下的范围；测试情况概览可查看测试计划的进度和通过率。用例与需求、任务关联、测试计划与迭代关联，能让跟踪数据与研发过程对应起来。具体统计口径以团队在看板中约定的公式为准。
示例：一个测试轮次的进度跟踪记录
以下为演示情景，用于说明跟踪表如何填写和解读，数据为示例值。
示例背景与轮次范围
某功能模块进入第二轮回归测试，轮次计划执行用例 120 条，其中 6 条经确认本轮跳过，分母为 114 条。依赖一套测试环境，计划周期 5 个工作日。执行人 3 名，开发接口人 1 名，环境管理人 1 名。
跟踪表填写样例
| 日期 | 已执行 | 通过 | 失败 | 阻塞 | 执行进度 | 通过率 | 当日阻塞说明 |
|---|---|---|---|---|---|---|---|
| 第1天 | 28 | 24 | 4 | 3 | 24.6% | 85.7% | 环境数据未就绪，3 条用例无法执行 |
| 第2天 | 55 | 48 | 7 | 8 | 48.2% | 87.3% | 新增 5 条阻塞，集中在支付相关用例，等待构建修复 |
| 第3天 | 76 | 66 | 10 | 5 | 66.7% | 86.8% | 环境数据已就绪，构建修复待验证 |
| 第4天 | 98 | 86 | 12 | 2 | 86.0% | 87.8% | 剩余阻塞 2 条，等待第三方接口联调 |
| 第5天 | 112 | 99 | 13 | 0 | 98.2% | 88.4% | 阻塞全部解除，2 条用例未执行，转入下轮 |
从数据中读出阻塞与风险
第2天是这轮测试的关键节点：执行进度接近一半，但阻塞数从 3 条升到 8 条，且集中在支付相关用例。如果只看执行进度，会误判为进展正常；把阻塞数和阻塞原因放在一起看，才能发现风险集中在同一模块，且依赖构建修复。第3天环境问题解除后阻塞数下降，说明环境类阻塞处理路径有效；剩余阻塞转为第三方接口联调，属于外部依赖，需要提前升级协调。
根据数据做出的调整动作
- 第2天站会上将支付相关阻塞列为当日最高优先级，开发接口人当日给出修复构建，执行人优先复测。
- 第3天调整执行顺序，先执行不依赖第三方接口的用例，避免整体进度被单一依赖拖住。
- 第5天收口时确认 2 条未执行用例的原因和下轮安排，写入轮次结论，避免遗漏。
完成检查：判断跟踪是否做到位
阶段结束或跟踪机制运行一段时间后，可用下面五项逐条核对。每项都给出可观察的通过标准，避免停留在“感觉跟踪得还行”。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 口径一致性 | 进度公式、分母、状态判定是否全团队一致 | 任取 5 条用例，不同执行人对状态的判定一致；汇总数字可由明细复算得出 |
| 更新及时性 | 每日更新是否在约定时点前完成 | 连续 3 个工作日无逾期未更新用例；站会数据与看板一致 |
| 阻塞项闭环 | 每个阻塞项是否有原因、责任人和处理结果 | 无只有“阻塞”标记而无原因和责任的记录；已解除阻塞有复测结果 |
| 结论有数据支撑 | 进度结论是否能追溯到明细 | 周度汇总和轮次结论中的每个数字都能在跟踪表中找到对应记录 |
| 记录可追溯 | 历史状态和调整动作是否可查 | 能还原任一时点的执行进度；偏差调整有文字记录 |
五项全部满足，说明跟踪机制可以支撑“测试能否进入下一阶段”的判断；若更新及时性和阻塞项闭环两项不达标，优先修正这两项，因为它们直接决定风险能否被及时暴露。跟踪记录本身也是下一轮测试计划的数据来源，轮次结束后保留记录，便于对比不同轮次的执行效率和阻塞分布。
常见问题
测试进度按用例数算还是按工作量算，怎么选？
两种口径各有适用条件。用例粒度接近、团队规模较小时，按用例数计算更简单，公式为（通过 + 失败）÷（本轮计划用例总数 − 跳过数），分母需与计划一致，临时追加用例先纳入计划再计入。用例执行耗时差异明显、需要向外部准确交代剩余工时时，再引入工作量口径，前提是每条用例初始化时就有估算值并由同一角色维护。两种口径不要混用，通过率单独统计为“通过 ÷（通过 + 失败）”，与执行进度分开看。
阻塞项长期不解除，跟踪机制该怎么处理？
阻塞项应有明确的责任路径和时限。执行人发现阻塞后当日标注原因和影响用例范围，测试负责人判断类型并分派给开发接口人或环境管理人，责任人在阻塞项上回复进展，执行人复测后关闭。超过约定时限未解除的，由测试负责人升级到项目层面协调，并在周度汇总中列为风险。若阻塞集中在同一模块或同一外部依赖，可调整执行顺序，先执行不依赖该部分的用例，避免整体进度被单一依赖拖住。
每日站会要不要逐条过用例？
不必逐条过。站会最小内容控制在四项：昨日完成的用例数与通过率、今日计划执行的用例范围、新增和仍未解除的阻塞项、需要其他角色当日响应的事项。执行人只报与自己相关的状态变化，测试负责人负责把变化汇总成轮次层面的判断。逐条过用例会拉长会议时间，状态更新本身已在看板完成，站会的作用是同步结论和推动阻塞。
跟踪表里的“失败”用例算不算已执行？
算。失败表示执行动作已经发生、结果已经产生，因此计入已执行，也计入通过率的分母。它是否转为通过，属于缺陷修复与验证环节，不在测试进度跟踪的范围内。需要单独关注的是阻塞：阻塞不计入已执行，但必须单独统计数量并记录原因，否则进度数字看起来正常，实际风险被掩盖。
轮次结束后跟踪记录还要保留吗？
建议保留。轮次结束收口时冻结数据，形成执行进度、通过率、未关闭风险的结论，并确认无“执行中”遗留用例、跳过项均有原因、阻塞项均已关闭或转为风险。保留的记录是下一轮测试计划的数据来源，可用于对比不同轮次的执行效率和阻塞分布，也便于在需要时还原任一时点的执行进度。
