缺陷复测的范围以该缺陷本身及其直接关联的改动为界，通常覆盖原复现路径、修复涉及的模块与接口，以及修复可能波及的相邻功能；通过标准是原复现步骤不再出现该缺陷、修复未引入新的可观察异常，并且用例执行结果与证据记录完整可追溯。变更后的整体回归属于回归测试管理，不在复测范围内。下面按定义、边界、流程、判定和相邻概念逐项说明。
要点总览（TL;DR）
- 缺陷复测的范围以该缺陷本身及其直接关联改动为界：覆盖原复现路径、修复涉及的模块与接口，以及修复可能波及的相邻功能；变更后的整体回归归回归测试管理。
- 复测通过需要四项条件同时成立：原复现步骤不再出现该缺陷、修复未引入新的可观察异常、相关用例执行完整、执行记录与证据可追溯。
- 复测与修复验证指向同一环节，只是表述角度不同；复测与回归测试的分工在于前者回答“这个缺陷修好了吗”，后者回答“这次变更有没有破坏别的功能”。
- 复测不通过时退回开发并重开缺陷，写清失败现象、复现条件和与上次修复的差异；属于新问题的应单独建缺陷并关联原缺陷。
- 常见误解包括把复测当回归、以修复提交代替验证、只看主路径、证据缺失也算通过，这四种做法都会让复测结论失去可信度。
缺陷复测是什么：一句话定义
缺陷复测是缺陷修复提交之后、缺陷关闭之前进行的一次针对性验证：按照缺陷原本的复现条件重新执行，确认修复有效，并检查修复动作是否带出新的可观察问题。它的对象是某一个已修复的缺陷，而不是整个版本或整条业务链路。
可以用一句话判断某项工作是否属于复测：如果这次验证的起点是“某个缺陷已被修复”，终点是“该缺陷可以关闭或需要退回”，那么它就是复测。反过来，如果验证的起点是“版本发生了变更”，目的是确认变更没有破坏既有功能，那属于回归测试。
复测的目的有三个层次。第一层是确认缺陷现象消失，即原复现步骤不再触发该问题。第二层是确认修复没有引入新的异常，包括修复点周边的报错、数据异常或交互变化。第三层是留下可追溯的记录，让后续的人能够判断这个缺陷当时是如何被验证通过的。三层都完成，复测才算真正结束。
复测的范围边界：包含什么、不包含什么
复测范围界定的核心原则是“跟着缺陷走，跟着改动走”。范围过窄，修复带出的问题会漏到线上；范围过宽，复测会膨胀成一轮回归，拖慢缺陷关闭节奏。实际操作中，可以按下面的清单确定覆盖对象。
复测应包含的内容：
- 原复现路径：缺陷报告中的前置条件、操作步骤、输入数据和预期结果，按原样重新执行一遍。
- 修复涉及的模块与接口：开发改动落在哪个功能、哪个服务或哪个接口，就在对应位置验证其行为。
- 修复波及的相邻功能：与修复点共享数据、共享组件、共享状态或存在调用关系的功能，检查其表现是否发生变化。
- 缺陷相关的用例：与该缺陷关联的测试用例，包括原失败用例和补充的边界用例。
复测不包含的内容：
- 变更后的整体回归。版本内所有功能的全量验证属于回归测试管理，由回归计划统一安排，不挂在单个缺陷的复测任务下。
- 代码修复方法本身的评审。修复方案是否合理、代码是否优雅，属于代码评审和开发自测的职责，复测只对可观察的行为结果负责。
- 与本缺陷无关联的其他缺陷。复测过程中顺带发现的新问题应单独记录为新缺陷，不并入本次复测的判定。
范围边界需要在复测开始前写清楚，而不是执行完再补。缺陷单中记录“影响范围”或“复测要点”，可以让执行人明确要跑哪些路径、看哪些相邻功能，也方便评审人判断复测是否充分。
复测的组成与执行流程
复测由四个环节组成，每个环节都有明确的输入和产出。环节之间的交接信息完整，复测结论才站得住。
环节一：复测任务接收与信息核对
执行人拿到修复完成的缺陷后，先核对信息是否齐全：复现步骤是否可执行、环境与版本是否明确、修复说明是否写清改动位置、影响范围是否标注。信息缺失时退回补充，避免带着模糊条件开始验证。这一环节的产出是一份可执行的复测任务，包含环境、版本、步骤和关注点。
环节二：复现验证与修复点确认
按原复现步骤执行，观察缺陷现象是否消失。同时对照修复说明，确认改动确实落在预期位置，行为变化与修复描述一致。如果原步骤无法复现缺陷，需要判断是环境差异、数据差异还是修复已生效，不能直接记为通过。产出是原路径的验证结果和修复点确认记录。
环节三：关联影响检查
围绕修复点检查相邻功能与接口。重点看三类情况：共享同一数据对象的其他入口是否正常；调用同一接口的其他页面是否返回正确；修复涉及的边界条件在相邻场景下是否同样成立。产出是关联检查的结果清单，逐项标注正常或异常。
环节四：结论记录与状态流转
把原路径结果、关联检查结果、执行环境和证据一并记录，给出通过或不通过的结论，并推动缺陷状态流转。通过则进入待关闭或已关闭；不通过则退回开发并重开缺陷，附上失败现象和复现条件。产出是一条可追溯的复测记录和明确的缺陷状态。
在工具层面，复测任务接收、状态流转和证据留存需要落在同一处，避免结论散落在聊天记录里。ONES 测试管理解决方案覆盖缺陷管理流程，缺陷可关联至迭代，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；复测结论和关联记录可以随缺陷单一起保留，便于后续追溯。对于需要按迭代观察质量情况的团队，ONES 还提供测试报告与项目缺陷分布统计，可作为复测结果的汇总参考。
通过标准如何界定：判定条件与证据
复测通过不是“看起来没问题”，而是一组可核验的条件同时成立。建议把判定条件写成清单，执行人逐项确认，评审人按同一份清单复核。
| 判定条件 | 具体含义 | 需要的证据 |
|---|---|---|
| 原缺陷不再出现 | 按缺陷单中的前置条件、步骤和数据重新执行，结果符合预期 | 执行记录、实际结果截图或日志、执行环境与版本 |
| 修复未引入新的可观察异常 | 修复点及相邻功能在检查中表现正常，无报错、无数据错乱、无交互回退 | 关联检查清单及逐项结果 |
| 相关用例执行完整 | 与缺陷关联的用例已执行，原失败用例转为通过，补充的边界用例有结论 | 用例执行结果、失败项说明 |
| 记录可追溯 | 执行人、执行时间、环境版本、结论和证据齐全，他人可据此复核 | 缺陷单中的复测记录与附件 |
四项条件全部满足，才判定为通过。其中任何一项存疑，例如原步骤因环境原因未能执行、相邻功能检查未覆盖，都应记为待确认而不是通过。
不通过时的处理：复测发现缺陷仍可复现，或修复带出了新的可观察异常，应退回开发并重开缺陷。退回时写清三件事：失败的现象、复现的条件、与上次修复的差异。缺陷重开后重新进入修复流程，再次修复完成后重新发起复测。若异常属于新问题而非原缺陷未修好，应单独创建缺陷并关联原缺陷，避免把两个问题混在一条记录里导致状态反复。
通过标准的具体阈值需要结合团队规范确定。例如相邻功能检查覆盖几个入口、证据需要截图还是日志，不同团队可以有不同要求，但“原路径验证、关联检查、证据留存”这三项不能省略。
复测、修复验证与回归测试的区别
这三个概念经常被混用，混用的直接后果是范围失控或验证缺失。复测与修复验证指向同一环节：修复验证强调对修复结果的确认，复测强调按原路径重新执行验证，二者可以视为一体，只是表述角度不同。真正需要区分的是复测与回归测试。
| 维度 | 复测（含修复验证） | 回归测试 |
|---|---|---|
| 验证对象 | 单个已修复的缺陷及其直接关联改动 | 变更后的版本或功能整体 |
| 触发时机 | 修复提交之后、缺陷关闭之前 | 版本变更、功能上线或阶段性质量检查时 |
| 范围依据 | 缺陷的复现路径与修复影响范围 | 回归计划确定的用例集与功能清单 |
| 主要责任人 | 缺陷的验证人，通常为测试执行人 | 回归计划的组织者与执行团队 |
| 结论去向 | 缺陷关闭或退回重开 | 版本是否可发布的质量判断 |
分工上，复测回答“这个缺陷修好了吗”，回归测试回答“这次变更有没有破坏别的功能”。一个缺陷复测通过，不代表版本可以发布；一轮回归通过，也不替代对单个缺陷的复测确认。两者在缺陷生命周期中前后衔接：复测关闭缺陷，回归守住版本质量底线。
具体例子与常见误解
下面用一个演示情景说明范围与标准如何落地。某订单系统在提交订单时，使用优惠券后金额显示为原价，缺陷单记录了复现步骤、测试账号和预期金额。
开发修复后提交说明：优惠券计算逻辑调整，涉及订单金额计算接口和订单详情页展示。复测执行人先核对信息，确认环境与版本；随后按原步骤下单并使用同一张优惠券，检查订单金额是否按折扣显示，原缺陷现象消失；接着检查关联影响，包括不使用优惠券的普通下单、订单详情页金额展示、退款时按折后金额计算这三个相邻场景；最后把执行结果、截图和版本信息记录在缺陷单中，判定通过并推动缺陷关闭。整个过程覆盖的是这一个缺陷及其直接关联改动，没有扩展到全站下单流程的回归。
常见误解一：把复测当回归。修复一个缺陷后顺手把整个模块跑一遍，看起来严谨，实际把复测任务变成了没有计划的回归，耗时增加且结论难以归因。正确做法是复测按缺陷范围执行，整体回归由回归计划单独安排。
常见误解二：以修复提交代替验证。开发提交代码或回复“已修复”，并不等于缺陷已验证。修复说明只是复测的输入，结论必须来自按原路径的实际执行。
常见误解三：只看主路径。原步骤跑通就判定通过，忽略了修复点周边的接口和相邻功能。修复带出的新异常往往出现在共享数据或调用关系上，关联影响检查不能省略。
常见误解四：证据缺失也算通过。执行过但没有留下环境、版本和结果记录，后续无法复核，也无法判断问题是否在特定条件下复现。证据记录是通过标准的一部分，不是可选项。
常见问题
缺陷复测和修复验证是两件事吗，需要分别做吗？
两者指向同一环节，不需要拆成两次执行。修复验证强调对修复结果的确认，复测强调按原复现路径重新执行验证，只是表述角度不同。实际执行时，一次按原路径的验证既完成了修复确认，也完成了复测，结论记录在同一份缺陷单中即可。
复测时原缺陷无法复现，可以直接判定通过吗？
不能直接判定通过。原步骤无法复现缺陷，需要先判断原因：是环境或数据差异导致现象未触发，还是修复确实已生效。若属于环境差异，应换到缺陷报告记录的环境与数据下重新执行；若确认修复生效，再按通过标准逐项核对关联影响和证据记录。原因未查清就记为通过，会把未验证的风险留到后续环节。
复测过程中发现的新问题，应该并入原缺陷还是单独记录？
属于新问题的应单独创建缺陷，并关联原缺陷。把两个问题混在一条记录里，会导致状态反复：原缺陷已修复但复测无法关闭，新问题又缺少独立的修复与验证轨迹。单独记录后，原缺陷可按复测结论正常流转，新缺陷进入自己的修复流程。
相邻功能检查要覆盖到什么程度才算充分？
覆盖范围取决于修复点的关联关系，可以从三类关系入手：共享同一数据对象的其他入口、调用同一接口的其他页面、修复涉及的边界条件在相邻场景下的表现。具体覆盖几个入口、证据用截图还是日志，由团队规范确定。需要守住的是关联检查这一环节本身不能省略，覆盖范围应在复测开始前写入缺陷单的复测要点，便于评审人判断是否充分。
复测结论和证据记录应该保存在哪里？
建议与缺陷单保存在同一处，包含执行人、执行时间、环境版本、原路径结果、关联检查结果和证据附件，使他人可以据此复核。ONES 测试管理解决方案覆盖缺陷管理流程，缺陷可关联至迭代，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；复测结论和关联记录可以随缺陷单一起保留，便于后续追溯。团队还可以借助测试报告与项目缺陷分布统计，把复测结果汇总为版本质量的参考。
