验收测试计划与系统测试计划的区别

2026年11月6日

验收测试计划与系统测试计划属于不同层级的测试规划：系统测试计划面向产品整体，验证系统是否满足需求规格；验收测试计划面向用户与业务方，验证系统是否满足业务验收条件。两者的差异集中在目标与判断依据、参与方与签字责任、准入准出条件、缺陷处理逻辑四处。下面用统一口径逐项对照，并给出可写入计划的条款写法与选择建议。

Table of Contents

要点总览（TL;DR）

系统测试计划验证系统是否满足需求规格，由测试团队主导；验收测试计划验证业务方是否接收，由客户或业务代表主导。
系统测试准入看开发自测与版本可部署，准出看用例执行与缺陷收敛；验收准入看系统测试通过，准出看验收用例通过与签字确认。
系统测试阶段缺陷以修复排期为主；验收阶段以是否阻断业务使用判定，遗留问题需书面确认。
内部迭代项目可简化验收计划，合同交付项目两份计划都应完整编制，门槛分开设定。
用验收计划替代系统测试计划会让缺陷集中暴露在验收阶段，签字确认失去意义。

同口径差异对照：目标、参与方、准入准出与缺陷处理

先把两份计划放在同一张表里，用五个维度对齐。读者可以据此判断自己手上的文档属于哪一类，以及缺了哪部分内容。

维度	系统测试计划	验收测试计划
验证目标	验证系统是否满足需求规格与设计文档，回答“系统做得对不对”	验证系统是否满足业务验收条件，回答“业务方要不要接收”
主导与配合角色	测试团队主导，开发与产品配合	客户或业务代表主导，供方测试与实施配合
准入条件	开发自测完成、版本可部署、测试环境就绪	系统测试通过、具备可验收版本与验收环境
准出条件	系统测试用例执行完毕，遗留缺陷收敛到约定标准	验收用例通过、关键缺陷关闭，验收方签字确认
缺陷处理	以修复为主，按严重程度与影响面排期	以是否阻断业务使用判定，遗留问题形成书面确认

逐维度看：目标维度决定用例从哪里来；参与方维度决定谁在计划上签字；准入准出维度决定两份计划如何衔接；缺陷维度决定同一张缺陷单在两个阶段被如何对待。五个维度中，目标是最上游的差异，其余四项都由它派生。

目标与验证对象：验证系统对不对，还是验证业务要不要

系统测试计划的判断依据是需求规格说明书、设计文档和接口约定。测试人员把需求条目拆成测试点，再组织成用例，覆盖功能、性能、兼容性、异常处理等范围。用例来源是文档，覆盖范围以需求条目为边界，需求写了什么就验什么，需求没写的通常不在系统测试的判定范围内。

验收测试计划的判断依据是业务场景、合同条款或双方约定的验收标准。用例来源是真实业务流程和验收条款，覆盖范围以“业务能否正常开展”为边界。一个功能在系统测试中全部用例通过，仍可能在验收阶段因为操作路径不符合业务习惯、数据口径与合同约定不一致而被判不通过。

这个差别带来两个实际后果。其一，两份计划的用例不能互相复制：系统测试用例按功能模块组织，验收用例按业务场景串联多个模块。其二，验收标准需要在项目早期就写清楚，如果合同或验收条款只写了“满足业务需求”这类笼统表述，验收阶段就容易出现判定分歧。可行的做法是在验收计划中把每条验收标准写成可观察的结果，例如“订单从提交到出库的全流程在测试数据下可完整走通，各环节状态与业务规则一致”。

参与方与职责分工：谁主导、谁配合、谁签字

系统测试计划由测试团队主导编制和执行，开发团队负责修复缺陷并提供版本说明，产品经理负责确认需求理解是否准确、判定争议需求的处理方式。计划文档中的责任人字段通常写测试负责人、各模块测试执行人、缺陷修复对接的开发负责人。

验收测试计划由客户或业务代表主导，供方测试团队提供用例支持与执行配合，实施或交付团队负责环境、数据和操作培训。签字确认的责任在验收方：验收结论、遗留问题清单、上线许可都由验收方出具书面意见。供方可以提出建议，但不能代替验收方做接收决定。

写计划时可以把职责落到三类字段：编制人、执行人、确认人。系统测试计划的确认人是测试负责人与产品负责人；验收测试计划的确认人是客户或业务代表。问题受理也要写清归属：系统测试阶段缺陷由开发团队受理并给出修复排期；验收阶段发现的问题先由供方判定属于缺陷还是需求变更，再由验收方决定是否阻断上线。

准入与准出条件：两份计划各自的门槛怎么定

门槛要写成可核验的条件，避免“基本完成”“大致通过”这类表述。下面两组清单可以直接改写进计划文档，量化口径按项目实际约定调整。

系统测试计划

准入：开发自测完成并提交自测记录；版本可部署，构建产物与版本号对应；测试环境、测试数据、依赖服务就绪；需求规格与变更说明已同步给测试团队。
准出：计划内用例执行率达到约定值（示例：100%）；用例通过率达到约定值（示例：不低于95%）；遗留缺陷按严重程度收敛，示例口径为“致命与严重级缺陷清零，一般级遗留不超过约定数量且有修复计划”；测试报告完成并经评审。

