缺陷修复验收要解决的是“谁来判定、按什么判定、判定不通过往哪走”。做法是在提交修复前就把复现步骤、预期结果、验证环境和证据要求写进缺陷记录，修复后由验证人按同一口径复测；复测通过进入关闭判定，复测失败带证据回退给修复人并重新计时。本文给出可直接套用的字段表、状态流转表、角色分工、完整示例和自检清单，适用于缺陷从提交修复到关闭这一段流程。
要点总览（TL;DR）
- 验收标准的核心是让每条缺陷在修复前就具备可判定条件：复现步骤、预期结果、实际结果、影响范围、验证环境与测试数据、证据类型缺一不可。
- 状态流转要保证唯一出口：待修复→待复测→复测通过或复测失败回退；失败回退必须携带失败证据并重新计时，再次提交后重跑同一套验收条件。
- 关闭判定建议同时满足验证人通过结论、缺陷提出人业务确认和负责人审批，三者不全的缺陷停留在复测通过状态。
- 严重程度与优先级影响证据完整度和审批层级，高严重度缺陷要求更完整的证据组合，但判定条件本身不因级别降低。
- 流程上线后用检查清单核对字段完整性、回退记录、关闭门槛和返工计时，优先修正字段模板与状态进入条件。
验收标准先写清哪些字段
验收标准的价值在于让修复人和验证人对“修好了”有同一个判断依据。字段缺失时，常见结果是修复人认为已解决、验证人无法复现或无法确认，缺陷在两人之间反复流转。因此每条缺陷在进入修复前，应把判定条件写完整，而不是等复测时再补充说明。
下表列出缺陷修复验收应具备的字段。前四项是判定核心，缺一项就无法形成可复测的条件；后三项用于界定验证边界和证据要求。
| 字段 | 填写要求 | 判定作用 |
|---|---|---|
| 复现步骤 | 按操作顺序编号，写清入口、操作动作和触发条件；涉及特定数据时注明数据特征 | 验证人据此独立复现，避免依赖修复人口头说明 |
| 预期结果 | 描述修复后应出现的界面、数据或接口返回，尽量具体到可观察的值 | 作为通过与否的直接对照标准 |
| 实际结果 | 记录缺陷发现时的实际表现，保留原始报错信息或异常数据 | 与预期结果形成差异，界定修复目标 |
| 影响范围 | 说明受影响的模块、用户角色、业务流程，以及是否存在关联功能 | 决定复测时需要覆盖的关联场景，防止修一处坏一处 |
| 验证环境与测试数据 | 注明环境类型、版本号、账号权限和测试数据来源；数据需可重建 | 保证修复人与验证人在同一条件下比对结果 |
| 严重程度与优先级 | 按团队既有分级填写，并说明该级别对应的验收要求 | 影响证据完整度和关闭审批层级 |
| 证据类型 | 约定需要留存的形式：截图、日志片段、录屏、接口返回报文 | 让复测结论有可核查的支撑材料 |
严重程度与优先级会改变验收口径的严格程度，但不应降低判定条件本身。高严重度缺陷通常要求更完整的证据组合，例如界面问题附截图加日志、接口问题附请求与返回报文，关闭时增加负责人审批；低优先级缺陷可以简化证据类型，只保留关键截图，但复现步骤和预期结果仍需写清。这样处理的好处是：判定标准统一，投入的证据成本随风险分级调整。
证据类型建议在缺陷模板中预设为必填项，而不是复测时临时决定。截图适合界面展示类问题，日志适合异常与报错，录屏适合多步操作或时序相关问题，接口返回适合服务端数据处理问题。证据与状态变更一起留存，后续复盘或争议裁决时可以直接调取。
复测通过与失败回退怎么流转
状态流转要保证每种结果都有唯一出口：通过走向关闭，失败回到修复人，再次提交后重新进入复测。状态名称可以按团队习惯调整，但状态之间的进入条件和退出条件必须固定，否则缺陷会在状态之间滞留或跳过验证。
| 状态 | 进入条件 | 责任角色 | 退出条件与去向 |
|---|---|---|---|
| 待修复 | 缺陷已提交，验收字段填写完整 | 修复人 | 提交修复说明与自测记录后进入待复测 |
| 待复测 | 修复人已提交修复，验证环境就绪 | 验证人 | 按原验收条件复测，得出通过或失败结论 |
| 复测通过 | 复测结果与预期结果一致，关联场景无新增异常 | 验证人 | 进入关闭判定，等待提出人确认与负责人审批 |
| 复测失败回退 | 复测结果与预期不符，或修复引入新的关联问题 | 验证人 | 附失败证据退回修复人，重新计时，回到待修复 |
| 关闭 | 复测通过，提出人确认业务场景满足，负责人审批完成 | 负责人 | 流程结束，记录归档 |
复测通过后的关闭判定需要三个条件同时满足：验证人给出明确的通过结论并附证据，缺陷提出人确认原始业务场景已经满足，负责人完成关闭审批。三者缺一，缺陷停留在复测通过状态，不直接关闭。这样设计是为了避免验证人只验证技术表现、忽略业务使用场景的情况。
复测失败时，回退对象是原修复人，回退时必须携带失败证据：复测时的实际表现、与预期结果的差异、复现所用环境和数据。缺陷重新计时，计时起点为回退时间，而不是首次提交时间，这样修复时长统计能反映真实返工。再次提交后，验证人重跑同一套验收条件，包括复现步骤、预期结果和影响范围中列出的关联场景；验收条件本身不因返工而放宽，如需调整，应由提出人和负责人确认后修改并记录变更原因。
在工具层面，缺陷状态、复测记录和关闭审批可以放在同一个缺陷工作项中流转。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并可将缺陷关联至迭代，使复测记录与迭代进度对应。具体状态配置和审批设置以实际使用版本为准。
角色分工与各环节交付物
流程能否执行，取决于每个角色是否清楚自己要交什么。下表按环节列出角色、动作和交付物，交付物是判断该环节是否完成的依据。
| 角色 | 关键动作 | 交付物 | 完成标志 |
|---|---|---|---|
| 修复人 | 分析缺陷原因，完成修复，在提交前自测 | 修复说明（改动范围、原因分析）、自测记录（自测环境、自测结果） | 缺陷状态变为待复测，自测记录可查 |
| 验证人 | 按原验收条件复测，覆盖影响范围内的关联场景 | 复测记录（环境、数据、步骤、结果）、复测结论及证据 | 给出通过或失败结论，证据随记录留存 |
| 缺陷提出人 | 确认修复后业务场景是否满足原始诉求 | 业务确认意见 | 明确表示满足或不满足，不满足时说明差异 |
| 负责人 | 审批关闭，处理修复人与验证人之间的判定争议 | 关闭审批记录、争议裁决结论 | 审批完成或争议有明确结论 |
修复人的自测记录容易被省略，但它是复测的第一道过滤。自测记录至少包含自测环境和自测覆盖的场景，验证人可以据此判断复测重点。验证人的复测记录要与验收字段对应，逐项写明复现步骤的执行结果，而不是只写“已验证通过”。提出人的确认环节适合业务影响明显的缺陷，纯技术类缺陷可由验证人结论直接进入审批。负责人的争议裁决需要以验收字段和证据为依据，裁决结论应记录在缺陷中，供后续类似问题参考。
一个完整示例：从提交修复到关闭
以下为演示情景，用于说明流程如何串联，不代表真实项目数据。
验收条件填写。某订单列表页面在筛选条件组合后出现分页错乱。缺陷记录中填写：复现步骤为进入订单列表、选择两个筛选条件、翻到第二页；预期结果为分页总数与筛选结果一致、页码可正常切换；实际结果为总数显示全部订单数量、第二页出现重复记录；影响范围为订单列表模块及导出功能；验证环境为测试环境指定版本、使用测试账号和固定测试数据集；严重程度为高，要求附截图与接口返回报文；证据类型为截图、接口返回。
第一次提交与复测失败。修复人提交修复说明，注明调整了分页参数传递逻辑，并附自测记录。验证人按原条件复测，发现分页总数已正确，但导出功能仍按未筛选的全量数据导出，与影响范围中列出的关联场景不符。验证人将缺陷回退，附复测截图和导出接口返回报文，说明差异点，缺陷重新计时并回到待修复。
再次提交与复测通过。修复人补充修复导出逻辑，再次提交并附自测记录。验证人重跑同一套验收条件，包括列表分页和导出两个场景，结果均与预期一致，附复测截图和接口返回。缺陷进入复测通过。
关闭判定。缺陷提出人确认筛选加导出的业务场景已满足，负责人完成关闭审批。缺陷关闭，全过程的时间点、状态变更和证据均保留在缺陷记录中。这个示例说明：影响范围写清楚，才能在复测时发现关联功能的问题；回退带证据，修复人才能准确定位返工点。
ONES 测试管理可为测试活动生成多维度测试报告，并提供项目缺陷分布统计，复测记录和缺陷状态在缺陷工作项中留存，可作为验收结论和后续复盘的依据。
完成检查：验收流程是否可执行
流程上线后，可用以下清单逐项核对。每项都对应可观察的记录或状态，而不是主观感受。
- 抽查近期缺陷，每条是否具备复现步骤、预期结果、实际结果、影响范围、验证环境和测试数据；缺少任一项的缺陷是否被要求补充后再进入修复。
- 复测失败的缺陷是否都有明确的回退记录，包含失败证据、回退对象和重新计时的时间点。
- 再次提交的缺陷是否按原验收条件重跑，验收条件发生变更时是否有变更记录和确认人。
- 关闭的缺陷是否同时具备验证人通过结论、提出人业务确认和负责人审批；三者不全的缺陷是否停留在复测通过状态。
- 严重程度与优先级是否实际影响了证据要求和审批层级，而不是所有缺陷走同一套流程。
- 任取一条已关闭缺陷，能否从记录中还原提交、复测、回退、再次提交、关闭的完整时间线和证据。
- 修复时长统计是否以回退后的重新计时为准，返工情况能否从数据中识别。
检查中发现的问题，优先修正字段模板和状态进入条件，再调整角色分工。字段和状态是流程可执行的基础，角色职责在此基础上才能稳定运转。
常见问题
缺陷复测失败回退后，修复时长应该从哪个时间点重新计算？
计时起点应为回退时间，而不是首次提交修复的时间。这样统计出的修复时长能反映真实返工，返工次数也能从数据中识别。如果团队按首次提交时间累计，返工缺陷的耗时会被低估，后续分析修复效率时容易失真。回退记录中应同时写明回退时间、回退对象和失败证据，便于核对。
验收条件在返工过程中可以调整吗？
可以调整，但需要留下变更记录。再次提交后验证人默认重跑原验收条件，包括复现步骤、预期结果和影响范围中列出的关联场景；如果确认原条件本身有误或业务诉求发生变化，应由缺陷提出人和负责人确认后修改，并在缺陷记录中写明变更原因和确认人。验收条件不因返工而自动放宽。
低优先级缺陷是否也要走完整的关闭审批？
可以按风险分级简化。严重程度与优先级影响的是证据完整度和审批层级，判定条件本身不降低。低优先级缺陷可简化证据类型，例如只保留关键截图，关闭审批也可由验证人结论直接进入；高严重度缺陷通常要求截图、日志或接口报文等组合证据，并增加负责人审批。分级规则应写进缺陷模板，避免逐条临时判断。
验证人复测通过，但缺陷提出人认为业务场景没满足，怎么处理？
缺陷停留在复测通过状态，不直接关闭。提出人需说明未满足的具体差异，验证人据此判断是验收条件遗漏还是修复范围不足：属于验收条件遗漏的，补充条件后重新复测；属于修复范围不足的，带证据回退给修复人。双方判断不一致时由负责人依据验收字段和证据裁决，裁决结论记录在缺陷中。
缺陷状态和复测记录在工具中如何承载？
可以把缺陷状态、复测记录和关闭审批放在同一个缺陷工作项中流转。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并可将缺陷关联至迭代；测试活动可生成测试报告，并提供项目缺陷分布统计，作为验收结论和复盘的依据。具体状态配置与审批设置以实际使用版本为准。
