验收测试计划与系统测试计划分属两个不同的测试层级，差异集中在测试目标、参与方、准入准出条件和缺陷处理方式上。系统测试计划由测试团队主导，验证产品整体是否满足需求规格；验收测试计划由用户或业务方主导，验证系统是否满足业务场景与合同约定。本文用同一组维度对照两类计划，并说明在项目中如何先后衔接、按场景选择。
要点总览（TL;DR）
- 两类计划分属不同层级：系统测试计划验证系统是否满足需求规格，由测试团队主导；验收测试计划验证业务是否可用，由用户或业务方主导。
- 差异最大的两个维度是主导角色和准出判定：系统测试由测试团队按量化门槛判定，验收测试由业务方签字确认。
- 准入门槛前后衔接：系统测试以需求评审通过、可测版本提交为入口；验收测试以系统测试通过、验收标准确认为入口。
- 缺陷处理逻辑不同：系统测试按严重等级推动修复与回归关闭，验收测试区分阻断验收与可带条件通过，形成遗留问题清单。
- 衔接时复用测试报告、缺陷记录和环境说明，重写目标、参与方、验收标准与准出判定；内部交付项目可轻量化验收，有合同验收要求时两类计划都需正式编写。
一张表看清两类测试计划的差异
两类计划最容易混淆的地方，是把它们当成同一份文档的不同叫法。实际上，从计划依据到准出判定，两者的取值几乎逐项不同。下表按七个维度做同口径对照，便于快速建立整体认知。
| 对比维度 | 系统测试计划 | 验收测试计划 |
|---|---|---|
| 测试目标 | 验证系统整体是否满足需求规格与设计说明 | 验证系统是否满足业务场景、合同约定与用户期望 |
| 测试对象范围 | 模块集成后的完整系统，覆盖功能、性能、接口、兼容性等系统级特性 | 面向业务流程的端到端使用，按用户真实操作路径组织 |
| 主导与参与角色 | 测试负责人主导，测试工程师执行，开发修复，产品/需求方确认需求口径 | 用户代表或业务方主导，客户参与判定，测试人员提供支持 |
| 准入条件 | 需求与设计评审通过、测试环境就绪、开发提交可测版本 | 系统测试通过、验收标准与样本数据确认、验收环境就绪 |
| 准出条件 | 用例执行率达到约定值、缺陷收敛、遗留缺陷完成评估、测试报告输出 | 验收用例通过、业务方签字确认、遗留问题形成处理约定 |
| 缺陷处理方式 | 按严重等级分级，指派开发修复，回归验证后关闭 | 区分阻断验收的问题与可带条件通过的问题，形成遗留清单 |
| 计划依据文档 | 需求规格说明书、设计文档、接口文档、测试策略 | 合同或验收标准、业务流程图、用户手册、系统测试报告 |
差异最大的是主导角色和准出判定：系统测试由测试团队判定是否达到质量门槛，验收测试由业务方判定是否愿意接收。最容易混淆的是测试对象范围，两者都覆盖完整系统，但系统测试按特性组织，验收测试按业务场景组织，用例的切分逻辑不同。计划依据文档也常被忽略，验收标准若没有在项目早期确认，验收计划就缺少可判定的依据。
目标与对象：验证需求规格还是验证业务可用
系统测试计划的目标是回答“系统做得对不对”。它以需求规格和设计文档为基准，检查功能是否按定义实现、性能是否达到指标、模块集成后是否出现接口错配。测试对象是集成后的完整系统，用例通常按功能模块和系统特性组织，例如按订单、支付、库存分别设计用例，再补充性能与兼容性场景。
验收测试计划的目标是回答“业务能不能用起来”。它以业务流程和合同约定为基准，检查用户按真实路径操作时能否完成工作。测试对象是端到端的业务链路，用例按场景组织，例如“客户下单到收货的完整流程”“退款申请到账务冲销的完整流程”。同一条业务链路可能横跨多个系统模块，验收用例关注的是链路是否走通、结果是否符合业务预期。
目标差异会直接影响后续工作。系统测试需要准备覆盖各模块的测试数据和环境配置，用例设计偏重边界值、异常输入和接口组合；验收测试需要准备贴近真实业务的样本数据，用例设计偏重典型业务场景和高频操作路径。环境准备上，系统测试环境可以模拟，验收环境通常要求更接近生产配置，数据也更接近真实业务分布。计划编写时若不区分这两类目标，容易出现系统测试用例过多覆盖业务场景、验收用例又回头补测技术细节的情况。
参与方与职责：测试团队主导还是用户业务方主导
系统测试计划的编写者是测试负责人，审批者通常是测试经理与产品/需求方，通过判定由测试团队依据准出条件做出。测试工程师负责用例设计与执行，开发负责缺陷修复，产品/需求方负责确认需求口径和缺陷是否属于需求理解偏差。这条链路在组织内部闭环，决策权清晰。
验收测试计划的编写者通常是业务方或用户代表，测试人员协助整理用例和准备环境；审批者是业务负责人或客户方项目负责人；通过判定由业务方签字确认。测试团队在验收阶段转为支持角色，负责提供测试证据、协助复现问题和解释系统行为，不替业务方做接收决定。
两类计划之间的协作接口是测试证据的移交。系统测试报告、缺陷记录、已知问题清单需要在验收启动前交付给业务方，作为验收用例设计和风险判断的输入。移交内容应包含测试范围与未覆盖范围、遗留缺陷及其影响、环境与数据说明。移交不完整时，验收阶段容易重复测试已覆盖的内容，或者遗漏系统测试中已知的风险点。
准入与准出：两类计划的门槛怎么设
准入门槛决定测试能否开始，准出门槛决定测试能否结束。两类计划的门槛设置方法如下。
系统测试准入条件：
- 需求规格与设计文档完成评审，需求变更已同步到测试范围；
- 测试环境部署完成，测试数据准备就绪；
- 开发提交可测版本，冒烟测试通过，主要功能可运行；
- 接口文档、配置说明等测试依据齐全。
系统测试准出条件：
- 用例执行率达到计划约定值，未执行用例有明确说明；
- 缺陷收敛，严重及以上等级缺陷修复并回归通过；
- 遗留缺陷完成影响评估，形成遗留缺陷清单；
- 系统测试报告输出，包含测试范围、结果统计与风险说明。
验收测试准入条件：
- 系统测试通过并完成报告移交；
- 验收标准逐条确认，验收用例与样本数据准备完成；
- 验收环境就绪，访问权限与账号配置完成；
- 业务方参与人员与时间安排确定。
验收测试准出条件：
- 验收用例按约定执行完成，通过率达到验收标准；
- 业务方对验收结果签字确认；
- 遗留问题形成书面处理约定，明确责任方与处理时限；
- 验收结论归档，作为交付或上线依据。
设置门槛时，系统测试的准出值应在测试计划中量化，例如用例执行率和缺陷密度；验收测试的准出以业务方确认为准，量化指标用于支撑判断而非替代签字。两类门槛都应与项目实际约束匹配，迭代周期短的项目可以降低用例覆盖要求，但不能省略遗留缺陷评估这一环节。
缺陷处理：修复推动与验收判定有何不同
系统测试阶段的缺陷处理以推动修复为目标。缺陷被发现后按严重等级分级，致命和严重缺陷优先指派开发修复，一般和轻微缺陷排入修复计划；修复完成后由测试人员回归验证，验证通过才关闭。缺陷数据用于支撑准出判断：严重缺陷是否清零、缺陷趋势是否收敛、遗留缺陷的影响范围是否可接受。沟通路径是测试与开发之间的日常协作，产品/需求方在需求口径有争议时介入。
验收测试阶段的缺陷处理以判定是否影响接收为目标。发现的问题先判断性质：阻断验收的问题必须修复后重新验收，例如核心业务流程无法走通、关键数据错误；可带条件通过的问题记录为遗留问题，由业务方与交付方约定处理时限和责任人。验收缺陷不追求全部关闭，而是形成清晰的遗留问题清单和处理承诺。沟通路径是业务方与交付方之间的确认，测试人员提供复现步骤和技术说明。
两类缺陷数据的用途也不同。系统测试的缺陷统计反映产品质量趋势，是测试报告的核心内容；验收测试的遗留问题清单反映交付风险，是验收结论的附件。计划编写时应明确缺陷记录字段，至少包含发现阶段、严重等级、影响业务、处理结论，便于两类计划之间追溯同一问题的处理状态。
如何衔接：从系统测试计划走到验收测试计划
两类计划在项目中的先后顺序是：系统测试完成并通过准出后，进入验收测试。衔接不是简单地把系统测试文档改个名字，而是保留证据、重写判定逻辑。具体步骤如下。
- 系统测试准出评审：确认用例执行率、缺陷收敛情况和遗留缺陷清单，输出系统测试报告。
- 移交测试证据：将测试报告、缺陷记录、环境说明、已知问题清单交付业务方，作为验收计划的输入。
- 确认验收标准：业务方逐条确认验收标准与验收用例，明确样本数据来源和验收环境要求。
- 编写验收测试计划：重写目标、参与方、验收标准和准出判定方式，引用系统测试证据但不照搬其准出条件。
- 执行验收并记录问题：按业务场景执行用例，问题按阻断验收与可带条件通过分类记录。
- 形成验收结论：业务方签字确认，遗留问题形成处理约定，验收结论归档。
可以复用的内容包括环境说明、部分端到端用例、缺陷记录和测试报告中的风险说明。需要重写的内容包括测试目标、主导角色、验收标准、准出判定方式和缺陷处理规则。计划模板中建议保留“上游测试证据引用”“验收标准来源”“遗留问题处理约定”三个字段，确保交接物在文档中有明确位置，避免验收阶段重新收集信息。
在工具层面，两类计划的编写、评审和缺陷跟踪可以在同一平台承载。以ONES为例，测试计划可作为工作项关联需求与用例，系统测试报告和缺陷记录在验收阶段直接引用，验收结论与遗留问题在同一流程中流转，减少文档移交时的信息丢失。这类承载方式适合测试与验收由不同角色接力推进的项目，具体配置按团队流程确定。
适配场景与选择建议
两类计划并非每个项目都必须完整执行，选择取决于交付对象和验收要求。
以内部交付为主的项目，例如内部管理系统上线，系统测试计划是必选项，验收测试可以轻量化处理：由业务方按核心业务流程做一轮确认测试，形成简化的验收记录，不必单独编写完整验收计划。此时重点是系统测试准出条件设置到位，避免把未收敛的缺陷带入使用阶段。
有外部客户或合同验收要求的项目，两类计划都需要正式编写。验收标准应在合同或项目启动阶段确认，验收测试计划提前编制，明确参与人员、验收环境和判定方式。系统测试报告是验收准入的必要输入，移交不完整会直接拖延验收进度。
敏捷迭代场景下，两类计划都可以轻量化。系统测试计划按迭代维护测试范围和准出条件，验收测试以迭代评审或演示替代部分正式验收，验收标准嵌入用户故事的完成定义中。需要保留的是缺陷分级规则和遗留问题记录，避免迭代节奏下问题被静默带入下一周期。
常见误用有两种。一种是用系统测试计划替代验收测试，认为系统测试通过就等于业务可用，结果上线后业务方提出大量使用问题；系统测试验证的是需求规格，业务场景的可用性需要业务方参与确认。另一种是验收标准缺失或过于笼统，验收阶段无法判定通过与否，导致验收反复延期；验收标准应在计划阶段逐条明确，并配套可执行的验收用例。
常见问题
系统测试已经全部通过，验收测试还需要重新设计用例吗？
需要重新组织，但不必从零开始。系统测试用例按功能模块和系统特性切分，验收用例按业务流程和用户操作路径切分，两者的组织逻辑不同。可以复用的是端到端链路相关的用例、测试数据和环境说明，需要补充的是贴近真实业务的样本数据、高频操作路径和合同或验收标准中明确要求的场景。直接把系统测试用例当作验收用例执行，容易覆盖技术细节而遗漏业务链路是否走通。
验收测试中发现的问题必须全部修复才能通过验收吗？
取决于问题性质。阻断验收的问题，例如核心业务流程无法走通、关键数据错误，需要修复后重新验收；可带条件通过的问题记录为遗留问题，由业务方与交付方书面约定处理时限和责任人，作为验收结论的附件。验收阶段的目标是形成清晰的接收判定和遗留问题处理承诺，遗留问题清单需要写明影响范围和责任方，避免上线后无人跟进。
迭代周期很短的项目，两类计划可以合并成一份吗？
可以简化，但建议保留两条判定逻辑。系统测试部分按迭代维护测试范围和准出条件，验收部分以迭代评审或演示替代部分正式验收，验收标准嵌入用户故事的完成定义中。合并文档时至少要保留缺陷分级规则、遗留问题记录和验收确认记录三项内容，否则迭代节奏下问题容易被静默带入下一周期，后续追溯困难。
验收标准应该在什么时候确认，由谁确认？
验收标准应在项目启动或合同签订阶段确认，最迟不晚于验收测试计划编写前。确认方是业务负责人或客户方项目负责人，测试人员协助把标准转写成可执行的验收用例。标准需要逐条明确、可判定，例如明确业务流程走通的条件、数据准确性的口径、性能响应的可接受范围。标准缺失或过于笼统时，验收阶段无法判定通过与否，容易反复延期。
系统测试的遗留缺陷如何影响验收测试计划？
系统测试遗留缺陷清单是验收准入的输入之一。编写验收计划时，需要评估每条遗留缺陷是否影响验收范围内的业务流程：影响核心链路的，应在验收前修复或与业务方约定规避方案；不影响验收范围的，在计划中注明并说明影响边界。移交时同时提供缺陷的复现步骤和技术说明，便于业务方判断是否纳入验收关注点，避免验收阶段重复发现同一问题。
