验收测试计划与系统测试计划：准入准出与缺陷处理差异

验收测试计划与系统测试计划都包含准入、准出和缺陷处理，但判断对象不同：系统测试计划判断完整系统是否达到需求覆盖与系统级质量门槛，验收测试计划判断业务场景能否被用户接受、是否具备移交条件。本文按同一组维度对照两类计划的准入条件、准出证据和缺陷处理方式，并说明项目中如何衔接。

要点总览（TL;DR）

• 两类计划的判断对象不同：系统测试计划判断完整系统是否达到需求覆盖与系统级质量门槛，验收测试计划判断业务场景能否被用户接受、是否具备移交条件。
• 准入阶段，系统测试看版本可测、开发自测、环境数据与用例评审；验收测试看系统测试结论、验收环境与真实数据、验收范围确认和业务方排期。
• 准出证据不同：系统测试以用例通过率、需求覆盖、缺陷收敛趋势和遗留缺陷分级评估为依据；验收测试以验收场景通过情况、业务方签署确认和遗留问题接受记录为依据。
• 缺陷分级依据不同：系统测试按严重程度与影响范围分级，由测试回归关闭；验收测试按业务影响与场景阻断程度判定，业务方参与确认是否阻断验收。
• 遗留缺陷处理差异最明显：系统测试阶段经评估可带条件流转，验收阶段需业务方明确接受或约定上线后处置，并记录责任人与时间安排。

两类计划先对齐比较口径

两类计划的核心差别在判断对象。系统测试计划面向完整系统，回答“系统是否按需求正确实现、系统级质量是否达标”；验收测试计划面向业务验收，回答“用户能否在真实业务场景中接受这个版本、是否可以移交上线”。判断对象不同，后续的准入检查、准出证据和缺陷判定都会随之不同。

参与方也有明显差异。系统测试计划以开发和测试团队为主：开发提供可测版本并修复缺陷，测试设计用例、执行测试、回归验证。验收测试计划需要业务方、产品方和用户代表参与：业务方确认验收范围和场景清单，用户代表按真实业务操作验证，产品方协调范围与上线安排。两类计划在同一项目中通常前后衔接：系统测试达到准出条件后，系统测试结论成为验收测试准入的重要输入；验收通过后，版本才具备移交或上线条件。

比较维度	系统测试计划	验收测试计划
目标	验证完整系统满足需求与系统级质量要求	确认业务场景可被用户接受并具备移交条件
判断对象	系统功能、性能、兼容性等系统级质量	真实业务流程、用户场景与业务可接受标准
主要参与方	开发、测试	业务方、产品方、用户代表，测试提供支持
在项目中的位置	系统集成完成后、验收之前	系统测试准出之后、上线移交之前

准入条件对照：进入测试前各查什么

准入解决的是“现在是否具备开始测试的条件”。两类计划的准入检查项都围绕版本、环境、范围和人员准备，但检查的具体内容和判定责任人不同。

系统测试准入重点检查可测性：版本与构建可部署、开发自测完成并有自测记录、测试环境与测试数据就绪、需求与用例经过评审。判定责任通常在测试负责人，开发负责人配合确认自测结论。条件不满足时，常见处理是退回开发补齐自测或修复阻塞问题，推迟测试开始时间，避免在不可测版本上消耗用例执行资源。

验收测试准入重点检查验收前提：系统测试已有明确结论、验收环境与真实或脱敏业务数据准备完成、验收范围与场景清单经业务方确认、业务方参与人员与排期落实。判定责任在业务方与产品方，测试团队提供系统测试结论和环境支持。系统测试未达准出条件时，验收不应启动；验收范围未确认时，先完成范围对齐再排期。

准入维度	系统测试计划	验收测试计划
版本与构建	可部署、可测，开发自测完成	以系统测试通过的版本为验收基线
环境与数据	测试环境、测试数据就绪	验收环境、真实或脱敏业务数据就绪
范围与依据	需求与用例评审通过	验收范围与场景清单经业务方确认
前置结论	无强制前置，依赖开发交付	系统测试结论明确
人员准备	测试人员与排期落实	业务方、用户代表参与排期落实
判定责任	测试负责人判定，开发配合	业务方与产品方判定，测试提供支持
不满足时	退回补齐自测或修复阻塞问题，推迟开始	暂缓验收，先完成系统测试或范围确认

