缺陷复测要回答的问题很具体：开发说修好了，测试怎样确认它真的修好，并把结论留在缺陷单里。完整动作按“修复提交—复测准备—按原路径验证—影响面抽查—结论回写—关闭或退回”推进。复测只覆盖这个缺陷及其改动影响面，变更后的整体回归另按回归测试管理。下面给出可直接照做的五步流程、角色交付物和完成检查项。
要点总览（TL;DR）
- 复测启动前先确认缺陷单信息完整：复现步骤、环境与版本、预期与实际结果、严重级别，以及开发补充的根因、改动范围与自测结论；信息缺失时退回补充。
- 复测按五步推进：核对修复版本进入待测环境、按原复现步骤重跑、对改动范围做影响面抽查、判定并回写结论、关闭或退回。
- 开发交付修复说明与自测记录，测试产出复测执行记录与验证证据，缺陷负责人把关状态流转并跟踪积压。
- 结论分通过、不通过、阻塞三类，均需附证据回写缺陷单；退回时写明复现路径、实际结果、环境版本和证据。
- 复测只验证单个缺陷及其影响面，变更后的整体回归另按回归测试管理，两者记录与责任人分开。
复测前要拿到哪些信息
复测能否开始，取决于缺陷单和修复说明是否足以支撑一次可重复的验证。信息不全时直接重跑，常见结果是测出一个与修复无关的现象，或者无法判断通过与否。建议在缺陷单中固定以下字段，并明确各自的责任人。
| 信息类别 | 具体字段 | 责任人 | 缺失时的处理 |
|---|---|---|---|
| 缺陷描述 | 复现步骤、环境与版本、预期结果、实际结果、严重级别 | 缺陷提交人（通常为测试） | 退回提交人补充，暂不进入复测 |
| 修复说明 | 根因、改动范围、影响模块、自测结论 | 开发 | 退回开发补充，修复说明缺失不放行 |
| 复测环境 | 待测版本号、环境地址、所需测试数据 | 开发交付，测试确认 | 环境与缺陷环境不一致时，在缺陷单中写明差异及对结论的影响 |
复现步骤要写到他人可照着操作的程度：入口页面、操作顺序、输入数据、观察点。环境与版本需要精确到可定位的构建，避免“测试环境最新版”这类无法回溯的描述。严重级别决定复测的优先级和影响面抽查的深度，高危缺陷应扩大抽查范围。
修复说明是复测准备中最容易被省略的一项。根因说明改了什么逻辑，改动范围说明涉及哪些模块、接口或配置，自测结论说明开发已做过哪些验证。测试据此判断影响面抽查应覆盖哪些相邻功能，而不是只把原步骤跑一遍。复测环境原则上与缺陷发生环境保持一致；确实存在差异时，例如数据版本或依赖服务不同，应在缺陷单中记录差异，并说明该差异是否影响结论成立。
缺陷复测的操作步骤
五步流程的每一步都有明确的输入、动作、输出和完成标志。按顺序推进，可以避免“测了但说不清结论”的情况。
第一步：确认修复版本已进入待测环境
输入是开发提交的修复说明和待测版本号。动作是核对缺陷单中记录的修复版本与待测环境实际部署的版本是否一致，确认环境可用、所需数据就绪。输出是版本核对记录。完成标志是缺陷单中能查到“修复版本—待测环境—部署时间”的对应关系。常见卡点是开发口头告知已修复但未更新缺陷单，或环境部署了更新版本导致无法确认被测对象。
第二步：按原复现步骤重跑
输入是缺陷单中的原始复现步骤、预期结果和实际结果。动作是严格按原路径操作，逐步记录每一步的实际表现，包括与预期一致和不一致的地方。输出是复测执行记录，附截图或日志。完成标志是原复现步骤全部执行完毕，且实际结果有明确记录。常见卡点是测试凭记忆简化步骤，跳过了触发缺陷的关键前置条件，导致缺陷“消失”但无法确认已修复。
第三步：对改动范围做影响面抽查
输入是开发提供的改动范围和影响模块。动作是围绕改动点抽查相邻功能与边界条件，例如同一接口的其他调用方、相关配置项、异常输入和空值场景。抽查项应写入缺陷单或复测记录，便于复核。输出是影响面抽查结果。完成标志是改动范围内列出的模块均有抽查结论。常见卡点是只验证原步骤通过就结束，遗漏了修复引入的相邻功能异常。
第四步：判定结论并回写缺陷单
输入是前两步的执行记录和抽查结果。动作是给出三类结论之一：通过、不通过、阻塞。通过需附验证证据；不通过需写明实际结果与预期的差异及复现信息；阻塞需说明阻塞原因，例如环境不可用或依赖未就绪。输出是更新后的缺陷单。完成标志是缺陷单中的结论字段、证据和说明均已填写。常见卡点是结论只写在聊天记录里，缺陷单状态未同步。
第五步：关闭或退回
输入是已回写结论的缺陷单。动作是：通过则关闭缺陷，记录关闭时间和验证人；不通过则退回开发，附复现步骤、实际结果和证据，并更新状态为待修复或重新打开；阻塞则挂起并注明解除条件。输出是状态流转完成的缺陷单。完成标志是缺陷单状态与结论一致，且退回时开发能依据所附信息直接复现。常见卡点是退回时只写“还有问题”，缺少复现信息，导致来回沟通。
缺陷单的状态流转和验证记录需要开发、测试与缺陷负责人围绕同一份记录协作。在 ONES 测试管理中，未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷也可关联至迭代，便于把复测结论和证据留在同一工作项上，减少结论散落在聊天工具里的情况。状态字段如何设置、流转规则如何约定，仍需团队按自身流程确定。
角色分工与交付物
复测涉及三类角色，职责边界清晰可以减少“谁来测、谁来关”的扯皮。下表按角色列出动作和交付物。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 开发 | 定位根因、控制改动范围、完成自测、交付可测版本 | 修复说明（根因、改动范围、影响模块）、自测记录、待测版本号 |
| 测试 | 核对版本与环境、按原路径重跑、影响面抽查、判定结论 | 复测执行记录、验证截图或日志、缺陷单结论回写 |
| 缺陷管理者/负责人 | 把关状态流转、归类退回原因、跟踪积压缺陷 | 状态流转记录、退回原因分类、积压跟踪清单 |
开发的责任在交付可测版本时并未结束：修复说明要能让测试看懂改了什么、可能影响哪里。测试的责任是给出可复核的结论，证据要能支撑“通过”或“不通过”的判断。缺陷管理者的价值在于守住状态规则，例如修复说明缺失的缺陷不进入复测、退回必须附复现信息，并定期查看长期停留在待复测状态的缺陷，识别是环境问题还是责任不清。
一个完整的复测示例
以下为演示情景，用于说明字段如何填写和流转，不代表真实项目数据。
缺陷背景：某后台系统的订单导出功能，在筛选条件包含“已取消”状态时，导出的文件缺少对应记录。复现步骤为：进入订单列表，选择状态“已取消”，点击导出，打开文件核对记录数。预期导出记录数与列表一致，实际导出为空。严重级别为高。
开发修复说明：根因是导出查询未拼接状态筛选参数，改动范围为导出服务的查询构造逻辑，影响模块包括订单导出和报表导出两个入口，自测结论为两种筛选组合下导出记录数均与列表一致。
测试复测动作：核对待测版本号与环境一致后，按原步骤重跑，导出文件记录数与列表一致，附文件截图。影响面抽查覆盖：报表导出入口在相同筛选条件下的结果、无筛选条件时的全量导出、筛选结果为空时的导出行为。三项抽查均正常。
结论回写与关闭：缺陷单结论填“通过”，附复测记录和截图，状态更新为已关闭，记录验证人和关闭时间。
未通过时的退回写法：“按原步骤复测，筛选‘已取消’后导出记录数仍为 0，与列表 12 条不一致。环境为待测版本 V2.3.1，操作录屏和导出文件见附件。请确认状态参数是否在报表导出入口同样生效。”这样的退回信息包含复现路径、实际结果、环境版本和证据，开发可直接据此排查。
复测完成检查与常见误区
判断一次复测是否做到位，可以逐项核对以下检查项。全部满足，才适合把缺陷标记为关闭。
- 原复现步骤已按原路径完整执行，实际结果有记录；
- 改动范围内的影响模块已完成抽查，抽查项有结论；
- 验证证据（截图、日志、导出文件等）已附在缺陷单中；
- 缺陷单结论、状态、验证人和时间已更新；
- 退回时附有可复现的信息，开发无需再次询问。
复测环节的典型偏差有三类。第一类是只测原步骤、不看影响面，修复本身通过但相邻功能被改坏，问题延后暴露。第二类是修复说明缺失仍放行复测，测试不知道改了什么，抽查无从下手，结论的可信度下降。第三类是把复测与回归混为一谈，用一次复测代替版本回归，或者反过来要求复测覆盖全部功能，导致复测周期失控。复测验证单个缺陷是否修好，回归测试验证变更是否引入新的整体问题，两者的记录、范围和责任人应分开管理。
退回与重开的判定条件需要区分：复测发现原缺陷仍可复现，退回开发继续修复；复测通过后在同一影响面发现新问题，按新缺陷提交并关联原缺陷；缺陷关闭后因环境或数据变化再次出现，重新打开并注明复现条件。无论哪种情况，复测记录都应保留在缺陷单中，包含执行时间、执行人、环境版本和证据，保证后续追溯时能还原当时的验证过程。
常见问题
复测时原缺陷无法复现，但开发也没给出修复说明，能直接关闭吗？
不建议直接关闭。原缺陷无法复现有两种可能：修复确实生效，或者复现条件发生了变化（数据、环境、版本不同）。缺少修复说明时，测试无法判断属于哪种情况，也无法确定影响面抽查的范围。
处理方式是退回开发补充根因、改动范围和自测结论，再按原复现步骤重跑一次，并在缺陷单中记录本次执行的环境版本与数据条件。确认原路径通过且影响面抽查有结论后，再关闭缺陷。
影响面抽查要覆盖多大范围，有没有可参照的边界？
抽查范围以开发提供的改动范围和影响模块为起点，而不是以缺陷本身的复现路径为边界。常见做法是覆盖三类对象：改动点所在功能的相邻操作、同一接口或服务的其他调用入口、以及异常输入和空值等边界条件。
严重级别高的缺陷应扩大抽查范围。抽查项写入缺陷单或复测记录，每项给出结论，便于后续复核。范围大小由改动影响面决定，团队可在缺陷单中约定抽查项清单。
复测通过后，同一影响面又发现新问题，应该重开原缺陷还是提新缺陷？
按新缺陷提交，并关联原缺陷。原缺陷的验证结论是“该问题已修复”，这个结论成立；新问题是修复过程或相邻功能暴露出的另一处异常，有独立的复现步骤和预期结果，单独跟踪更利于定位和统计。
如果缺陷关闭后因环境或数据变化再次出现同一现象，则重新打开原缺陷，并注明复现条件的变化。两种情况都要把复测记录保留在缺陷单中，包含执行时间、执行人、环境版本和证据。
缺陷单长期停在待复测状态，通常是什么原因，怎么处理？
常见原因有三类：修复说明缺失导致测试无法开始、待测环境或数据未就绪、责任人对状态流转规则理解不一致。缺陷负责人可以定期查看停留时间较长的待复测缺陷，逐条确认卡在哪一环。
处理上可以约定两条规则：修复说明不完整的缺陷不进入复测，由开发补充；环境阻塞需在缺陷单中注明解除条件，避免状态长期悬空。退回原因按类别归集后，也能看出是流程问题还是协作问题。
小团队人手有限，复测记录可以简化到什么程度？
可以简化形式，保留可追溯的核心信息：执行时间、执行人、被测版本、原路径执行结果、影响面抽查项及结论、证据（截图或日志）。这些信息足以支撑“通过”或“不通过”的判断，也便于后续追溯。
不建议省略的是退回时的复现信息。退回只写“还有问题”，开发需要反复询问，来回沟通的成本通常高于一次写清复现路径和实际结果。记录承载在缺陷单中即可，无需另建文档。
