缺陷修复验证的依据，是一组能让他人独立复现问题、判断修复是否成立的记录。它通常包含四类：缺陷本身的复现信息、修复变更与根因说明、验证条件与执行结果、关闭或退回的评审结论。依据齐备的标准可以概括为一句话：换一个人拿到这些记录，能按原路径复现问题，确认修复已生效，并理解为什么关闭。
要点总览（TL;DR）
- 缺陷修复验证的依据由四类记录组成：缺陷复现信息、修复变更与根因说明、验证条件与执行结果、关闭或退回的评审结论。
- 依据齐备的判断标准是他人仅凭记录即可复现原问题、确认修复生效并理解关闭理由，需要当面询问才能判断则说明依据不足。
- 执行上分修复提交、验证执行、关闭评审三个阶段，每个阶段以明确的完成标志作为进入下一阶段的门槛，验证不通过时退回同样要留记录。
- 缺陷提交人、修复人、验证人和评审角色各自交付对应依据，修复人与验证人之间的交接决定验证范围是否覆盖影响面。
- 缺少复现路径、变更未关联缺陷、验证环境与缺陷环境不一致且未说明、结果无执行记录，属于关闭前必须消除的阻断项。
一条缺陷从修复到关闭要留下哪些依据
把依据按“缺陷记录—修复—验证—评审”四类分组，可以清楚看到每项材料回答什么问题。缺少任何一类，后续判断都会依赖口头补充或当事人记忆。
| 类别 | 依据项 | 回答的问题 |
|---|---|---|
| 缺陷记录 | 复现步骤、环境与版本、严重级别、影响范围 | 问题是什么、在什么条件下出现、影响多大 |
| 修复侧 | 变更内容、提交或变更单与缺陷的关联、根因说明、影响面评估 | 改了什么、为什么这样改、还可能波及哪里 |
| 验证侧 | 验证用例或复现路径、测试数据、验证环境版本 | 按什么条件验证、在哪个环境验证 |
| 结果与评审 | 执行结果、日志或截图、执行人与时间、关闭或退回结论 | 验证是否通过、由谁在何时确认、最终结论是什么 |
缺陷记录中的复现步骤要写到他人可照做的程度，包括前置数据、操作顺序和预期结果与实际结果的对比。环境与版本需要具体到构建号或发布批次，严重级别和影响范围用于确定验证力度和是否需要扩大回归。
修复侧依据的核心是关联关系：变更记录能指向它修复的是哪条缺陷。根因说明解释问题产生的机制，影响面评估说明同类代码路径、共用组件或相邻功能是否可能受影响。这三项共同决定验证范围，而不只是验证原复现路径。
验证侧依据要事先明确，而不是执行后补写。验证用例或复现路径说明怎么验，测试数据说明用什么数据验，环境版本说明在哪验。当缺陷环境与验证环境存在差异时，需要在记录中说明差异及判断理由。
结果与评审依据承担“结论可追溯”的作用。执行结果记录通过或不通过，日志与截图提供客观支撑，执行人和时间确定责任与时效，关闭或退回结论说明最终处置。四类依据串起来，才构成一条完整的证据链。
按阶段落实：修复提交、验证执行、关闭评审各做什么
依据清单解决“收集什么”，阶段动作解决“什么时候由谁产出”。三个阶段各自有明确的输入、动作、输出和完成标志，完成标志是进入下一阶段的门槛。
| 阶段 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 修复提交 | 已确认的缺陷记录 | 提交变更并在变更记录中关联缺陷，填写根因说明与影响面评估 | 带缺陷关联的变更记录与修复说明 | 缺陷状态进入待验证 |
| 验证执行 | 修复说明与验证条件 | 在指定环境按复现路径或用例执行，记录结果、日志或截图 | 验证结果记录 | 结果可被他人按记录复核 |
| 关闭评审 | 验证结果记录 | 核对依据是否齐备，给出关闭或退回结论 | 带结论的评审记录 | 缺陷状态与评审结论一致 |
修复提交阶段的关键动作是建立关联。变更内容、根因说明和影响面评估应在提交时一并填写，此时修复人对问题理解最完整。若等到验证阶段再补根因，容易写成对现象的描述而非原因分析。完成标志设为“状态进入待验证”，可以防止未关联变更的缺陷提前进入验证队列。
验证执行阶段的动作要围绕事先确定的验证条件展开。验证人先读修复说明和影响面评估，确认验证范围覆盖原复现路径及可能受影响的相邻功能，再在指定环境执行并记录结果。完成标志是“结果可被他人复核”，意味着记录中包含环境、数据、操作步骤和实际结果，而不是只写一句“验证通过”。
关闭评审阶段由缺陷负责人或评审角色核对四类依据是否齐全，确认验证结论与证据一致后给出关闭结论。若依据存在缺口，评审应退回补充，而不是以口头确认替代记录。完成标志是缺陷状态与评审结论一致，避免出现记录写关闭、系统状态仍为待验证的情况。
验证不通过时，退回同样需要依据。验证人应记录失败现象、实际结果与预期结果的差异、复现条件，并将缺陷退回修复环节。修复人据此补充变更或修正根因判断，重新提交后再次进入待验证。每次退回与重新提交都保留记录，形成完整的流转轨迹。
谁负责提供和确认这些依据
依据无人认领是证据链断裂的常见原因。按角色划分交付物，并明确交接点，可以减少重复收集和遗漏。
| 角色 | 交付物 | 交接点 |
|---|---|---|
| 缺陷提交人 | 可复现的缺陷描述、原始环境与版本信息、严重级别建议 | 提交缺陷时交付给缺陷负责人分派 |
| 修复人 | 变更关联、根因说明、影响面评估 | 变更提交并转入待验证时交付给验证人 |
| 验证人 | 验证执行记录、结果判断、日志或截图 | 验证完成后交付给评审角色 |
| 缺陷负责人或评审角色 | 依据齐备性确认、关闭或退回结论 | 评审完成后更新缺陷最终状态 |
缺陷提交人的责任在提交时基本完成，但其提供的复现步骤质量直接影响后续所有环节。提交人应尽量使用原始发现环境的信息，避免转述导致条件失真。缺陷负责人分派时，应确认复现步骤是否足够具体，不足时退回补充。
修复人与验证人之间的交接是证据链中最关键的一环。修复人交付的不只是代码变更，还包括根因说明和影响面评估，验证人据此确定验证范围。交接内容不完整时，验证人有权要求补充后再开始验证。
评审角色通常由缺陷负责人、测试负责人或约定的质量角色承担，其职责是核对而非重新验证。评审确认依据齐备、结论与证据一致后关闭缺陷；发现缺口时退回相应角色补充。角色可以由同一人兼任，但交付物和确认动作仍需分别留下记录。
一个缺陷修复验证的完整示例
以下为演示情景，用于说明各类依据的实际写法，不对应真实系统。
缺陷描述：订单列表页在筛选“待发货”状态并翻至第二页时，列表重复显示第一页的前三条订单。环境为测试环境 v2.4.1 构建 20240612，浏览器为 Chrome 125。严重级别为一般，影响范围为订单列表分页筛选功能。复现步骤：登录测试账号，进入订单列表，选择状态“待发货”，点击下一页，观察列表内容。
修复提交：变更单号 CHG-3187，关联缺陷 BUG-1042。变更内容为修正分页参数在筛选条件下的偏移量计算。根因说明：筛选条件改变结果集后，分页偏移仍按未筛选总数计算，导致页码与数据错位。影响面评估：同一分页组件被用于售后单列表和库存流水列表，需一并验证。
验证条件：验证环境为测试环境 v2.4.1 修复构建 20240614，测试数据为测试账号下 35 条待发货订单。验证路径为原复现步骤，另补充售后单列表与库存流水列表的分页筛选检查。
验证结果：订单列表筛选后翻页显示正确，售后单列表与库存流水列表分页正常。附三张列表截图与接口返回日志。执行人张某，执行时间 20240614 15:20，结论为通过。
关闭评审：评审人李某核对缺陷描述、变更关联、验证条件与结果记录，确认影响面已覆盖，结论为关闭，缺陷状态更新为已关闭，时间 20240614 16:05。
这个示例体现的规律有三点：复现步骤写到可照做，变更与缺陷双向可查，验证范围由影响面评估决定而非只验原路径。照此结构填写，即使换人接手也能独立判断修复是否成立。
完成检查：依据是否足以支撑关闭
关闭前逐项核对以下检查项，任何一项不满足都应退回补充。检查的目的是确认记录本身足以支撑结论，而不依赖当事人解释。
- 缺陷描述可复现：复现步骤、环境版本、预期与实际结果齐全，他人可照做。
- 变更已关联：变更记录能指向该缺陷，根因说明与影响面评估已填写。
- 验证条件明确：验证用例或复现路径、测试数据、验证环境版本在执行前已确定。
- 结果有记录：通过或不通过均有日志、截图或等效证据，执行人与时间可查。
- 结论有评审：关闭或退回结论由评审角色给出，且与缺陷状态一致。
通过标准可以统一表述为：一位未参与该缺陷的同事，仅凭记录即可复现原问题、确认修复生效、理解验证范围与结论。若需要向提交人或修复人当面询问才能判断，说明依据尚不充分。
以下情形应作为阻断项处理：缺少可执行的复现路径；变更记录未与缺陷关联；验证环境与缺陷环境不一致且未说明理由；验证结果没有执行记录或执行人。阻断项未消除前，缺陷不应关闭。
依据的留存要保证后续可查阅。缺陷关闭后，记录仍需保留，供版本回溯、同类问题排查和质量分析使用。当缺陷记录、变更关联、验证结果与评审结论在同一工作项流转中留痕时，追溯成本会明显降低。ONES 支持在缺陷工作项中关联变更与验证记录，并通过状态流转承载待验证、关闭与退回的交接，使证据链随缺陷生命周期自然沉淀，便于后续按缺陷或版本查阅。
常见问题
缺陷修复验证时，验证环境与缺陷发现环境不一致怎么办？
先判断差异是否影响结论。如果缺陷与具体构建号、浏览器版本或数据状态相关，应尽量在与缺陷一致的环境中验证；确实无法还原时，需要在验证记录中写明环境差异、差异可能带来的影响，以及仍判定通过的理由。评审角色据此判断证据是否充分，差异未说明的验证结果不应直接作为关闭依据。
修复人提交变更时根因还没完全确认，可以先进入验证吗？
可以进入验证，但根因说明不能空缺。修复提交阶段的完成标志是缺陷状态进入待验证，前提是变更已与缺陷关联并填写了根因说明与影响面评估。根因判断尚不确定时，应写明当前判断和待确认点，验证人据此扩大验证范围。若根因与影响面完全空白，验证范围无从确定，应先补充再流转。
验证不通过退回后，之前那轮验证记录需要保留吗？
需要保留。每轮验证的失败现象、实际结果与预期差异、复现条件都应留在缺陷记录中，修复人据此修正变更或调整根因判断。保留多轮记录可以形成完整流转轨迹，也便于后续判断问题是修复不彻底还是引入了新问题。只保留最后一轮通过记录，会丢失判断修复过程是否可靠的依据。
缺陷关闭后，这些依据还要留多久、给谁看？
留存时长按团队的质量管理与合规要求确定，通常至少覆盖当前版本周期及后续回溯需要。使用方包括版本回溯时的排查人员、处理同类问题的开发与测试、以及做质量分析的负责人。留存的关键是缺陷记录、变更关联、验证结果与评审结论能按同一缺陷查到，避免分散在聊天记录或个人文档中。
小缺陷也要走完整的四类依据吗？
依据类别可以按缺陷的严重级别和影响范围裁剪，但可复现、可追溯的底线不变。文案错别字一类缺陷，复现步骤和验证记录可以简短，变更关联仍需保留；涉及共用组件或核心流程的缺陷，则应完整填写根因说明与影响面评估，并扩大验证范围。裁剪的是记录详略，不是证据链结构。
