缺陷修复验收判定的是复测还是关闭节点

缺陷修复验收判定的是“修复完成、可以进入复测”的准入节点，关闭节点由复测结果决定。也就是说，修复验收通过后缺陷进入待复测状态，复测通过且满足关闭条件才关闭，复测不通过则退回修复。本文按缺陷从提交修复到终结的顺序，说明修复验收的构成条件、复测与关闭的分工，以及两套标准的边界。

要点总览（TL;DR）

• 缺陷修复验收判定的是“修复完成、可以进入复测”的准入节点，关闭节点由复测结果决定。
• 修复验收关注修复提交本身的质量，可用修复说明、可定位的版本或构建号、影响范围与自测说明、初步验证证据、复测交接责任人五项条件核对。
• 复测由验证方按原复现路径执行，通过则进入关闭判定，不通过则退回修复；关闭由具备权限的责任人按关闭条件执行。
• 修复验收标准判定修复提交质量，缺陷关闭标准判定缺陷是否终结，两者使用时机不同，不能互相替代。
• 常见误解是把修复完成当关闭、把修复验收当复测，正确顺序是修复验收通过后复测，复测通过并满足关闭条件才关闭。

缺陷修复验收判定的是哪个节点

缺陷修复验收判定的是进入复测的准入节点。它回答的问题是：开发侧是否已经按约定完成修复，并提交了可验证的版本或环境。判定通过意味着这条缺陷具备复测条件，可以交给验证方执行复测；判定不通过则退回开发继续修复。

三个节点的先后关系可以概括为：修复提交 → 修复验收 → 复测 → 关闭。修复验收位于复测之前，是复测的前置条件；复测是验证动作，确认缺陷现象是否消失、修复是否引入新问题；关闭是验证通过后的终态。把修复验收理解成关闭判定，会让未经验证的修复直接终结缺陷，复测环节就失去了把关作用。

判定通过后的状态流转方向是明确的：缺陷从修复中或待验收状态转入待复测状态，责任人从开发侧转到验证侧，验证方依据修复提交物安排复测。此时缺陷仍然处于打开状态，只是阶段发生了变化。

修复验收标准的构成条件

修复验收标准用于判断一次修复提交是否达到可复测的准入要求。它关注修复提交本身的质量，可以用一组可核对的条件来检查。以下清单可作为验收时的对照依据，团队可按缺陷等级和项目约定增减条目。

• 修复内容与缺陷描述对应：修复说明要指向原缺陷的现象、触发条件和预期结果，说明改了什么、为什么这样改，避免提交与缺陷无关的改动。
• 修复提交物可定位：给出可验证的版本号、分支、构建号或部署环境，让验证方能够准确找到包含该修复的产物，而不是凭口头描述判断。
• 影响范围与自测说明：写明修改涉及的模块、可能受影响的相邻功能，以及开发侧已做的自测内容和结果，便于验证方确定复测的侧重点。
• 复现路径上的初步验证证据：针对原缺陷的复现步骤，提供修复后的验证记录，例如操作截图、日志片段或接口返回结果，证明原现象在开发侧已不再出现。
• 提交复测的责任人与时点：明确由谁提交、提交给谁、期望何时完成复测，让交接有明确对象和时间预期。

这些条件共同构成修复验收的判定依据。条件齐备，验收通过并进入待复测；条件缺失，例如没有可定位的构建号或没有自测说明，验收就应退回补充，而不是直接进入复测。

复测节点做什么、关闭节点做什么

复测与关闭是两个不同的节点，执行角色、输入和判定结果都不同。复测由验证方执行，输入是修复验收通过的提交物，动作是按原缺陷的复现路径重新验证，并检查修复是否影响相邻功能。复测的判定结果有两个分支：通过则进入关闭判定，不通过则退回修复，缺陷回到开发侧继续处理。

关闭节点由具备关闭权限的责任人执行，通常是验证方或测试负责人。关闭的判定条件是复测通过，并且满足团队约定的关闭条件，例如修复已在目标版本中生效、相关文档或记录已更新、没有遗留的关联问题。关闭表示这条缺陷在本次生命周期内终结。

关闭与回归测试的边界需要分清。复测针对的是这一条缺陷及其修复影响范围；回归测试关注的是变更对更大范围功能的影响，通常按版本或迭代组织。一条缺陷可以因复测通过而关闭，回归测试则作为独立的质量活动继续执行，两者不互相替代。

节点	判定对象	主要执行角色	输入	结果
修复验收	修复提交是否达到可复测要求	开发提交，验证方或负责人验收	修复说明、版本或构建号、自测记录	通过进入待复测；不通过退回修复
复测	缺陷现象是否消失、修复是否引入新问题	验证方	待复测缺陷及可验证的修复产物	通过进入关闭判定；不通过退回修复
关闭	缺陷是否终结	验证方或测试负责人	复测通过记录及关闭条件	关闭缺陷；条件不满足则保持打开

