缺陷修复跟踪的依据，是一组能相互印证的过程记录：缺陷单里的复现步骤与期望结果、修复提交与变更说明、评审与合并记录、测试环境与构建版本、验证用例与执行结果、验证人确认与关闭理由。判断一个缺陷能否从“已修复”进入“已验证”，要看这些记录是否指向同一缺陷、同一版本、同一环境，并留下可追溯的关联关系。本文围绕修复到验证这一段，给出依据清单、操作步骤、角色分工、完整示例和关闭前的检查表。ONES 可作为承载缺陷单、修复关联与验证记录的工作项平台，下文在相应管理动作处自然衔接。
要点总览（TL;DR）
- 缺陷修复跟踪的依据分为四组：缺陷单基础信息、修复侧记录、验证侧记录和状态流转记录，四组指向同一缺陷、同一版本、同一环境才能支撑关闭结论。
- 操作上把依据嵌入状态流转：受理复现、修复提交与缺陷单关联、提交验证前检查构建与变更说明、验证执行记录结果、关闭时写明理由与遗留风险。
- 角色分工要落到交付物：报告人提供复现信息，开发提供修复提交与变更说明，评审人给出结论，验证人记录用例与结果，缺陷管理员维护状态与关闭记录。
- 关闭前按一致性、可复核性、完整性三个维度逐项核对，依据缺失时阻断关闭并补正，避免带着缺口关闭缺陷。
- ONES 工作项可承载缺陷单、修复关联、验证记录与状态流转留痕，具体字段配置按团队流程调整。
缺陷修复跟踪要留哪些依据：一张依据清单
缺陷修复跟踪的依据按产生阶段可以分为四组：缺陷单基础信息、修复侧记录、验证侧记录和状态流转记录。四组依据各自回答一个问题——缺陷是什么、改了什么、在什么条件下验证过、谁在什么时候做了判定。缺少任何一组，关闭结论都会失去支撑。
缺陷单基础字段决定后续所有记录能否对得上号。复现步骤要写到他人可照着操作的程度，期望结果与实际结果分列，严重程度和影响版本标明判断口径。这些字段在缺陷受理时填写，后续修复和验证都以此为基准，避免“修的不是报告的那个问题”。
修复侧依据说明改动内容和影响范围。修复提交需要与缺陷单建立关联，变更说明写清修改思路，影响范围说明列出可能受影响的模块或功能，代码评审记录保留评审人和评审结论。评审通过是提交验证的前置条件之一，评审意见中的遗留问题也应记录在案。
验证侧依据证明修复在受控条件下有效。测试环境、构建版本号必须明确，验证用例对应缺陷单中的复现步骤与相关场景，执行结果记录通过或失败，验证人留下确认。环境与版本信息尤其关键，同一缺陷在不同构建上的表现可能不同，缺少版本标识的验证结论无法复核。
状态流转依据记录判定过程。每次状态变更保留时间与变更人，关闭时写明关闭理由，对未完全消除的风险给出遗留风险说明。这些记录让后续复盘或审计能还原缺陷的处理路径。
| 阶段 | 依据项 | 作用 | 最低要求 |
|---|---|---|---|
| 缺陷受理 | 复现步骤、期望结果、实际结果、严重程度、影响版本 | 确立缺陷事实与处理优先级 | 他人可按步骤复现 |
| 修复 | 修复提交、变更说明、影响范围说明、代码评审记录 | 说明改了什么、影响哪里、是否经过评审 | 提交与缺陷单关联，评审有结论 |
| 验证 | 测试环境、构建版本号、验证用例、执行结果、验证人 | 证明修复在指定版本和环境有效 | 环境与版本可识别，结果可复核 |
| 状态流转 | 状态变更时间、变更人、关闭理由、遗留风险说明 | 还原判定过程，支撑关闭结论 | 每次变更可追溯到人 |
从修复到验证的操作步骤
把上述依据嵌入缺陷状态流转，跟踪才有可执行的动作。下面按缺陷从受理到关闭的顺序说明每一步的输入、动作、输出和完成标志。
第一步：受理与复现确认
输入是报告人提交的缺陷描述。缺陷管理员或测试人员按复现步骤操作，确认问题存在，补齐期望结果、实际结果、严重程度和影响版本。输出是一份信息完整、状态为“待修复”的缺陷单。完成标志是复现结论明确：能稳定复现、偶现或无法复现，无法复现的需注明已尝试的环境和步骤。
第二步：修复提交并与缺陷单关联
开发人员领取缺陷后，在修复提交中引用缺陷单编号，填写变更说明和影响范围。提交代码评审，评审人给出通过或修改意见。输出是关联了修复提交、带有评审结论的缺陷单。完成标志是评审通过且提交记录可在缺陷单中查到，影响范围说明覆盖被改动模块。
第三步：提交验证前的准入检查
开发将缺陷状态改为“待验证”前，需确认三项条件：修复提交已合并到目标分支、构建版本已生成并可识别、变更说明与影响范围已填写。输出是进入验证队列的缺陷单。完成标志是验证人能凭缺陷单上的版本号找到对应构建，无需再向开发口头询问。
第四步：验证执行与结果记录
验证人依据缺陷单中的复现步骤设计验证用例，在指定环境和构建版本上执行，记录执行结果。验证通过则填写验证人确认；验证不通过则写明失败现象，将缺陷退回并附上新的复现信息。输出是带验证记录和明确结论的缺陷单。完成标志是验证结论与执行记录一致，退回时开发能直接依据记录定位问题。
第五步：关闭缺陷
验证通过后，由验证人或缺陷管理员关闭缺陷，填写关闭理由，对未完全消除的风险给出遗留风险说明并注明后续处理方式。输出是状态为“已关闭”的缺陷单。完成标志是关闭理由、验证记录、修复提交三者能在同一缺陷单内相互跳转，形成完整链条。
角色分工与各环节交付物
依据缺失往往源于责任不清：有人以为开发会写变更说明，开发以为测试会补版本号。按角色明确输入与交付物，可以减少这类空档。下表列出修复到验证阶段各角色的职责。
| 角色 | 主要职责 | 输入 | 交付物 |
|---|---|---|---|
| 报告人 | 提交缺陷并配合澄清 | 使用中发现的问题 | 复现步骤、期望结果、实际结果、影响版本 |
| 开发人员 | 修复并说明改动 | 已确认的缺陷单 | 修复提交、变更说明、影响范围说明 |
| 评审人 | 审查修复质量 | 修复提交与变更说明 | 评审结论与修改意见 |
| 测试验证人 | 验证修复有效性 | 待验证缺陷单与目标构建 | 验证用例、执行结果、验证人确认 |
| 缺陷管理员 | 维护流程与状态 | 各环节记录 | 状态流转记录、关闭理由、遗留风险说明 |
跨角色交接时需要一次确认动作。开发提交验证前，与验证人确认目标构建版本；验证人退回缺陷时，在缺陷单中写明失败现象和复现环境，开发据此重新进入修复。退回意味着责任回到开发一侧，缺陷单状态和指派对象同步更新，避免缺陷停留在无人处理的状态。
在 ONES 中，缺陷、修复任务和验证记录可以放在同一工作项体系内管理：修复提交与缺陷单建立关联，验证记录作为缺陷工作项下的记录留存，状态流转自动保留变更人和时间。这样各角色的交付物落在同一处，交接时不必跨系统核对。
示例：一个缺陷从提交到关闭的依据链
以下为演示情景，用于说明依据如何串联，不代表真实项目数据。
某系统在订单导出功能中，用户选择超过一千条记录导出时页面无响应。报告人提交缺陷单，写明操作步骤、期望结果（导出文件生成并下载）、实际结果（页面卡住超过两分钟）、严重程度为高、影响版本为当前测试构建。测试人员按步骤复现，确认问题稳定出现，缺陷进入待修复。
开发人员定位到导出逻辑缺少分批处理，提交修复代码并在提交信息中引用缺陷单编号，变更说明写明改为分批查询、影响范围为订单导出模块，评审人审查后通过，评审意见中提示关注大数据量下的内存占用。修复合并后生成新的构建版本，开发将缺陷状态改为待验证，并在缺陷单中注明目标版本号。
验证人在测试环境使用新构建执行验证用例：分别以一千条、五千条记录导出，检查文件内容完整性和响应时间，执行结果均通过，记录环境、版本号和执行时间，填写验证人确认。缺陷管理员关闭缺陷，关闭理由写明修复已验证，遗留风险说明记录评审意见中提到的内存占用问题，约定在后续性能测试中观察。
这条依据链的关联方式是：缺陷单编号贯穿修复提交、评审记录、验证用例和关闭记录；版本号把修复与验证锁定在同一构建上；环境信息让验证结果可复核；状态流转记录保留每个环节的责任人和时间。任何一环缺失，关闭结论都会变得难以追溯。
完成检查：依据是否齐全可判定
关闭缺陷前，可用下面的检查表逐项核对。检查的目的是确认依据之间能相互印证，而不只是确认字段被填满。
| 检查维度 | 检查项 | 判定标准 |
|---|---|---|
| 一致性 | 缺陷单、修复提交、验证记录是否指向同一缺陷 | 修复提交引用缺陷单编号，验证用例对应缺陷复现步骤 |
| 一致性 | 验证所用版本是否为包含修复的构建 | 版本号可识别，且晚于修复合并时间 |
| 一致性 | 验证环境是否与缺陷影响场景匹配 | 环境信息明确，与缺陷单记录的影响环境一致或有说明 |
| 可复核性 | 验证用例与执行结果是否可被他人重跑 | 用例步骤完整，结果记录具体现象而非仅写“通过” |
| 可复核性 | 验证人确认是否明确 | 有验证人署名与验证时间 |
| 完整性 | 状态流转记录是否连续 | 每次状态变更均有变更人和时间，无跳步或缺失 |
| 完整性 | 关闭理由与遗留风险是否填写 | 关闭理由说明判定依据，遗留风险注明后续处理方式 |
检查中发现依据缺失时，应阻断关闭并补正。常见情形包括：验证记录缺少版本号，需回到对应构建重新确认；修复提交未关联缺陷单，需补充关联或在缺陷单中注明提交信息；验证结果只写结论没有执行细节，需补充可复核的记录。补正完成后再进入关闭判定，避免带着缺口关闭缺陷。
当团队把缺陷单、修复关联、验证记录和状态流转放在同一工作项平台中管理时，上述检查可以借助字段和关联关系直接核对。ONES 工作项支持缺陷与修复任务的关联、状态流转留痕和验证记录留存，适合承载这条从修复到验证的依据链；具体字段配置可按团队流程调整。
常见问题
缺陷偶现、无法稳定复现时，修复跟踪的依据怎么留？
偶现缺陷同样需要完整依据，只是复现结论要写得更具体。受理阶段记录已尝试的环境、操作步骤、出现频次和日志或截图，复现结论标注为“偶现”并说明触发条件。修复侧仍要求提交与缺陷单关联、变更说明写清推测原因和改动范围。验证阶段不能只跑一次通过就关闭，应在记录中写明验证轮次、每轮的环境与结果，必要时约定观察期，把观察结果作为关闭依据的一部分。
修复提交没有关联缺陷单，还能关闭缺陷吗？
建议先补正再关闭。可以在缺陷单中补充提交信息与变更说明，或回到代码平台补上关联，使修复记录能被追溯到具体缺陷。若确实无法补关联，至少在缺陷单中写明改动位置、修改思路和评审情况，并由评审人或开发确认。缺少这层关联，后续复盘时无法判断某次改动对应哪个问题，验证结论也失去对照对象。
验证通过后，评审意见里提到的遗留问题该怎么处理？
遗留问题不阻断本次缺陷关闭，但要在关闭记录中体现。做法是在遗留风险说明中写明问题内容、当前影响、暂不处理的原因和后续处理方式，例如约定在性能测试或下个迭代中观察。若遗留问题可能影响缺陷本身的修复效果，则应视为验证未完全通过，退回补充修复或扩大验证范围后再判定。
缺陷退回后，依据链如何保持连续？
退回时在缺陷单中写明失败现象、复现环境和所用构建版本，状态与指派对象同步回到开发一侧。开发重新修复后，新的提交继续关联同一缺陷单，验证记录按轮次追加，保留前一轮的失败记录。这样同一缺陷单内可以看到完整的修复—验证—退回—再修复路径，而不是覆盖旧记录，关闭时的判定依据才完整。
团队规模较小、角色由一人兼任时，依据清单可以简化吗？
可以合并角色，但依据项不宜删减。小团队中开发可能同时承担评审或验证，此时仍要分别留下评审结论和验证记录，并在记录中注明由谁执行，避免自审自验缺少可追溯性。简化的是流转环节和审批层级，保留的是缺陷事实、改动说明、验证条件和判定记录这条证据链。