准出条件对照：什么算测试结束

准出解决的是“测试是否可以结束、版本是否可以进入下一环节”。系统测试准出以度量数据和缺陷收敛为依据，验收测试准出以业务确认和遗留问题接受记录为依据。

系统测试准出通常看四类证据：用例执行情况与通过率、需求覆盖情况、缺陷收敛趋势、遗留缺陷的分级评估结论。这些指标的具体阈值由项目风险和质量目标约定，不存在统一数值。未达标时的处理路径包括延长测试周期继续修复回归、与产品方协商裁剪范围、或对遗留缺陷逐条评估后带条件流转。

验收测试准出看验收场景的通过情况、业务方的签署确认、遗留问题的接受记录。验收结论通常以业务确认记录形式留存，而不只是测试报告中的通过率数字。未达标时，处理方式包括补充验收场景重新验证、缩小本次移交范围、或由业务方明确接受遗留问题并约定上线后处置计划。

准出维度	系统测试计划	验收测试计划
核心依据	用例执行与通过率、需求覆盖、缺陷收敛趋势	验收场景通过情况、业务可接受标准达成
遗留问题	按严重程度分级评估，可带条件流转	需业务方逐项确认接受或约定上线后处置
证据形式	测试报告与度量数据	验收结论与业务方确认记录
判定责任	测试负责人提出结论，项目负责人确认	业务方确认，产品方协调移交安排
未达标处理	延期测试、范围裁剪、带条件流转	补充验收、缩小移交范围、明确遗留处置

缺陷处理对照：分级、流转与遗留判定

缺陷处理的差异来自分级依据不同。系统测试阶段按严重程度与影响范围分级，例如阻断、严重、一般、轻微，关注的是功能正确性和系统稳定性；验收测试阶段按业务影响与场景阻断程度判定，关注的是这个缺陷是否让某条业务流程无法完成、是否影响用户正常使用。

流转路径也不同。系统测试缺陷由测试发现后提交，开发修复，测试回归验证后关闭，状态流转围绕“新建—修复—验证—关闭”推进。验收测试缺陷由业务方或用户代表在验收中提出，测试协助复现和定位，业务方参与确认该缺陷是否阻断验收：阻断项必须修复后重新验收，非阻断项进入遗留问题清单，由业务方明确接受或约定上线后处置。

遗留缺陷的处理是两类计划差异最明显的地方。系统测试阶段的遗留缺陷经分级评估后可以带条件流转到验收阶段，条件是影响可控且有后续跟踪安排；验收阶段的遗留缺陷不能仅由测试团队判断，需要业务方明确接受，并记录处置责任人和时间安排。缺陷记录字段上，系统测试侧重严重程度、影响模块、修复版本；验收阶段还需要记录业务影响描述、是否阻断验收、业务确认结论。

缺陷处理维度	系统测试计划	验收测试计划
分级依据	严重程度与影响范围	业务影响与场景阻断程度
提出与修复	测试提出，开发修复，测试回归	业务方提出，开发修复，业务方复验
状态流转	新建—修复—验证—关闭	提出—确认是否阻断—修复—业务复验—接受或遗留
遗留判定	测试与项目负责人评估后可带条件流转	业务方明确接受或约定上线后处置
关键记录字段	严重程度、影响模块、修复版本	业务影响、是否阻断验收、业务确认结论

当缺陷需要在测试与研发之间反复流转、遗留结论需要和版本准出记录对应时，可以用 ONES 测试管理承载这条链路：未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并支持关联至迭代；测试计划与迭代关联，测试报告可自动生成并按业务场景自定义模板，便于在准出评审时引用执行与缺陷数据。验收阶段的业务确认结论仍应由业务方在评审中给出，工具承担记录与追溯。