修复验收标准与缺陷关闭标准的边界

修复验收标准判定的是修复提交质量，缺陷关闭标准判定的是缺陷是否终结。前者在复测之前使用，检查开发侧交出的修复是否完整、可定位、可验证；后者在复测之后使用，检查验证结果和关闭条件是否满足。两套标准的判定对象不同，使用时机不同，不能互相替代。

不能替代的原因在于，修复提交质量合格并不等于缺陷已经解决。一次修复可能说明清楚、构建可定位、自测也做了，但复测时原现象仍然存在，或者修复引入了新的问题。此时修复验收可以通过，缺陷却不能关闭。反过来，复测通过也需要关闭条件来约束，例如确认修复进入目标版本、关联问题已处理，才能终结缺陷。

与相邻主题的范围也需要区分。回归测试管理关注变更影响范围的验证组织，包括回归范围选择、用例维护和版本质量评估；代码修复教程关注具体实现层面的修改方法。本文讨论的是缺陷从修复提交到验证终结的判定节点与标准边界，不展开回归测试的整体组织，也不涉及代码层面的修复细节。

在实际流转中，缺陷记录和状态交接需要有承载的地方。ONES 测试管理解决方案实现了覆盖全生命周期的缺陷管理，缺陷可关联至迭代；ONES Project 支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并统计缺陷状态分布。团队可以把修复说明、版本信息和复测结论记录在缺陷工作项中，让验收、复测、关闭各环节的判定依据随缺陷一起流转。具体的状态节点命名和流转规则以团队实际配置为准。

一个完整例子与常见误解

以下为演示情景，不对应真实客户或真实缺陷单。某项目在支付流程中发现一条缺陷：订单金额为整数时，优惠券抵扣后显示金额少一分。开发定位为金额计算精度问题，修改后提交修复说明，注明涉及订单结算模块、修复分支和构建号，附上原复现步骤在修复后的操作记录，并说明已自测整数、小数两类金额场景。验证方按修复验收条件核对，确认修复内容与缺陷对应、构建可定位、自测记录完整，验收通过，缺陷转入待复测。

复测时，验证方按原复现路径操作，确认金额显示正确，同时检查了相邻的退款金额展示，未发现异常，复测通过。随后按关闭条件确认修复已进入目标版本、关联的结算用例已更新，缺陷关闭。若复测时原现象仍出现，或发现退款金额受此次修改影响，复测判定不通过，缺陷退回修复，开发补充修改后重新走修复验收。

常见误解有两个。一是把修复完成当成关闭，开发提交修复后直接在系统中关闭缺陷，跳过了复测，导致未经验证的修复进入版本。二是把修复验收当成复测，验收时只核对了提交材料就宣布缺陷已解决，没有按复现路径实际验证。两种做法都会让复测环节失去作用。正确的做法是：修复验收只判定能否进入复测，复测通过并满足关闭条件后才关闭缺陷。

常见问题

修复验收通过后，缺陷状态应该怎么变？

修复验收通过后，缺陷从修复中或待验收状态转入待复测状态，责任人从开发侧转到验证侧。此时缺陷仍然处于打开状态，只是阶段发生了变化，验证方依据修复提交物安排复测。具体的状态节点命名和流转规则以团队实际配置为准。

复测不通过时，缺陷是退回修复还是直接关闭？

复测不通过应退回修复，缺陷回到开发侧继续处理，开发补充修改后重新走修复验收。复测不通过意味着原现象仍存在或修复引入了新问题，此时关闭缺陷会让未解决的问题进入版本，复测环节也就失去了把关作用。

修复验收条件和缺陷关闭条件可以合并成一套检查项吗？

不建议合并。修复验收条件检查的是修复提交是否完整、可定位、可验证，在复测之前使用；关闭条件检查的是复测结果和终结要求，在复测之后使用。一次修复可能材料齐全但复测时原现象仍存在，此时修复验收可以通过，缺陷却不能关闭。两套条件分开检查，才能让每个节点的判定有明确依据。

小团队人手有限，修复验收和复测能否由同一人完成？

可以由同一人执行，但两个动作的判定依据要分开。执行人先按修复验收条件核对提交材料，确认可进入复测；再按原复现路径实际验证，确认现象消失且相邻功能未受影响。把核对材料和实际验证分成两步记录，能避免只看了提交说明就宣布缺陷已解决。

缺陷关闭后还需要做回归测试吗？

需要。复测针对的是这一条缺陷及其修复影响范围，回归测试关注变更对更大范围功能的影响，通常按版本或迭代组织。一条缺陷可以因复测通过而关闭，回归测试作为独立的质量活动继续执行，两者不互相替代。