缺陷复测是在缺陷修复后，围绕该缺陷及其直接影响面重新执行验证，确认原问题已消除、修复未引入新的同类问题。界定复测时有两个关键问题：测到哪里为止，以及达到什么结果才算通过。本文按“验证对象—范围边界—通过条件—相邻概念—实际判定”的顺序展开，帮助测试与研发对同一个缺陷的关闭判断形成一致口径。
要点总览（TL;DR）
- 缺陷复测针对已标记修复的单个缺陷，验证原问题消除、修复未引入新问题，并留下可追溯的验证记录。
- 复测范围分三层：原复现步骤、关联用例和受影响功能路径为必测；同模块相邻场景按修复波及面选测；与本次修复无关的整体回归不纳入复测。
- 通过标准需四项同时成立：原步骤在约定环境不再复现、关联用例与受影响功能验证通过、未引入新的阻断或严重问题、验证记录完整。
- 修复验证、缺陷复测、回归测试范围逐层扩大：前者看修复动作是否生效，复测看单个缺陷能否关闭，回归看变更后整体功能是否受波及。
- 复测通过只代表该缺陷可以关闭，版本能否交付仍需回归测试与整体质量评估支撑。
缺陷复测到底验证什么
缺陷复测的对象是已经标记为修复的缺陷。开发完成修改并提交待验证后，测试人员依据缺陷记录中的复现步骤、环境信息和预期结果重新执行，判断该缺陷是否仍然存在。复测的结论直接决定这个缺陷能否关闭，因此它针对的是单个缺陷的关闭判断，而非对整个版本质量的重新评估。
复测包含三项验证目标。第一，原问题消除：按原复现步骤在约定环境中执行，缺陷现象不再出现。第二，修复未带来新问题：修复所触及的功能路径和关联场景仍然正常，没有出现阻断或严重级别的新问题。第三，结论可追溯：复测使用的环境、版本、执行人、执行结果被完整记录，后续任何人回看这条缺陷时，都能还原当时的判断依据。
这三项目标共同构成复测的完整含义。只确认原步骤不复现，属于验证了一半；只记录“已复测通过”而不留环境和版本信息，则结论无法复核。复测的价值在于给出一个有证据支撑的关闭决定。
复测范围的边界：从缺陷本身到受影响功能
复测范围由缺陷影响分析决定，起点是缺陷本身，向外延伸到修复动作可能触及的功能路径。范围随缺陷的影响面变化，不按模块全量铺开。把范围划分为三层，可以让不同缺陷采用不同的验证深度。
| 层级 | 包含内容 | 适用说明 |
|---|---|---|
| 必测层 | 原复现步骤、关联用例、受影响功能路径 | 每个缺陷复测都必须执行，缺一项不能判定通过 |
| 可选层 | 同模块相邻场景、同类缺陷的共性检查 | 根据修复方式与影响分析决定是否纳入，例如修复涉及公共组件时扩展检查 |
| 不纳入层 | 与本次修复无关的整体回归 | 由回归测试环节承担，不放进单个缺陷的复测范围 |
必测层中的“受影响功能路径”需要结合修复内容判断。例如修复涉及登录校验逻辑，那么登录成功、登录失败、异常输入等共用该逻辑的路径都应纳入；修复只改动某个页面的文案展示，受影响路径就集中在该页面的展示与相关交互上。关联用例指缺陷记录或测试用例库中与该功能直接对应的用例，它们提供了标准化的验证步骤和预期结果。
可选层的判断依据是修复的波及面。修复改动了被多处调用的公共方法、公共组件或配置项时，同模块相邻场景和同类缺陷的共性检查值得纳入；修复局限于独立分支的局部逻辑时，可选层可以收窄。可选层的作用是提前发现“修好一处、带坏另一处”的情况，是否执行应在复测前说明理由，而不是凭感觉增减。
不纳入层需要明确说出来，避免复测被误解为回归。与本次修复无关的模块、功能和历史缺陷，属于变更后的整体回归测试范围。把整体回归塞进单个缺陷的复测，会拉长关闭周期，也会让复测结论承担它无法承担的责任。
通过标准由哪些条件共同构成
复测通过是多项条件同时成立的结果，任何一项不满足都应判定为不通过或待补充验证。把标准拆成可逐项核对的条件，可以减少“看起来没问题就关了”的随意判断。
| 序号 | 通过条件 | 核对要点 |
|---|---|---|
| 1 | 原复现步骤不再复现 | 在缺陷记录约定的环境或双方确认的等效环境中，按原步骤执行，缺陷现象未出现 |
| 2 | 关联用例与受影响功能验证通过 | 必测层中的关联用例执行通过，受影响功能路径表现符合预期 |
| 3 | 修复未引入新的阻断或严重问题 | 复测过程中发现的新问题按严重程度评估，出现阻断或严重级别问题时不能判定通过 |
| 4 | 验证记录完整 | 记录包含复测环境、版本、执行人、执行时间与结果，可支撑后续复核 |
条件1中的“约定环境”需要提前说清。缺陷在测试环境复现、在预发布环境修复时，复测应在能够代表目标运行状态的环境执行；环境无法完全一致时，应记录差异并评估差异是否影响结论，不能默认等效。
条件3处理的是复测过程中出现的新情况。新问题如果属于阻断或严重级别，说明修复带来了不可接受的影响，应判定不通过并退回修复；如果属于轻微问题，可以记录为新缺陷单独跟踪，同时说明它不影响本次复测结论的理由。这个区分需要在复测记录中写明，便于评审时判断。
条件4常被忽略，却是复测结论可追溯的基础。一条只写着“已验证”的缺陷，在版本迭代、人员交接或质量复盘时无法提供有效信息。把环境、版本、执行人和结果写入缺陷工作项，复测结论才具备被复核的条件。在 ONES 中，缺陷可作为工作项关联至迭代，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，复测时补充的验证信息随缺陷记录一并保留，团队成员围绕同一条缺陷协作，减少口头交接造成的信息丢失。
复测、修复验证与回归测试的区别
这三个概念经常被混用，实际对象和范围并不相同。修复验证关注修复动作本身是否按预期生效，缺陷复测关注单个缺陷能否关闭，回归测试关注变更后整体功能是否受波及。三者是递进关系，范围逐层扩大。
| 概念 | 验证对象 | 范围 | 先后关系 |
|---|---|---|---|
| 修复验证 | 修复动作是否生效 | 聚焦修改点及其直接结果，确认改动按预期起作用 | 最先发生，是复测的前提 |
| 缺陷复测 | 单个缺陷能否关闭 | 原复现步骤、关联用例、受影响功能路径 | 在修复验证之后，给出缺陷关闭判断 |
| 回归测试 | 变更后整体功能是否受波及 | 与变更相关的功能集合及必要的整体范围 | 在复测之后或并行，面向版本质量 |
修复验证可以由开发自测完成，也可以由测试在修改点附近快速确认，它的结论是“改对了”。缺陷复测在此基础上前进一步，把原问题、关联用例和受影响功能一起验证，结论是“这个缺陷可以关了”。回归测试的范围更大，关注本次变更所在版本的整体功能是否稳定，结论是“这个版本可以继续交付”。
三者的顺序并非绝对串行，但逻辑上逐层递进。修复验证不通过，复测没有意义；复测不通过，缺陷应退回修复而不是进入回归结论；回归测试发现问题，通常作为新缺陷进入下一轮修复与复测。把三者混为一谈，容易出现两种偏差：用修复验证代替复测，遗漏受影响功能；用复测代替回归，让单个缺陷的关闭结论承担版本质量判断。
一个复测判定示例与常见误解
以下示例用于演示范围与通过标准如何落地，场景为说明性构造。
某系统登录页的图形验证码在连续输错三次后不再刷新，用户无法继续登录。缺陷记录中写明复现步骤：连续三次输入错误验证码，观察验证码是否刷新；预期结果为每次输错后验证码自动刷新。开发修改了验证码刷新逻辑并标记修复。
复测时，必测层包括：按原步骤连续三次输错验证码，确认每次均刷新；执行关联的登录用例，覆盖正确验证码登录、错误验证码提示、刷新后重新输入等场景；检查受影响功能路径，包括验证码刷新与登录提交之间的状态传递、连续失败后的账号锁定提示是否正常。可选层视修复方式决定：如果修改涉及公共的会话状态处理，应补充检查其他依赖会话状态的页面；如果修改仅在登录页局部，可选层可以收窄。与登录无关的订单、支付等功能不纳入本次复测。
判定时逐项核对：原步骤不再复现；关联用例与受影响路径通过；复测中未出现阻断或严重问题；记录中写明复测环境、版本、执行人和结果。四项全部满足，判定通过，缺陷可以关闭。若复测中发现刷新后登录提交偶发失败，属于受影响功能路径上的新问题，应按严重程度评估后再决定是否通过。
常见误解有三条。其一，把复测通过当成整个版本验证完成。复测只回答单个缺陷能否关闭，版本是否可交付要看回归测试与整体质量评估。其二，复测只跑原步骤，忽略受影响功能。原步骤不复现只是条件之一，修复触及的路径同样需要验证，否则容易在关闭缺陷后暴露新的关联问题。其三，环境不一致时直接判定通过。复测环境与缺陷约定环境存在差异时，应记录差异并评估其是否影响结论；差异足以改变验证结果时，应调整环境重新执行，而不是凭原步骤“看起来正常”下结论。
把范围三层和通过条件四项固定为团队共用的核对口径，复测结论就能在测试、研发和版本评审之间保持一致。缺陷状态流转与验证记录承载在同一条工作项上，复测的环境、版本、执行人和结果随缺陷一起沉淀，后续复盘和交接都有据可查。
常见问题
缺陷在测试环境复现、在预发布环境修复，复测应该在哪个环境执行？
优先选择能够代表目标运行状态的环境。如果缺陷在测试环境复现、修复提交在预发布环境，复测应在预发布或与目标运行状态一致的环境执行，并按原复现步骤验证。
环境无法完全一致时，需要把差异记录在缺陷工作项中，评估差异是否会影响验证结论。差异足以改变执行结果时，应调整环境重新执行，不能凭原步骤“看起来正常”直接判定通过。
复测过程中发现一个轻微的新问题，这个缺陷还能判定通过吗？
可以判定通过，前提是新问题不属于阻断或严重级别，并且已在复测记录中说明它不影响本次结论的理由。
轻微问题应作为新缺陷单独创建并跟踪，与原缺陷的关闭判断分开处理。若新问题属于阻断或严重级别，说明修复带来了不可接受的影响，应判定不通过并退回修复。
修复只改了一行代码，复测还需要跑关联用例和受影响功能吗？
需要。修改量小不代表影响面小，关键看这行代码被哪些路径调用。如果改动位于公共方法、公共组件或配置项中，受影响功能路径可能比修改本身大得多。
复测前应结合修复内容做影响分析，确定必测层的关联用例和受影响路径。可选层是否执行，应在复测前说明理由，例如改动涉及公共组件时扩展检查同模块相邻场景。
复测通过后，缺陷可以直接关闭，还需要等回归测试结果吗？
单个缺陷的关闭判断以复测结论为准，四项通过条件全部满足即可关闭该缺陷。回归测试面向的是变更后整体功能是否受波及，结论对象是版本而非单个缺陷。
两者可以并行推进，但用途不同。用复测结论代替版本质量判断，会让单个缺陷承担它无法承担的责任；反过来，等整体回归完成才关闭缺陷，也会拉长缺陷流转周期。
团队如何让复测结论在人员交接后仍然可复核？
把复测环境、版本、执行人、执行时间和结果写入缺陷工作项，让结论与缺陷记录绑定在一起。只写“已验证”的缺陷，在版本迭代或质量复盘时无法还原判断依据。
在 ONES 中，缺陷可作为工作项关联至迭代，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，复测补充的验证信息随缺陷记录一并保留，团队成员围绕同一条缺陷协作。
