缺陷修复后复测失败，默认做法是在原缺陷记录上重开，把状态从待验证或已修复退回处理中，保留同一条缺陷的完整历史与复测证据。只有复测失败暴露出与原始问题不同的独立缺陷，或原记录已关闭归档且需要独立统计口径时，才新建记录并关联原缺陷。判断的核心是失败原因是否同一根因、是否落在同一修复范围，以及团队对缺陷计数与追溯的口径。
要点总览（TL;DR）
- 默认在原缺陷记录上重开：把状态从待验证或已修复退回处理中，保留同一条缺陷的完整历史与复测证据。
- 新建记录的例外情形：复测失败暴露出独立根因、问题位于不同模块或需不同责任人，以及原记录已关闭归档且需要独立统计口径。
- 判断前先核对证据：复测步骤与结果、失败日志或截图、修复提交的变更范围，并先排除复测环境差异。
- 处置后按清单验证：复测通过、原缺陷与新缺陷状态一致、同一问题只计一次、证据可回溯。
- 用缺陷模板固定复测结论字段，并把重开与新建的团队约定写进文档，减少同类争议反复出现。
复测失败先看症状：分清同一缺陷复发还是新问题
复测失败本身只是一个结果状态，处置前需要先看失败的具体表现。不同的表现指向不同的原因，也决定了后续是回到原记录继续处理，还是另立一条新缺陷。本文讨论的范围限定在单条缺陷从修复完成到验证这一环节；变更后涉及多个模块、多条缺陷的整体回归安排，属于回归测试管理的范畴，这里不展开。
拿到复测结果后，先对照原始缺陷的描述逐项核对：原来失败的步骤是否仍然失败，失败是否只出现在部分场景或部分数据下，报错信息是否与修复前一致，影响面是否扩大到了原缺陷未涉及的模块。这几项核对能快速把失败归入下表几类症状。
| 复测表现 | 初步判断 | 后续走向 |
|---|---|---|
| 原始步骤按原样执行仍然失败，报错与修复前一致 | 修复未生效或未覆盖到该路径，属同一根因 | 重开原缺陷，退回处理中 |
| 原始步骤通过，但相邻场景、边界数据或关联功能失败 | 修复范围不完整，或修复引入的新问题，需进一步看变更范围 | 核对修复提交后决定重开或新建 |
| 出现修复前没有的新报错、新异常日志 | 很可能是修复引入的新缺陷，根因与原缺陷不同 | 倾向新建，并关联原缺陷 |
| 影响面扩大到原缺陷未涉及的其他模块或用户路径 | 独立缺陷，修复责任人和修复范围可能不同 | 新建记录，标注来源为复测发现 |
| 仅在复测环境失败，其他环境正常 | 先排查环境差异，暂不判定修复无效 | 补齐环境信息后重新复测，再决定处置 |
症状归类的作用是缩小判断范围，不能替代证据。比如“出现新报错”只是提示可能为新缺陷，还需要看修复提交改动了哪些文件、新报错是否落在改动范围内，才能确认根因是否独立。把症状当结论直接新建或直接重开，都容易造成记录失真。
重开与新建各自的适用条件及判断证据
重开与新建的分界，可以归纳为一句话：同一个问题没修好，重开；修好了一个问题却带出另一个问题，新建。落到操作层面，需要同时满足根因、修复范围、记录状态三个条件才能下结论。
重开的适用条件
- 复测失败的原因与原始缺陷是同一根因，例如同一处逻辑判断错误、同一个空值未处理、同一接口返回异常。
- 失败落在原缺陷声明的修复范围内，开发提交的变更正是针对这条缺陷，只是没有覆盖完整。
- 原记录仍处于可流转状态，例如待验证、已修复、验证不通过等，能够退回处理中继续指派。
- 团队希望这条缺陷的修复次数、复测轮次、处理时长保持在同一记录上，便于追溯。
新建的适用条件
- 复测失败暴露出独立根因，与原始缺陷的成因不同，例如原缺陷是前端展示错误，复测发现的是后端计算错误。
- 问题位于不同模块，或需要不同的修复责任人接手，继续挂在原记录上会造成责任归属混乱。
- 原记录已关闭归档，重新打开会破坏已归档批次的历史完整性，或团队规定关闭后的记录不再流转。
- 团队需要按独立缺陷统计该问题的数量、严重等级和处理周期，挂在旧记录上会导致计数口径失真。
支撑判断需要的证据
判断不能停留在“看起来像”。下表把条件和对应证据放在一起，便于在复测现场逐项核对。
| 判断条件 | 需要的证据 | 结论 |
|---|---|---|
| 根因是否相同 | 复测步骤与结果、失败日志或截图、修复提交的变更说明 | 根因相同则倾向重开，根因不同则倾向新建 |
| 是否同一修复范围 | 修复提交涉及的文件、模块、接口清单，与原缺陷描述比对 | 失败点在变更范围内且未修好，重开 |
| 原记录是否可流转 | 当前状态、是否已关闭归档、状态流转权限 | 可流转则重开，已归档且不宜回退则新建并关联 |
| 统计口径要求 | 团队对缺陷计数、重开率、复测失败率的定义 | 需要独立计数则新建，需要保留单条历史则重开 |
| 是否为环境差异 | 复测环境与修复验证环境的版本、配置、数据差异 | 环境差异先排除，排除后再判定修复是否有效 |
两类常见误判
第一类是把复测环境差异当成修复无效。复测环境的构建版本落后于修复分支、配置项未同步、测试数据与修复验证时不一致，都会让原本修好的功能再次失败。遇到这种情况，先核对环境版本与配置，补齐后再复测，避免在原记录上反复重开又反复通过。
第二类是把握不住边界，把新问题挂在旧记录上。修复引入的新缺陷如果继续挂在原记录里，原缺陷的处理时长会被拉长，缺陷数量被少计，后续按模块或按责任人统计时都会失真。反过来，把同一根因的复发拆成多条新记录，也会让重开率和修复质量的数据失去参考价值。
按情形处置：重开与新建的操作步骤
判断完成后，处置动作要保证三件事：状态变化有记录、复测证据有落点、相关角色知道下一步由谁接手。以下步骤按重开和新建两种情形分别列出。
情形一：重开原缺陷
- 把缺陷状态从待验证或已修复退回处理中，并在状态变更说明中写明“复测失败，退回处理”。
- 在缺陷记录中补充本轮复测信息：复测时间、复测人、复测环境与版本、执行步骤、实际结果、失败日志或截图。
- 重新指派给原修复人或当前模块负责人；如果原修复人已不在该任务上，指派前先确认接手人。
- 保留原严重等级和优先级，除非复测失败导致影响面明显扩大，此时在记录中说明调整理由后再修改。
- 通知测试发起人和相关开发，说明复测结论与下一轮验证的预期时间。
情形二：新建缺陷记录
- 新建一条缺陷，完整填写复现步骤、实际结果、期望结果、环境和版本，按新问题本身的严重程度定级。
- 在来源字段或描述中标注“复测发现”，并关联原缺陷记录，写明与原缺陷的关系，例如“修复 A 问题后引入 B 异常”。
- 指派给新问题对应的修复责任人，避免默认沿用原缺陷的处理人。
- 原缺陷按实际情况处理：如果原问题本身已修复通过，按验证通过关闭；如果原问题仍未修好，原记录仍需重开，两条记录各自闭环。
- 确认新记录没有被重复创建，同一复测失败只对应一条新缺陷。
涉及关闭归档记录与权限时的处理
原记录已关闭归档时，先确认团队对归档记录的管理约定：允许回退的，按重开流程处理并在记录中说明回退原因；不允许回退的，新建记录并关联原缺陷，保留原记录的归档状态不动。状态回退、关闭、重新打开这类操作通常涉及权限配置，执行前确认当前账号具备相应权限，或由缺陷管理员代为操作，避免出现状态改到一半无法继续的情况。
操作前的风险边界
- 调整状态或合并记录前，先确认修复提交的变更范围，避免在原因未查清时反复改动记录状态。
- 原始复测证据要先保存到记录中再改状态，防止状态回退后旧结论被覆盖、后续无法还原。
- 需要批量调整多条记录时，先冻结相关状态或暂停流转，逐条核对后再放开，降低误操作影响面。
- 删除、合并记录属于不可逆操作，执行前确认没有其他记录引用该缺陷，必要时先导出留档。
在缺陷管理工作项中承载上述流程时，记录的状态流转、复测信息补充和缺陷之间的关联需要落在同一条可追溯的链路上。ONES 测试管理解决方案提供覆盖全生命周期的缺陷管理，缺陷可关联至迭代；在缺陷追踪场景中支持一键创建并关联缺陷，便于团队成员围绕同一条缺陷协作。ONES Project 与 TestCase 数据互通，可一键提 Bug 至对应项目或迭代，用于记录和跟踪缺陷修复情况。这些能力对应的是记录承载与关联动作，具体的状态回退规则和权限配置仍需按团队实际配置确认。
处置后的验证与复发预防
处置动作完成不等于问题闭环。需要确认修复真正通过、记录状态一致、统计数据没有重复，再回头看这类争议为什么反复出现。
处置后的验证清单
| 验证项 | 通过标准 | 不通过时的动作 |
|---|---|---|
| 复测结果 | 原始失败步骤与相关场景均通过，无新报错 | 回到症状分类，重新判断重开或新建 |
| 原缺陷状态 | 已按实际情况关闭或保持处理中，状态与结论一致 | 核对状态变更记录，修正错误流转 |
| 新缺陷状态（如有） | 已指派、已关联原缺陷、来源标注清楚 | 补齐关联关系与来源字段 |
| 统计口径 | 同一问题只计一次，重开次数与新建数量可区分 | 排查重复记录，合并或标注 |
| 证据完整性 | 复测步骤、日志、环境版本均可回溯 | 补充缺失信息后再关闭 |
减少同类争议的预防措施
- 在缺陷模板中固定复测结论字段，例如复测结果、失败表现、是否同一根因、处置方式，让每次复测都留下可比较的结构化信息。
- 把重开与新建的团队约定写成简短规则，附在缺陷提交页或团队文档中，明确默认重开、例外新建，减少逐次讨论。
- 定期抽查缺陷记录质量，重点看复测失败后是否补充了证据、新建记录是否关联了原缺陷、关闭记录是否有验证结论。
- 用缺陷流转数据观察重开率和复测失败分布，例如按模块看重开次数、按修复人看复测失败比例，作为调整修复流程或补充测试用例的依据。ONES Project 可统计缺陷状态分布，用于沉淀问题和经验；更细的重开率口径需要团队在统计时自行定义。
这些措施的目标是让判断有据可依、处置有迹可循。规则本身可以随团队规模和数据反馈调整，但每次调整都应同步到缺陷模板和团队约定中，避免规则停留在口头、记录各写各的。
常见问题
复测失败但原缺陷已经关闭归档，还能直接重开吗？
先确认团队对归档记录的管理约定。允许回退的，按重开流程处理，并在状态变更说明中写明回退原因；不允许回退的，新建一条缺陷记录并关联原缺陷，原记录的归档状态保持不变。两种做法都要把本轮复测的时间、环境版本、执行步骤和失败证据补充到记录中，避免后续追溯时缺少依据。
复测时只有部分场景失败，算同一缺陷没修好还是新缺陷？
关键看失败点是否落在原缺陷声明的修复范围内。如果修复提交正是针对这条缺陷，只是没有覆盖到相邻场景或边界数据，属于同一根因未修完整，应重开原记录。如果失败点位于修复提交未改动的模块，或出现修复前没有的新报错，则更可能是独立缺陷，应新建记录并关联原缺陷。判断前先核对修复提交涉及的文件、模块和接口清单。
复测环境和其他环境结果不一致，应该先重开还是先排查？
先排查环境差异，暂不判定修复无效。核对复测环境的构建版本是否落后于修复分支、配置项是否同步、测试数据是否与修复验证时一致。补齐环境信息后重新复测，再根据结果决定重开还是新建。把环境差异当成修复无效直接重开，容易造成同一缺陷反复重开又反复通过，影响重开率数据的参考价值。
重开和新建同时发生的情况怎么处理，会不会重复计数？
两条记录各自闭环即可。原问题仍未修好的，原记录重开并继续处理；复测暴露的独立新问题，新建记录并关联原缺陷、标注来源为复测发现。统计时按问题本身计数：同一根因只计一次，新缺陷单独计入。处置完成后核对一遍，确认同一复测失败只对应一条新记录，避免重复创建导致缺陷数量虚高。
团队规模不大，也需要把重开与新建的规则写成文档吗？
建议写下来，篇幅可以很短。规则至少包含默认重开、例外新建、判断所需证据三项，附在缺陷提交页或团队文档中。人数少的团队口头约定也能运转，但人员变动或缺陷量上升后，判断口径容易不一致。规则写好后同步到缺陷模板的复测结论字段，让每次复测都留下可比较的结构化信息，后续调整也有依据。
