软件验收测试方案怎么写？GB/T 28035-2011方案要素与编制指南

软件项目验收不是开发方交代码、需方签收的简单环节，而是有明确流程与文档标准的技术审查活动。大量项目验收延期或反复，问题往往不是测试没做，而是验收方案缺失——测试范围含糊、通过准则模糊、追溯关系断裂，导致验收环节反复补测、争议不断。

GB/T 28035-2011《软件系统验收规范》自 2012 年 2 月 1 日实施以来，明确了验收计划的编制要求，其要素涵盖目的、范围、方法、准则、人员等八大模块，把验收方案定位成验收活动的”施工图”。一旦方案缺失，验收环节就成了无据可依的口头会。

验收测试方案的8个法定要素

依据 GB/T 28035-2011 第5.3条，验收计划应至少包含 7 项核心内容，叠加完整性与剪裁信息后实际为 8 个模块。

验收目的与依据

明确本次验收要回答的核心问题——系统功能与性能是否达到合同要求、文档是否齐套、配置管理是否受控。验收依据必须落到合同附件、需求规格说明书、相关国家标准（如 GB/T 8567-2006 文档规范、GB/T 15532-2008 测试规范）上。目的不清，方案在执行中就会被各种临时任务冲散。

技术条件与测试方法

写清楚测试环境配置（操作系统、数据库版本、网络拓扑）、测试工具版本、加压手段、被测对象版本号。方法层面需说明采用黑盒/白盒/灰盒哪一类、用例来源（需求追溯还是缺陷反推）、抽样比例。完整性级别按 GB/T 18492-2001 划分为 A、B、C、D 四级，不同级别的方案剪裁深度不同。

通过准则与人员安排

通过准则是方案中容易被忽视、却容易引发争议的部分。GB/T 28035-2011 给出三条底线：功能/性能符合合同与需求；文档齐全且通过评审；错误总数不超过约定值。A、B 级高完整性系统还要加测功能与性能强度测试。人员安排上，验收评审组需 5 人及以上单数，A、B 级系统表决须一致同意，其他级别三分之二以上同意即可。

方案编制避坑的3个实操要点

要素列齐只是底线，方案能否落地要靠细节。

需求—用例—缺陷追溯矩阵

每条需求至少对应一个测试用例，每条用例至少对应一条预期结果。矩阵的颗粒度做到”需求编号—用例编号—执行结果—缺陷编号”四列闭环。这一矩阵同时是后续回归测试的索引：在变更影响分析时，可以快速定位受影响的功能模块与历史用例。GB/T 25000.51-2016 的功能性测试对追溯性也有明确要求，可作为编制参考。

完整性级别与剪裁策略

并非所有软件都需要按 A/B 级高完整性要求开展验收。C、D 级系统可省略部分审查环节、合并评审步骤；A、B 级则必须委托****的第三方机构开展验收测试，且测试方案需经评审组独立审议后再执行。需方在方案里就需要写明剪裁依据与保留项，避免执行时擅自删减。

与开发方的协商留痕

验收方案不是需方一方的文件，需在编制过程中与开发方协商一致后再走需方审批。征求意见的会议纪要、沟通邮件、开发方书面回执都应归档为方案附件——这是 GB/T 28035-2011 验收计划章节的明确要求，也是验收争议出现时的关键证据。

方案评审与执行闭环

方案编制完成后，验收组织要对方案开展评审，评审通过才能作为正式文件进入执行环节。执行层面，建议把方案与测试记录、缺陷清单放在一起管理，每日的执行进度对应回方案中的人员分工与进度安排条目。验收测试结束后，依据方案给出的通过准则出具验收测试报告，再依此推动后续的验收评审与最终处置。

按 GB/T 28035-2011 框架编制方案的核心收益并非合规，而是降低验收阶段的沟通成本——开发方、需方、第三方机构都按同一份文件执行，任何争议都能在方案中找到对应条款。如果内部缺乏方案编制经验，也可以委托具备 CNAS 认可的第三方测评机构协助编制，由机构依据国家标准搭建矩阵、选用工具、设计测试方法，专业上更稳妥。

类似场景下，北京尚云（尚拓云测）在承接政企软件验收项目时，会依据 GB/T 28035-2011 与 GB/T 25000.51-2016 两套标准配套编制方案，把需求追溯、完整性级别、第三方测试接口一次性落到文档里，确保招投标、项目验收、科技成果评价三类场景都能直接复用。