验收测试计划

准入：系统测试已按准出条件通过并出具测试报告；具备可验收版本与独立验收环境；验收用例与验收标准已由双方确认；验收方人员与时间已排定。
准出：验收用例按约定执行完成并通过；关键缺陷关闭，非关键遗留问题形成书面清单并明确处理方式；验收方签署验收结论；如需上线，上线许可一并确认。

两份门槛的衔接关系是串联而非并列：系统测试准出是验收准入的前置条件。实际项目中可以把系统测试报告作为验收准入的附件，验收计划中直接引用该报告的结论，避免重复判定。

缺陷处理差异：修复排期与上线判定

系统测试阶段的目标是让产品达到可交付状态，缺陷处理以修复为主。缺陷按严重程度和影响面排序：致命与严重级优先修复并回归验证，一般级按迭代排期，轻微级可合并处理或延后。计划中记录缺陷编号、所属模块、严重程度、发现版本、修复版本、回归结果等字段，关注的是缺陷是否被修掉。

验收阶段的缺陷处理目标变成判定是否阻断上线。同一个一般级缺陷，在系统测试中可能排进下个迭代，在验收阶段则要由验收方判断它是否影响业务开展：影响核心业务流程的，作为阻断项要求修复；不影响使用的，列入遗留清单，由验收方书面确认接受，风险由接收方承担。计划中除缺陷基本信息外，还需要记录验收方判定结论、确认人、确认日期。

遗留问题的确认方式建议固定为一份清单：逐条写明问题描述、影响范围、临时规避方式、计划修复时间、确认人签字。口头同意在后续争议中难以追溯，书面清单既是验收结论的组成部分，也是上线后问题跟踪的输入。

适配场景与选择建议：什么时候写哪份计划

内部迭代项目通常以系统测试计划为主，验收环节由产品负责人和业务方代表做轻量确认，验收计划可以简化为一份确认清单。合同交付项目、政企采购项目、需要第三方验收的项目，两份计划都要完整编制，验收计划还要与合同条款逐条对应。涉及多个业务部门共同使用的系统，验收计划需要按部门拆分验收场景和确认人。

两份计划可以并行编制，但门槛必须分开。常见做法是在项目启动阶段同时起草，系统测试计划随需求变更滚动更新，验收计划在系统测试准出前定稿并由双方确认。并行编制的好处是验收标准提前暴露，测试用例设计时就能兼顾业务场景；风险在于如果两份计划共用一套准出条件，验收就退化成第二轮系统测试，业务方真正关心的问题反而没有被验证。

用验收计划替代系统测试计划是更常见的误用。缺少系统测试这一层，缺陷会在验收阶段集中暴露，修复与回归挤占验收时间，验收方被迫在带缺陷的版本上做接收判断，签字确认失去意义。反过来，只做系统测试不做验收计划，则在合同交付场景中缺少接收依据，上线后的责任边界不清。

计划编制、用例执行和缺陷流转需要有承载的地方。ONES 测试管理支持测试计划的规划和执行，并可多维度概览全部测试计划；测试用例可与需求、任务关联，测试计划与迭代关联，形成测试流程闭环。未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，便于按阶段区分系统测试缺陷与验收遗留问题。测试报告支持自动生成和自定义模板组装，可用于系统测试准出报告与验收结论的附件材料；用例库和测试计划支持单独配置权限，便于让验收方在只读或受限范围内查看执行情况。这些能力承载的是计划落地后的执行与记录，两份计划各自的目标、门槛和签字责任仍需在文档中分别写清。

常见问题

系统测试准出条件中的缺陷收敛标准怎么定才合理？

缺陷收敛标准需要结合项目阶段和业务影响来定，常见写法是按严重程度分级设限。例如致命与严重级缺陷清零，一般级遗留不超过约定数量并附修复计划，轻微级可合并处理。量化口径应在计划评审时由测试负责人与产品负责人共同确认，并写入系统测试计划。如果项目处于早期迭代，标准可以适当放宽；面向合同交付的版本，标准应更严格，并与验收准入条件衔接。

验收阶段发现的问题算缺陷还是需求变更，由谁判定？

验收阶段发现的问题先由供方测试或实施团队做初步判定：与已确认需求或验收标准不一致的，按缺陷处理；超出原约定范围的新要求，按需求变更处理。最终是否阻断上线由验收方决定。计划中应写明判定责任人和变更受理流程，避免验收方直接向开发提新需求导致范围失控。涉及合同条款的争议，以合同约定的变更程序为准。

两份计划可以合并成一份文档吗？

可以放在同一份项目测试规划文档中，但目标、参与方、准入准出条件和缺陷处理规则必须分节写清，门槛不能共用。合并文档的好处是衔接关系一目了然，系统测试报告可直接作为验收准入的附件引用。风险在于如果只写一套准出条件，验收就退化成第二轮系统测试，业务方真正关心的场景没有被单独验证。合同交付项目建议仍保留独立的验收计划章节或附件，便于双方签字确认。