缺陷修复验证要解决的核心问题，是把“修复完成”和“验证通过”拆成两个独立状态：开发提交修复时提供根因、改动范围、影响模块和自测证据，缺陷进入待验证；验证人按原复现步骤、边界场景和关联影响逐项核对，通过后关闭，不通过则带证据退回并记录轮次。本文覆盖单个缺陷从确认到关闭这一段流程，给出状态流转、提交字段、判定标准和检查清单。流程承载上，ONES 测试管理可用于缺陷创建、关联与流转，并保留验证记录。
要点总览（TL;DR）
- 把“修复完成”和“验证通过”拆成两个独立状态：开发提交修复后缺陷进入待验证，由验证人独立复测并判定，避免开发自证自关。
- 状态集合覆盖新建、已确认、修复中、待验证、验证不通过、关闭、挂起，每个状态写明进入条件、负责人和完成标志，禁止跳步。
- 修复提交必填根因说明、改动范围、影响模块、自测记录和构建版本，验证人据此确认测试对象并确定补充验证范围。
- 验证判定分通过、不通过、部分通过三档，退回须附失败证据并记录轮次；变更后的整体回归归回归测试管理，不在单缺陷验证内展开。
- 用状态流转、字段完整性、验证记录、退回轮次和关闭证据五项清单定期抽查已关闭缺陷，核对闭环是否达标。
缺陷修复验证的核心流程与状态流转
缺陷修复验证的流程骨架由状态和流转规则构成。状态集合建议覆盖新建、已确认、修复中、待验证、验证不通过、关闭、挂起七种，每个状态都要写明进入条件、负责人和完成标志。流转规则的关键约束有两条：开发不能把自己的修复直接置为关闭；验证不通过必须回到开发侧，并记录退回轮次。
下表给出各状态的进入条件、负责人和完成标志，可作为配置缺陷工作流时的对照依据。
| 状态 | 进入条件 | 负责人 | 完成标志 |
|---|---|---|---|
| 新建 | 报告人提交缺陷，含现象描述与复现步骤 | 报告人 | 缺陷单创建，字段基本完整 |
| 已确认 | 缺陷管理负责人或开发确认可复现、属于缺陷 | 缺陷管理负责人 | 确认结论记录，指定修复负责人 |
| 修复中 | 开发接单并开始定位 | 开发 | 根因已定位，改动方案确定 |
| 待验证 | 开发提交修复，必填字段与自测证据齐全 | 开发提交，验证人接收 | 修复提交记录完整，构建版本明确 |
| 验证不通过 | 验证人复测未通过或部分通过 | 验证人 | 失败证据与退回原因记录，轮次加一 |
| 关闭 | 验证人按判定标准确认通过 | 验证人 | 验证记录与证据齐全，判定为通过 |
| 挂起 | 依赖外部条件、暂无法修复或验证 | 缺陷管理负责人 | 挂起原因与恢复条件记录 |
每一步的输入、动作和输出要能对上：新建的输入是缺陷现象，动作是填写复现步骤，输出是可复现的缺陷单；修复中的输入是确认结论，动作是定位根因和改动，输出是修复提交；待验证的输入是修复提交，动作是复测，输出是验证判定。完成标志的作用是让交接有明确依据，避免“改完了但没人知道能不能验”的模糊状态。
责任边界上，修复提交与验证分离是硬性要求。开发负责把修复内容和证据写清楚，验证人负责独立复测并给出判定，缺陷管理负责人负责状态规则和争议裁决。验证不通过时，缺陷退回开发侧，退回记录要包含失败现象、失败环境、对应轮次编号，下一轮修复提交时沿用同一缺陷单，轮次递增，便于统计反复修复的缺陷。
修复提交时必填的字段与证据
修复提交字段的设计目标是让验证人不必追问就能开始复测。字段划分建议以“验证人是否需要它来判断”为标准：影响判定的一律必填，仅作补充说明的设为选填。
| 字段名 | 填写要求 | 示例 |
|---|---|---|
| 根因说明 | 必填，说明问题产生的直接原因 | 分页参数在第二页起未重置，导致重复数据 |
| 改动范围 | 必填，列出修改的文件、模块或配置项 | 订单列表查询接口、分页组件参数初始化逻辑 |
| 影响模块 | 必填，标注可能受影响的上下游模块 | 订单列表、导出功能、报表统计 |
| 关联缺陷 | 选填，同一根因引发的其他缺陷单号 | 关联缺陷 #2317、#2320 |
| 自测记录 | 必填，对照原复现步骤逐条说明自测结果 | 按原步骤复测通过；补充测试第三页、空数据场景通过 |
| 构建版本或提交标识 | 必填，验证人据此确认测试对象 | 构建号 build-20240612-03 或提交哈希 |
| 补充说明 | 选填，遗留风险、临时方案或需特别关注的点 | 导出功能未做完整回归，建议验证时覆盖 |
自测记录要与原复现步骤对照填写，逐条写明“原步骤第几步、自测结果如何”，而不是只写“已自测通过”。构建版本或提交标识必须指向验证人实际可获取的构建，否则验证人无法确认自己测的是不是修复后的版本。影响模块的填写直接决定验证范围，开发对改动波及面最清楚，这一项由开发填写比由验证人猜测更可靠。
字段必填的落地方式有两种：在缺陷工作流中把必填字段设为状态流转的校验条件，或在团队规范中约定并由缺陷管理负责人在评审时检查。前者依赖工具配置，后者依赖人工把关，团队可按现有工具条件选择。ONES 测试管理支持缺陷的创建、关联与在测试和研发团队间流转，可作为承载修复提交记录的工作项载体；字段级必填校验的具体配置方式需以产品实际设置为准。
验证环节的操作步骤与判定标准
验证人拿到待验证缺陷后，按以下顺序执行：先确认构建版本与修复提交一致，再按原复现步骤逐条复测，然后补充边界场景和关联影响验证，最后给出判定并记录证据。复测时使用缺陷单中的原始步骤和环境，不自行简化步骤，否则无法证明原问题已消除。
边界与关联场景的补充验证范围来自修复提交中的影响模块。常见补充项包括：原步骤的相邻输入（空值、极值、超长内容）、原问题的相邻页面或接口、以及关联缺陷涉及的场景。补充验证不必扩展到整个版本回归，变更后的整体回归属于回归测试管理范畴，单缺陷验证只覆盖本次改动及其直接影响面。
| 判定结果 | 适用情形 | 后续动作 |
|---|---|---|
| 通过 | 原复现步骤全部复测通过，边界与关联场景无新问题 | 记录验证证据，状态置为关闭 |
| 不通过 | 原问题仍可复现，或修复引入新的可复现问题 | 附失败证据退回，轮次加一 |
| 部分通过 | 主场景通过，但关联场景存在遗留问题或未覆盖项 | 列明剩余项与再验证时间，状态置为验证不通过或保留待验证 |
验证记录应包含：验证时间、验证人、使用的构建版本、复测步骤与结果、补充验证的场景清单、截图或日志等证据、判定结论。多轮验证时，每轮记录独立保留，轮次编号与退回原因对应，便于判断某个缺陷是否反复修复仍未解决。时效管理上，可为待验证状态设定响应时限，例如提交后一个工作日内开始验证，超时由缺陷管理负责人协调；具体时限按团队节奏确定。
在 ONES 测试管理中，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，验证结论和过程记录可随缺陷单保留，便于后续追溯。
角色分工与各环节交付物
缺陷修复验证涉及四类角色，职责按“谁产生信息、谁做判定、谁维护规则”划分，避免开发自证自关。
| 角色 | 主要职责 | 关键节点交付物 |
|---|---|---|
| 报告人 | 提交缺陷，提供可复现的现象与步骤，配合补充信息 | 缺陷描述、复现步骤、环境信息、必要截图 |
| 开发 | 确认与定位问题，完成修复，提交修复证据，响应退回 | 根因说明、改动范围、影响模块、自测记录、构建版本 |
| 验证人 | 独立复测，补充边界与关联验证，给出判定 | 验证记录、证据材料、通过或不通过结论、剩余项清单 |
| 缺陷管理负责人 | 维护状态规则与字段要求，裁决争议，跟踪挂起与超时缺陷 | 状态流转规则、字段规范、争议处理结论、挂起与超时清单 |
跨角色交接的触发条件要明确：开发提交修复即触发向验证人的交接，条件是必填字段齐全；验证人判定不通过即触发向开发的退回，条件是失败证据和轮次记录完整；缺陷挂起或超时即触发缺陷管理负责人介入。职责冲突时，处理原则是以验证证据为准：开发认为已修复但验证人复现失败，按不通过处理并保留双方记录；验证人判定通过但后续发现同场景问题，按新缺陷或重开处理，并在记录中说明关联关系。
角色可以由同一人兼任，但修复提交与验证判定不宜由同一人完成。团队规模较小时，可由同组其他成员交叉验证，保持“提交者与判定者分离”这一条即可。
示例：一个缺陷从提交到关闭的完整记录
以下为演示情景，用于示范字段填写与判定过程，不对应真实项目数据。
缺陷描述与复现步骤。现象：订单列表翻到第二页后出现与第一页重复的记录。复现步骤：1）登录测试环境，进入订单列表；2）默认每页 20 条，翻至第二页；3）对比第一页与第二页记录，发现 3 条重复。环境：测试环境，构建 build-20240610-01。
第一次修复提交。根因说明：分页参数在翻页时未重置偏移量。改动范围：订单列表查询接口、分页组件初始化逻辑。影响模块：订单列表、导出功能。自测记录：按原步骤复测通过；补充测试第三页与空数据场景通过。构建版本：build-20240612-03。关联缺陷：无。
第一次验证。验证人使用 build-20240612-03 按原步骤复测，第二页重复问题消失；补充验证导出功能时发现导出结果仍包含重复记录。判定：部分通过。退回原因：导出功能未覆盖修复，附导出文件截图，轮次记为第 1 轮退回。
第二次修复提交。根因说明：导出逻辑独立拼接查询，未复用修复后的分页参数。改动范围：导出查询构造逻辑。影响模块：导出功能、报表统计。自测记录：原步骤复测通过，导出 100 条记录无重复。构建版本：build-20240613-01。
第二次验证与关闭。验证人复测原步骤与导出场景均通过，补充验证报表统计无异常。判定：通过。验证记录包含构建版本、复测步骤结果、导出文件抽样截图、判定结论，缺陷状态置为关闭，轮次记录显示共 2 轮验证、1 次退回。
完成检查：验证闭环是否达标
流程建立后，可按以下清单逐项核对机制是否运转到位。检查对象是缺陷单记录和状态流转，不是团队口头约定。
- 状态流转无跳步：每条已关闭缺陷都能回溯到已确认、修复中、待验证的完整路径，没有从修复中直接到关闭的记录。
- 修复提交字段完整：待验证及之后状态的缺陷单中，根因说明、改动范围、影响模块、自测记录、构建版本均有内容。
- 验证记录可追溯：每条关闭缺陷都有验证人、验证时间、构建版本、复测结果和证据材料。
- 退回轮次被记录：发生过退回的缺陷单保留每轮退回原因和轮次编号，能统计反复修复的缺陷数量。
- 关闭前具备验证证据：关闭动作由验证人执行，判定结论与证据同时存在，开发自关的记录为零。
- 挂起缺陷有出口：挂起状态缺陷均记录恢复条件与责任人，定期复核，不长期滞留。
检查频率可按迭代或按月执行，抽查已关闭缺陷和退回缺陷各若干条，对照上述条目逐项打勾。发现字段缺失或跳步记录时，先修正流程配置或规范，再回溯受影响缺陷。ONES 测试管理提供项目缺陷分布统计，可用于观察缺陷状态分布和反复修复情况，作为检查的辅助数据；统计口径以产品内实际配置为准。
常见问题
开发提交修复后，验证人应该先做什么？
先确认构建版本与修复提交中填写的构建号或提交标识一致，确保测的是修复后的版本；再按缺陷单中的原始复现步骤和环境逐条复测，不自行简化步骤。原问题确认消除后，再按影响模块补充边界与关联场景验证，最后给出判定并记录证据。
验证结果为“部分通过”时，缺陷应该关闭还是退回？
按剩余问题的性质处理：如果遗留项属于本次修复应覆盖的范围，例如关联模块仍存在同一根因导致的问题，按不通过退回并记录轮次；如果遗留项是尚未验证的关联场景，可保留待验证状态，列明剩余项和再验证时间，待补充验证完成后再判定。两种处理都要在缺陷单中写清剩余项，避免部分通过变成事实上的默认关闭。
团队规模小，开发和验证由同一人兼任可以吗？
角色可以兼任，但修复提交与验证判定不宜由同一人完成。可行的做法是由同组其他成员交叉验证，保留“提交者与判定者分离”这一条约束。若确实无法分离，至少在缺陷单中记录验证依据和证据，并由缺陷管理负责人在抽查时重点核对这类记录。
缺陷反复退回多轮仍未解决，流程上怎么处理？
每轮退回都要保留失败现象、失败环境和轮次编号，同一缺陷单轮次递增。当轮次达到团队约定的阈值时，由缺陷管理负责人介入，判断是根因定位不准、改动范围评估不足还是需求理解有偏差，必要时组织开发与验证人共同复现。反复修复的缺陷数量可作为流程检查的观察项，用于发现修复提交质量的问题。
单缺陷验证和变更后的整体回归是什么关系？
单缺陷验证只覆盖本次改动及其直接影响面，范围来自修复提交中的影响模块；变更后的整体回归测试属于回归测试管理范畴，关注版本层面的整体质量。两者衔接点在于：验证人在补充验证中发现影响面超出预期时，应反馈给缺陷管理负责人或测试负责人，由后者决定是否纳入回归范围。