适配场景与选择建议

两类计划需要配合使用，投入重点取决于项目风险和周期约束。项目周期紧时，系统测试应保证需求覆盖和阻断级缺陷清零，验收测试聚焦核心业务链路和高频用户场景，减少非关键场景的验收范围，但验收范围和裁剪结论需要业务方事先确认。高风险业务场景下，验收测试应加强：增加真实数据验证、补充异常流程和边界场景、邀请实际用户代表参与操作，并把业务方确认环节前置到验收执行过程中，避免最后集中签署。

常见误用有两类。一类是用系统测试准出替代验收确认：系统测试通过率达标只说明系统级质量达到门槛，业务方是否接受仍需独立确认。另一类是在验收阶段重新做系统级回归：验收阶段发现的问题应回到缺陷流程定位修复，大范围系统回归应回到系统测试环节处理，否则验收周期会被拉长且责任边界模糊。

两类计划衔接时可以按以下要点检查：

• 系统测试准出结论是否形成书面记录，并作为验收准入的输入。
• 验收范围与场景清单是否在验收开始前经业务方确认。
• 系统测试遗留缺陷是否逐条标注对验收场景的影响，并明确哪些需要在验收前修复。
• 验收环境与数据是否与业务实际使用条件一致。
• 验收提出的缺陷是否记录业务影响和阻断判定，遗留项是否有业务方接受记录和上线后处置安排。
• 验收结论是否与版本移交或上线决策对应，形成可追溯的记录链。

把两类计划的准入、准出和缺陷记录放在同一条工作流中管理，可以让系统测试结论顺利成为验收输入，也让验收确认和遗留处置有据可查。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，测试报告自动生成并支持自定义模板，适合承载这类需要跨角色交接的测试过程记录。

常见问题

系统测试准出通过后，验收测试是否可以直接开始？

系统测试准出通过是验收测试准入的重要前提，但验收启动还需要满足其他条件：验收环境与真实或脱敏业务数据准备完成、验收范围与场景清单经业务方确认、业务方参与人员与排期落实。系统测试结论明确只解决了“版本是否达到系统级质量门槛”，验收范围未对齐或业务方未排期时，仍应先完成这些准备再启动验收。

验收阶段发现的缺陷，应该回到系统测试流程处理吗？

取决于缺陷性质。验收阶段发现的缺陷应先按业务影响判定是否阻断验收：阻断项回到缺陷流程定位修复，修复后由业务方复验；非阻断项进入遗留问题清单，由业务方确认接受或约定上线后处置。如果缺陷暴露出大范围的系统级问题，需要重新做系统级回归，应回到系统测试环节处理，避免验收周期被拉长、责任边界模糊。

遗留缺陷在两类计划中的接受方式有什么不同？

系统测试阶段的遗留缺陷由测试与项目负责人按严重程度分级评估，影响可控且有后续跟踪安排时可以带条件流转到验收阶段。验收阶段的遗留缺陷需要业务方逐项确认接受，并记录处置责任人和上线后处置时间安排，测试团队的意见作为参考，最终接受结论由业务方给出。

项目周期紧时，两类计划的投入应该如何分配？

系统测试优先保证需求覆盖和阻断级缺陷清零，验收测试聚焦核心业务链路和高频用户场景，可以缩减非关键场景的验收范围，但范围裁剪结论需要业务方事先确认。高风险业务场景下反而应加强验收测试：增加真实数据验证、补充异常流程和边界场景、邀请实际用户代表参与操作，并把业务方确认环节前置到验收执行过程中。

两类计划的准入、准出和缺陷记录如何形成可追溯的记录链？

关键是让系统测试结论成为验收准入的书面输入，并让验收确认与版本移交决策对应。可以用 ONES 测试管理承载这条链路：未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转并支持关联至迭代；测试计划与迭代关联，测试报告可自动生成并按业务场景自定义模板，便于在准出评审时引用执行与缺陷数据。验收阶段的业务确认结论仍由业务方在评审中给出，工具承担记录与追溯。