缺陷关联用例后，复测结果容易停在“链接已建、状态没动”的阶段。要让复测可跟踪，需要把缺陷、验证用例和复测结论串成一条状态链：修复提交时明确验证用例和复测责任人，复测执行后回写用例结果与缺陷状态，未通过则带证据退回。本文按现状基线、瓶颈归因、改进动作、前提代价和效果验证展开，并在状态链与待复测清单环节说明ONES可承载的管理动作。
要点总览（TL;DR）
- 复测跟踪的核心是把缺陷、验证用例和复测结论串成状态链：修复提交时确定验证用例与复测责任人，复测后回写用例结果和缺陷状态。
- 关联了用例仍跟不住复测，常见原因是链接不参与状态流转、结果散落在聊天邮件、把“已修复”当成“已验证”、缺少超期与退回机制。
- 优先改进动作包括：修复提交时强制关联用例并指定责任人、统一缺陷状态与用例结果的口径映射、未通过带证据退回、设置超期提醒与待复测清单。
- 落地需要缺陷与用例在同一或可互通系统中管理，并接受状态口径与必填约束；初期有录入、培训与操作负担。
- 用复测通过率、退回次数、平均复测周期、待复测积压量与超期占比做同口径前后对比，结合关联必填率等执行情况判断改进是否生效。
当前复测跟踪的常见做法与目标
多数团队已经建立了缺陷与用例的关联，但关联发生的时点和复测记录的位置差异很大。先描述一条可对照的现状基线，才能判断后续改进改变了什么。
关联方式：修复提交时关联与事后补关联
修复提交时关联，指开发在提交修复、流转缺陷状态时，同时选定用于验证的用例，复测对象在修复动作发生时即确定。事后补关联，指缺陷先流转，测试人员准备复测时再回头找用例挂接。前者把验证范围前置到修复环节，后者依赖测试人员的记忆和检索，容易出现缺陷已关闭、用例却未执行的情况。
复测由谁触发、谁执行、结果记在哪里
常见分工是：开发提交修复并触发复测，测试人员执行关联用例并给出结论，缺陷状态由测试人员或缺陷负责人更新。结果记录位置则分三类：记录在缺陷的评论或描述里；记录在用例执行结果里；只留在聊天、邮件或口头确认中。前两种可回溯，第三种在人员轮换或版本回溯时基本失效。
跟踪目标：状态可见、责任明确、结果可回溯
复测跟踪要达成的目标可以归纳为三条。状态可见，指任意时刻能查到某缺陷处于待复测、复测中、复测通过还是复测退回。责任明确，指每个待复测缺陷都有确定的复测人，而不是停留在“测试组”这一层。结果可回溯，指复测结论、执行用例、失败证据与缺陷记录保存在同一处，能按缺陷或按版本回查。
| 基线维度 | 较弱做法 | 较好做法 |
|---|---|---|
| 关联时点 | 复测前事后补关联 | 修复提交时关联验证用例 |
| 复测触发 | 口头通知或群里喊人 | 缺陷流转到待复测并指派责任人 |
| 结果记录 | 聊天记录、邮件、口头确认 | 用例执行结果与缺陷记录同处保存 |
| 状态口径 | 已修复即视为完成 | 已修复与已验证分开表达 |
复测跟踪中的瓶颈与误区
关联了用例仍跟不住复测，通常不是关联动作本身有问题，而是关联之后缺少推动状态变化的机制。下面四类瓶颈分别对应流程断点或认知误区。
关联停留在链接层面，复测状态不随缺陷流转
缺陷与用例之间只有一条链接，缺陷状态从“已修复”走到“已关闭”时，用例的执行结果并不参与判断。机制原因在于状态机只覆盖缺陷自身，复测被当作缺陷之外的动作。结果是链接存在、复测是否发生无人核对，缺陷可能在没有执行验证用例的情况下被关闭。
复测结果散落在聊天、邮件或口头确认
复测结论写在即时消息里，短期看沟通很快，长期看无法按缺陷聚合。机制原因是结果没有落在与缺陷同一可检索的载体上，统计复测通过率、退回次数时只能人工翻记录，成本高且口径不一。人员变动后，历史复测结论往往直接丢失。
把“已修复”当成“已验证”，状态口径混淆
这是最常见的认知误区。开发提交修复后把缺陷置为已修复，团队在报表里把它计入完成，但验证用例尚未执行。已修复表达的是修复动作完成，已验证表达的是复测结论通过，两者混用会让缺陷完成率虚高，也会让待复测工作量从视野中消失。
缺少超期与退回机制导致复测积压
待复测缺陷没有时限，也没有退回路径时，复测队列只进不出。机制原因有两层：一是没有超期提醒，复测人不知道哪些缺陷已等待过久；二是复测未通过时缺少规范的退回动作，缺陷在“已修复”和“待复测”之间反复横跳，或者被直接重新打开而丢失上一轮复测证据。积压由此形成，且难以判断积压是修复质量问题还是复测排期问题。
优先改进动作：把复测结果纳入状态链
改进的重点是让复测结果成为缺陷状态流转的必要输入，而不仅是附加信息。以下动作按优先级排列，每项都说明它改变了什么机制。
修复提交时强制关联验证用例并指定复测责任人
把关联动作从复测前移到修复提交时，并将验证用例与复测责任人设为提交修复的必填项。机制变化在于：复测对象和责任人在缺陷进入待复测之前就已确定，复测不再依赖事后检索和口头分派。责任人应落到具体个人，便于后续超期提醒和待复测清单按人聚合。
统一缺陷状态与用例执行结果的口径映射
为缺陷状态和用例执行结果建立固定映射，避免同一事实出现两种表达。映射关系应写成团队可见的规则，并在缺陷流转时按规则校验。
| 缺陷状态 | 对应用例执行结果 | 含义 |
|---|---|---|
| 待复测 | 未执行 | 修复已提交，验证用例等待执行 |
| 复测中 | 执行中 | 复测人已开始执行验证用例 |
| 复测通过 | 通过 | 验证用例执行通过，可进入关闭 |
| 复测退回 | 失败 | 验证未通过，缺陷退回修复 |
映射确定后，“已修复”不再等同于完成，缺陷只有在关联用例执行通过后才能进入关闭。这样报表中的完成口径与复测结论保持一致。
复测未通过时带证据退回并重新排期
复测失败时，退回动作应附带失败证据，包括失败的验证用例、实际结果与预期结果的差异、必要的日志或截图，并同时给出重新修复的排期。机制变化在于：退回不是简单地把状态改回打开，而是形成一轮可追溯的复测记录，下一轮修复能直接看到上一轮失败原因，减少来回确认。
设置复测超期提醒与待复测清单
为待复测状态设置时限，超期后提醒复测责任人及其负责人；同时维护一份按责任人、按版本或按模块聚合的待复测清单，作为每日或每轮迭代的检查入口。机制变化在于：复测工作量从隐性变为显性，积压可以被看见并按优先级处理，而不是等到发布前集中暴露。
在工具承载上，ONES 测试管理支持一键创建并关联缺陷，让团队成员围绕缺陷协作；ONES Project 与 TestCase 数据互通，可一键提 Bug，并支持一键提交 Bug 至对应项目或迭代、记录和跟踪缺陷修复情况。团队可以把上述关联、责任人和状态流转放在同一工作项体系中管理，并用缺陷状态分布统计观察待复测与退回的分布。复测超期提醒与待复测清单的具体配置方式，需结合团队实际使用的版本和流程设置确认。
适用前提与代价
这套改进把复测从个人习惯变成流程约束，落地前需要确认前提，并对代价有预期。
前提条件
- 缺陷与用例在同一工具或可互通的系统中管理，关联关系、执行结果和缺陷状态能够相互引用；若分属两套系统，需要先确认字段同步或接口能力。
- 团队接受统一的状态口径与必填字段约束，包括待复测、复测通过、复测退回等状态的定义，以及修复提交时关联用例和指定责任人的要求。
- 有明确的复测时限标准，例如按缺陷严重程度设定不同的等待时长，否则超期提醒缺少判断依据。
- 缺陷负责人和复测责任人的角色划分清晰，避免同一人既提交修复又给出复测结论而无第二人复核。
需要付出的代价
初期需要投入时间做三件事：梳理并固化状态口径映射，把历史缺陷的关联关系补齐到可统计的程度，对开发和测试进行流程培训。流程加严后，修复提交环节的必填项会增加操作步骤，开发可能感到提交变慢；复测退回要求附带证据，也会增加测试人员的记录工作量。这些负担在流程稳定后会下降，但在推行初期需要预留适应期，并允许团队对必填范围和时限标准做一次校准。
效果验证：用哪些指标判断改进生效
判断改进是否生效，要选能反映状态链运转情况的指标，并用同口径做改进前后对比。指标本身不证明因果，需要结合流程执行情况一起解读。
指标定义与取数口径
| 指标 | 定义 | 取数口径 |
|---|---|---|
| 复测通过率 | 复测结论为通过的缺陷占已复测缺陷的比例 | 按固定统计周期，只计入已完成复测的缺陷，排除待复测 |
| 退回次数 | 同一缺陷经历复测退回的次数 | 按缺陷累计，区分首次退回与多次退回 |
| 平均复测周期 | 从修复完成到给出复测结论的平均时长 | 以缺陷状态变更时间为准，排除等待排期的时间需单独说明 |
| 待复测积压量 | 统计时点处于待复测状态的缺陷数量 | 按责任人或模块分组统计 |
| 超期占比 | 待复测缺陷中超过时限的比例 | 时限标准需在对比前后保持一致 |
改进前后的同口径对比方法
选取改进上线前后各一个完整迭代或相同长度的统计周期，使用同一套指标定义和取数口径对比。对比时注意三点：一是确认统计范围一致，例如是否包含低优先级缺陷；二是排除发布节奏、需求规模等外部变化对复测周期的影响，必要时按缺陷严重程度分层比较；三是把指标变化与流程执行情况对照，例如关联必填率、超期提醒响应情况，避免把复测通过率上升简单归因于流程改进。若指标改善同时伴随关联覆盖率提升和超期占比下降，改进生效的判断更有依据。
ONES 测试管理可为测试活动自动生成多维度测试报告并提供报告模板，缺陷状态分布也可在 ONES Project 中统计，团队可据此建立上述指标的定期回顾。报告是否直接包含复测通过率、退回次数等具体指标，需以实际配置和报告模板为准。
常见问题
缺陷与用例分属两套系统时，复测结果还能串进缺陷状态链吗？
可以，但需要先确认两套系统之间的字段同步或接口能力。至少要让缺陷能引用验证用例编号、复测结论和失败证据，并让缺陷状态变更能读取复测结果。若暂时无法自动同步，可先用固定字段加人工回写的方式过渡，同时在待复测清单中标注数据来源，避免统计时口径混乱。
复测责任人应该指定给个人还是测试组？
建议落到具体个人。指定到测试组时，超期提醒和待复测清单只能聚合到组一级，容易出现“组里都以为别人在看”的情况。若团队采用轮值复测，可以把责任人设为当轮值班人，并在交接时同步待复测清单，保证任一时刻每个待复测缺陷都有明确的人负责。
复测退回时要求附带证据，会不会让测试人员负担过重？
退回证据的范围可以按缺陷严重程度分级：严重缺陷要求附失败用例、实际与预期差异及必要日志；一般缺陷至少记录失败用例和简要说明。这样既保留可追溯性，也避免所有退回都按同一标准记录。推行初期可先统一最低要求，再根据实际退回情况调整。
复测通过率上升，就能说明流程改进生效了吗？
不能单独下结论。复测通过率受缺陷质量、修复水平和复测范围共同影响。判断改进是否生效，应同时看关联必填率、超期占比和待复测积压量的变化，并用改进前后相同长度的统计周期、同一套指标定义做对比。若通过率上升的同时超期占比下降、关联覆盖率提升，改进生效的判断更有依据。
ONES 能否直接支撑复测结果回写和待复测清单？
ONES 测试管理支持一键创建并关联缺陷，ONES Project 与 TestCase 数据互通、可一键提 Bug 并记录和跟踪缺陷修复情况，缺陷状态分布也可在 ONES Project 中统计。复测结果回写驱动状态流转、超期提醒与待复测清单的具体配置方式，需结合团队实际使用的版本和流程设置确认。
