缺陷修复与验证跟踪的目标，是让每个缺陷从提交到关闭都有可核对的记录：缺陷单写清复现条件、影响范围和验收口径，修复人提交修复说明与影响面，验证人按原步骤独立验证并补查受影响范围，状态流转时留下版本、环境和证据。本文只覆盖单缺陷从修复到验证这一段，变更后的整体回归属于回归测试管理。在协作工具中，这类闭环通常由缺陷工作项承载，ONES 的缺陷管理能力可作为落地载体之一。
要点总览（TL;DR）
- 缺陷闭环由信息完备、修复、验证、状态流转、重新打开五个动作组成，每一步都以缺陷单上可核对的版本、环境和证据作为完成依据。
- 报告人、修复人、验证人、缺陷管理负责人各自交付固定字段与记录；修复与验证分离是默认原则，例外需在缺陷单上注明代验人和原因。
- 验证人按原复现步骤和验收口径验证，再对修复人给出的影响面清单做针对性检查；验证不通过时回填失败证据并重新打开。
- 把缺陷作为工作项管理，将必填字段、状态机、证据附件和交接通知配置在同一条记录上，便于查询与复盘。
- 完成检查以定期抽样为主，核对信息完备率、流转留痕、重新打开情况和整改闭环，抽查结果作为流程改进输入。
缺陷修复到验证的闭环包含哪些关键动作
一轮完整的缺陷闭环由五个动作组成：信息完备、修复、验证、状态流转、重新打开。每个动作都以缺陷单上可核对的记录作为完成依据，只写“已修复”而没有版本、环境和证据，不能算完成。
缺陷单进入修复前，先确认信息是否足够让修复人独立复现。复现步骤要写到具体操作顺序和输入数据；环境与版本要写明操作系统、浏览器或设备、构建号；影响范围说明受影响的模块、用户角色和关联功能；严重程度按业务影响和出现频率判定；验收口径写清“什么样算修好”，例如某接口在指定条件下返回正确结果且不再报错。信息缺失的缺陷单退回报告人补充，避免修复人反复追问。
修复阶段的动作包括定位说明、修复方案、影响面评估、提交修复版本与自测记录。定位说明写清根因所在模块或逻辑；修复方案说明改了什么、为什么这样改；影响面评估列出本次改动可能波及的功能，供验证人做针对性检查；自测记录附上修复人本地或开发环境验证的结果。
验证阶段由验证人按原复现步骤重走一遍，确认问题不再出现，再对影响面评估中列出的范围做针对性检查，防止修复引入新问题。验证记录要写明验证环境、版本号、执行结果和证据位置。
状态按“待修复—修复中—待验证—已验证/重新打开”流转。验证不通过时，验证人回填失败现象、环境、版本和日志或截图，缺陷重新打开并回到待修复，进入下一轮修复与验证。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 信息完备 | 报告人提交的缺陷描述 | 补齐复现步骤、环境版本、影响范围、严重程度、验收口径 | 可独立复现的缺陷单 | 修复人无需追问即可复现 |
| 修复 | 信息完备的缺陷单 | 定位根因、确定方案、评估影响面、提交修复版本并自测 | 修复说明、影响面清单、修复版本号、自测记录 | 修复说明与自测记录齐全，版本可查 |
| 验证 | 修复版本、原复现步骤、验收口径、影响面清单 | 按原步骤验证，补做受影响范围检查 | 验证记录、证据（截图、日志、版本号） | 原问题不再出现，针对性检查通过 |
| 状态流转 | 验证结果 | 通过则置为已验证，不通过则回填证据并重新打开 | 状态变更记录与责任人 | 每次流转都有版本、环境、证据和操作人 |
| 重新打开 | 验证失败证据 | 回到待修复，进入下一轮 | 带失败证据的缺陷单 | 失败现象可复现，责任人和下一轮计划明确 |
谁负责哪一步：角色分工与交付物
缺陷闭环涉及四类角色：报告人、修复人、验证人、缺陷管理或测试负责人。职责边界清晰，缺陷单上的字段和证据才不会悬空。
报告人负责把问题描述到可复现，交付复现步骤、环境版本、影响范围、严重程度和期望结果。修复人负责定位与修复，交付根因说明、修复方案、影响面评估、修复版本号和自测记录。验证人负责独立验证，交付验证环境与版本、执行结果、证据和结论。缺陷管理或测试负责人负责流程运行，包括缺陷单质量抽查、状态停留时长观察、重新打开情况统计和升级协调。
修复人与验证人分离是默认原则：修复人自测通过后交给验证人，验证人按原复现步骤和验收口径独立判断，避免“自己改自己验”导致漏检。人员紧张或缺陷影响极低时可有例外，但需在缺陷单上注明代验人和原因，便于后续追溯。
跨团队缺陷由报告人提交到承接团队的项目或迭代中，并在缺陷单上写明对接人。承接团队确认接收后更新责任人和计划修复版本；超过约定时限未响应或影响面扩大时，由缺陷管理负责人按升级路径通知双方团队负责人，升级记录同样留在缺陷单上。
| 角色 | 主要动作 | 必须填写的字段与证据 |
|---|---|---|
| 报告人 | 提交并补充缺陷信息 | 复现步骤、环境与版本、影响范围、严重程度、期望结果 |
| 修复人 | 定位、修复、自测、提交验证 | 根因说明、修复方案、影响面评估、修复版本号、自测记录 |
| 验证人 | 按原步骤验证并做针对性检查 | 验证环境与版本、执行结果、截图或日志、验证结论 |
| 缺陷管理/测试负责人 | 抽查质量、跟踪流转、协调升级 | 抽查记录、停留时长与重新打开统计、升级记录 |
一个缺陷从提交到关闭的完整示例
以下为演示情景，用于说明字段填写和流转方式，不代表真实项目数据。
报告人提交缺陷单：标题为“订单列表按金额排序后分页结果重复”。复现步骤写明登录测试账号、进入订单列表、选择按金额降序、翻到第 2 页，观察第 2 页出现第 1 页已展示的订单。环境与版本记录为测试环境、构建号 2024.06.18-03、Chrome 浏览器。影响范围为订单列表分页与排序组合场景，涉及运营和客服查看订单。严重程度定为高，因为影响日常查单。验收口径写明：按金额排序后连续翻页，订单不重复、不遗漏，排序顺序正确。
修复人定位到分页参数与排序字段组合时的查询逻辑问题，修复说明写清改动位置和原因，影响面评估列出订单列表的筛选、排序、分页组合以及导出功能。提交修复版本 2024.06.19-01，并附自测记录：本地按原步骤验证通过，另检查了筛选加分页组合。
验证人在测试环境、构建号 2024.06.19-01 下按原复现步骤验证，确认重复问题消失，再对影响面清单中的筛选、排序、分页组合和导出逐项检查。验证记录附上第 1 至第 3 页的截图和查询日志，状态置为已验证。
若验证时发现导出功能在排序条件下仍出现重复，验证人回填失败现象、环境、版本和日志截图，将缺陷重新打开并回到待修复。修复人基于新证据继续定位，下一轮修复完成后再次提交验证，直到原问题和受影响范围都通过。
用工作项承载缺陷闭环：状态、字段与交接
把缺陷作为工作项管理，可以让状态、字段、证据和交接集中在同一条记录上，查询和复盘时不必跨多个地方找信息。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提 Bug，并统计缺陷状态分布；也支持一键提交 Bug 至对应项目或迭代，记录和跟踪修复情况。ONES 测试管理方案覆盖缺陷管理，缺陷可关联至迭代。具体字段类型、状态机配置和附件形式以实际产品界面为准。
字段设计上，建议把复现步骤、环境与版本、影响范围、严重程度、验收口径设为缺陷工作项的固定字段，信息不全时限制进入修复状态。状态机按“待修复—修复中—待验证—已验证/重新打开”设置，并为每次流转记录操作人和时间。
证据挂接上，修复说明、影响面评估、自测记录、验证记录和截图日志都附在同一条缺陷工作项下，验证结论与修复说明相邻，便于交接时快速判断。验证人完成验证后通过工作项通知修复人或报告人，重新打开时同样触发通知，减少线下追问。
缺陷数据沉淀后，可按模块、严重程度、状态和重新打开情况查询，作为迭代复盘和质量改进的输入。需要沉淀分析结论时，可用 ONES Wiki 编写复盘文档并关联相关工作项，把文档与缺陷记录放在一起。
- 必填字段：复现步骤、环境与版本、影响范围、严重程度、验收口径
- 状态流转：待修复→修复中→待验证→已验证；验证失败→重新打开→待修复
- 证据附件：修复说明、影响面评估、自测记录、验证记录、截图或日志
- 交接通知：提交验证、验证通过、重新打开三个节点通知相关责任人
- 查询维度：模块、严重程度、状态、责任人、重新打开次数
完成检查：这套跟踪机制是否真的跑通
判断机制是否落地，看缺陷单能否支撑独立复现和独立验证，看状态流转是否留下可核对的信息，看重新打开是否被记录和分析。检查以定期抽样为主，抽查结果作为流程改进输入。
缺陷单信息完备率按抽样核对：随机抽取一定数量的缺陷单，检查复现步骤、环境版本、影响范围、严重程度、验收口径五项是否齐全，计算齐全比例。比例偏低说明提交环节的必填约束或填写指引需要调整。
状态流转检查看每次流转是否带版本、环境和证据：进入待验证时是否有修复版本号和自测记录，置为已验证时是否有验证环境和证据。缺少任一项即记为不合格流转。
重新打开率和验证返工情况按周期观察：统计重新打开的缺陷占已验证缺陷的比例，以及同一缺陷经历多轮验证的分布。比例持续偏高时，回看修复阶段的影响面评估是否充分、自测是否覆盖原复现步骤。
定期抽查建议按迭代或固定周期执行，由缺陷管理或测试负责人组织，开发与测试代表参与。抽查中发现的信息缺失、流转缺证据、超时未响应作为阻断项，要求在下个周期前整改并复查。
| 检查项 | 通过标准 | 抽查方式 |
|---|---|---|
| 缺陷单信息完备率 | 抽样缺陷单五项关键信息齐全 | 按周期随机抽样核对 |
| 状态流转留痕 | 每次流转带版本、环境、证据和操作人 | 逐条检查流转记录 |
| 重新打开情况 | 重新打开有失败证据和下一轮计划 | 统计比例并抽查原因 |
| 交接与升级 | 跨团队缺陷有对接人和升级记录 | 检查超时未响应缺陷 |
| 整改闭环 | 阻断项在下个周期前整改并复查 | 对照上期抽查结果复核 |
常见问题
缺陷单信息不全，修复人可以直接开始修吗？
不建议直接进入修复。信息不全时，修复人往往需要反复追问复现步骤、环境版本或验收口径，修复结果也难以被独立验证。更稳妥的做法是把缺陷单退回报告人补充，或在缺陷单上标注缺失项并约定补齐时间。若问题紧急，可先由修复人协助复现并补全关键信息，但补齐前不进入正式修复状态，避免后续验证缺少判断依据。
修复人和验证人由同一人担任，什么情况下可以接受？
修复与验证分离是默认原则，目的是让验证人按原复现步骤和验收口径独立判断。人员紧张或缺陷影响极低时可以有例外，但需要在缺陷单上注明代验人和原因，并保留验证环境、版本和证据记录。涉及核心功能、高严重程度或跨团队交付的缺陷，建议保持分离；例外情况可在定期抽查时重点复核，观察是否出现漏检或反复重新打开。
验证时发现修复引入了新问题，应该重新打开原缺陷还是新建一条？
按判断依据区分：如果新问题与原缺陷同源，属于修复不完整或修复方式带来的直接后果，回填失败现象、环境、版本和证据后重新打开原缺陷，进入下一轮修复与验证；如果新问题是修复影响面之外、可独立复现的另一处缺陷，建议新建缺陷单并关联原缺陷，便于分别跟踪责任人和修复计划。两种方式都要在记录中写清关联关系，避免复盘时信息割裂。
缺陷修复后，变更涉及的整体回归应该放在哪里跟踪？
本文覆盖的是单缺陷从修复到验证这一段。修复提交后如果变更影响到多个模块或版本，需要做整体回归，这部分归回归测试管理，通常按测试计划和用例执行，与单缺陷的验证记录分开管理。实际操作中，可以在缺陷验证通过后，把影响面清单作为回归范围的输入，交给回归测试环节统一安排，缺陷单上保留验证结论即可。
用工作项承载缺陷闭环时，哪些配置最影响执行效果？
影响最大的是三处：一是必填字段，把复现步骤、环境与版本、影响范围、严重程度、验收口径设为固定字段，信息不全时限制进入修复状态；二是状态机，按待修复、修复中、待验证、已验证和重新打开设置，并记录每次流转的操作人和时间；三是证据挂接，把修复说明、影响面评估、自测记录和验证记录附在同一条工作项下。ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提 Bug 并统计缺陷状态分布，具体字段类型和状态机配置以实际产品界面为准。
