缺陷能否关闭，取决于验收结论是否成立，而不取决于修复动作是否完成。开发提交修复只说明缺陷进入待验证状态；测试按原复现步骤复测、核对影响范围、留下可追溯证据，并由修复人之外的角色确认后，缺陷才具备关闭条件。下面给出一套可落地的判定条件、操作步骤、角色分工与检查清单，适用于团队建立或修订缺陷修复验收流程的场景。
要点总览（TL;DR）
- 缺陷可进入关闭需同时满足四项条件：复测通过、验证范围覆盖、证据可追溯、无未决关联项，缺一项就停留在验证或待确认状态。
- 流程按“开发提交修复→测试复测→失败回退→再次提交验证→关闭判定”推进，每步明确输入、动作、输出与完成标志，状态随动作流转。
- 复测失败回退必须写清回退原因、实际现象与预期差异、复现条件；再次验证保留独立轮次记录，并约定轮次上限与升级条件。
- 开发、测试、缺陷责任人、复核角色各司其职，关闭动作由修复者之外的角色确认，避免修复者自证关闭。
- 流程落地后可用检查清单反向核对已关闭缺陷，确认能从关闭记录还原复测步骤、证据与确认人。
关闭判定要满足哪些条件
可进入关闭的缺陷，应同时满足四项条件。四项条件缺一项，缺陷就应停留在验证或待确认状态，避免把“改过了”当成“验过了”。
| 判定条件 | 判定标准 | 需要保留的证据 |
|---|---|---|
| 复测通过 | 按缺陷单记录的原复现步骤操作，实际结果与预期结果一致；原步骤无法完全复现时，说明替代验证方式及理由 | 复测记录，包含执行步骤、实际结果、执行时间与执行人 |
| 验证范围覆盖 | 覆盖修复点本身、修复可能影响的关联功能，以及必要的相邻功能；范围依据开发提交的影响说明确定 | 验证范围清单，逐项标注通过、不通过或不在本次范围及原因 |
| 证据可追溯 | 复测结论能对应到具体环境、版本、构建或提交，截图、日志等材料可被他人复核 | 环境与版本信息、截图或日志、复测结论记录 |
| 无未决关联项 | 关联缺陷、待确认问题已处理完毕，或已明确挂起并记录挂起原因与后续处理人 | 关联项清单及每项的处理结论 |
除四项条件外，还需保证判定人与确认人分离。执行复测的人给出验证结论，缺陷责任人或指定的复核角色确认关闭，修复者本人不单独完成关闭动作。这样做的目的是让关闭结论建立在他人可复核的证据上，而不是修复者的自我判断。
四项条件的证据要求应在流程设计阶段就写进缺陷单模板或状态流转规则中。若证据字段缺失，复测通过也只能视为口头结论，关闭判定缺少依据。
从复测到关闭的操作步骤
把修复、复测、回退、再次验证和关闭组织成连续流程，关键是每一步都有明确的输入、动作、输出和完成标志，状态随动作推进，记录随状态留存。
| 步骤 | 输入 | 动作 | 输出 | 完成标志与状态 |
|---|---|---|---|---|
| 步骤一：开发提交修复 | 缺陷单、修复说明、影响范围说明、自测结果 | 开发完成修复并自测，填写修复说明与影响范围，提交验证 | 待验证的缺陷单及修复说明 | 缺陷状态由“处理中”变为“待验证”，修复说明字段完整 |
| 步骤二：测试领取并复测 | 原复现步骤、预期结果、修复说明、影响范围 | 测试领取缺陷，按原步骤复测，并验证修复点与影响面 | 复测结论：通过或不通过，附证据 | 复测记录填写完成，结论明确 |
| 步骤三：复测失败回退 | 复测不通过的证据与现象描述 | 测试写明回退原因、实际现象、复现条件，退回开发 | 带失败证据的回退记录 | 缺陷状态变为“重新打开”或“待修复”，回退原因必填 |
| 步骤四：再次提交验证 | 补充修复说明、本轮修改内容 | 开发补充修复后再次提交，测试按轮次重新复测 | 新一轮复测记录，标注轮次 | 轮次编号连续，达到约定轮次仍未通过时触发升级 |
| 步骤五：关闭判定 | 复测通过记录、验证范围清单、证据材料、关联项处理结论 | 按四项条件逐项核对，确认人复核后关闭 | 关闭记录与判定依据 | 缺陷状态变为“已关闭”，四项条件核对项均有结论 |
回退环节需要写清三件事：回退原因、实际现象与预期结果的差异、复现所需条件。缺少其中任何一项，开发在下一轮修复时容易偏离问题本身，造成反复往返。
再次提交验证要保留轮次记录。每轮复测都应有独立记录，而不是覆盖上一轮结论。团队可约定一个轮次上限，例如同一缺陷连续三轮复测未通过时，由缺陷责任人或测试负责人组织分析，判断是修复方案问题、需求理解偏差还是环境差异，再决定继续修复、拆分缺陷或调整验收标准。
关闭判定不是简单点一下状态。确认人需要对照四项条件逐项核对，确认证据齐全、范围覆盖、关联项有结论，再执行关闭。若核对中发现证据缺失，应退回补充，而不是先关闭后补记录。
在缺陷工作项中承载上述流转时，ONES 可以把缺陷单、修复说明、复测记录与状态变更放在同一条工作项记录里，使每轮复测和回退原因都可查询，关闭前的核对项也有对应字段可填。流程设计者可将四项判定条件配置为关闭前的必填检查项，减少凭印象关闭的情况。
角色分工与各环节交付物
验收流程涉及开发、测试、缺陷责任人和复核角色。职责清晰的标准是：每个环节都有明确的责任人，每个交接点都有可检查的交付物，且没有两个角色对同一结论同时负责。
| 角色 | 主要动作 | 交付物 | 交接时点 |
|---|---|---|---|
| 开发 | 完成修复与自测，说明修改内容与影响范围 | 修复说明、影响范围说明、自测结果 | 提交验证时交接给测试 |
| 测试 | 按原步骤复测，核对影响面，记录结论与证据 | 复测记录、验证范围清单、通过或回退意见 | 复测完成后交接给确认角色；失败时退回开发 |
| 缺陷责任人 | 确认修复范围是否覆盖缺陷本身，核对关联项处理情况 | 范围确认意见、关联项处理结论 | 关闭判定前完成确认 |
| 复核或确认角色 | 对关闭判定做复核，处理验证结论争议 | 关闭确认记录、争议裁决结论 | 关闭动作执行前 |
缺陷责任人通常由提出缺陷或负责该功能模块的人担任，其职责是确认“修的是不是这个问题、影响面有没有遗漏”，而不是替代测试做复测。复核角色可由测试负责人、质量负责人或团队约定的评审人承担，重点处理测试与开发对结论不一致的情况。
交接时点要与状态流转绑定。开发提交后缺陷进入待验证，测试才有复测对象；测试给出通过结论后，确认角色才做关闭复核。若交接时点模糊，容易出现缺陷停留在某个状态无人推进的情况。
示例：一个缺陷从复测失败到关闭的完整走查
以下为演示情景，用于说明流程如何运转，不对应真实项目数据。
某系统缺陷单记录：在订单列表页按“金额从高到低”排序后，翻到第二页，排序结果恢复为默认顺序。复现步骤为登录测试环境、进入订单列表、选择金额降序、翻至第二页。预期结果为第二页仍按金额降序排列。
开发第一次提交修复，修复说明为“调整分页参数传递”，影响范围标注为订单列表排序与分页。缺陷状态变为待验证。测试按原步骤复测，发现第二页排序正确，但在切换每页条数后排序再次失效，于是判定复测不通过，回退原因写为“分页条数变更场景未覆盖”，附操作截图与复现条件，缺陷状态变为重新打开。
开发补充修复，在修复说明中注明同时处理了分页条数与排序参数的组合场景，并补充自测结果。缺陷再次进入待验证，本轮复测记录标注为第二轮。测试按原步骤复测，并增加每页条数切换、翻页与排序组合的验证项，结果均与预期一致，复测结论为通过。
关闭判定阶段，确认人逐项核对：复测通过，有第二轮复测记录；验证范围覆盖修复点、分页与排序组合场景；证据包含环境、版本、截图与执行时间；关联的两个同类排序缺陷已分别处理并记录结论。四项条件齐备后，确认人执行关闭，缺陷状态变为已关闭。
这个示例体现了两个要点：回退时写清未覆盖的场景，使下一轮修复有明确目标；每轮复测独立记录，使关闭时的判定依据可以回溯到具体轮次，而不是只看到最终结论。
完成检查：流程可执行性核对
流程写完后，可用下面这份清单逐项核对，确认它在实际项目中能被执行，而不是停留在文档里。
- 四项关闭判定条件是否都有对应的证据字段或附件要求，填写位置是否明确。
- 复测失败回退是否有独立状态，回退原因、实际现象、复现条件是否为必填项。
- 再次提交验证是否保留轮次记录，是否约定轮次上限与触发升级的条件。
- 开发、测试、缺陷责任人、复核角色的职责是否存在空缺或重叠，特别是关闭动作由谁执行。
- 测试与开发对结论有争议时，是否有指定的升级路径与裁决人，裁决结论是否记录。
- 缺陷从提交到关闭的每次状态变更、复测记录与证据是否可查询、可追溯。
- 验收流程与回归测试管理的边界是否清晰：本次验收聚焦单个缺陷的修复验证，整体回归范围由回归测试计划另行管理，两者在记录上能区分。
核对时建议挑一个近期已关闭的缺陷做反向检查：能否从关闭记录还原出复测步骤、证据和确认人。若还原不出来，说明流程中的记录要求还需要补强。流程可执行的标准，是任何人拿到一条已关闭缺陷，都能看懂它为什么可以关闭。
常见问题
复测时原复现步骤已经无法重现，还能判定复测通过吗？
可以，但需要把替代验证方式写清楚。原步骤无法完全复现时，应在复测记录中说明替代验证的操作方式、覆盖的场景以及采用该方式的理由，并附上对应的证据材料。判定标准仍然是实际结果与预期结果一致，只是验证路径发生了变化。若替代方式无法覆盖缺陷的核心场景，应视为验证范围不足，缺陷继续停留在验证状态，补充验证后再做关闭判定。
同一缺陷反复回退多轮，流程上应该怎么处理？
建议在流程中约定轮次上限，例如连续三轮复测未通过时触发升级。升级后由缺陷责任人或测试负责人组织分析，判断问题出在修复方案、需求理解偏差还是环境差异，再决定继续修复、拆分缺陷或调整验收标准。每轮复测保留独立记录，不覆盖上一轮结论，这样升级时能直接看到各轮的失败现象与回退原因，避免在同一问题上反复往返。
关闭判定由谁执行，测试给出通过结论后还需要复核吗？
测试给出复测通过结论后，仍建议由缺陷责任人或指定的复核角色做关闭确认。测试负责执行复测并给出结论，缺陷责任人确认修复范围是否覆盖缺陷本身、关联项是否处理完毕，复核角色处理测试与开发结论不一致的争议。关闭动作由修复者之外的角色执行，目的是让关闭结论建立在他人可复核的证据上。团队规模较小时，缺陷责任人与复核角色可由同一人承担，但应与修复者分离。
缺陷关闭后发现问题仍然存在，流程上如何补救？
按重新打开处理，并保留原关闭记录作为追溯依据。重新打开时写明发现问题的场景、与原复测结论的差异，以及本次验证的环境与版本信息。若属于原验证范围遗漏，应在流程复盘中补充对应的验证项；若属于修复引入的新问题，则作为新缺陷单独记录，并关联原缺陷。重新打开的次数和原因可作为检查验收流程有效性的参考，帮助识别验证范围设定或证据要求上的薄弱环节。
单个缺陷的验收和整体回归测试如何区分，记录上怎么体现？
单个缺陷的验收聚焦本次修复点及其影响面，验证范围依据开发提交的影响说明确定；整体回归测试针对变更后的系统范围，由回归测试计划另行管理。记录上可以这样区分：缺陷单内保留复测步骤、验证范围清单与关闭判定依据；回归测试在执行计划与测试报告中记录范围、用例与结果。两者在缺陷单上可通过关联项互相引用，但验收结论不替代回归结论，回归发现的问题按新缺陷进入验收流程。
