软件项目验收总扯皮？90%是因为测试范围没写清楚！这份合同模板你必须看

验收会上甲方说"这个功能不对"，乙方一脸委屈"任务书里没写这个啊"，两边各执一词，评审专家夹在中间左右为难。项目就这么卡住了，尾款结不了，关系也搞僵了。

一、为什么测试范围总扯皮？

先看一个真实案例。一个470万的项目，历时14个月，最后因为终验报告上的一行“系统在高并发场景下，开户接口响应时间未达合同约定的200毫秒以内”，被甲方卡掉了最后一笔15%的验收款。 70万，就卡在这一行字上。

软件测试范围

合同签的时候没人觉得“200毫秒”有什么问题。验收的时候，甲方拿着这个数字说事，乙方说“测试环境不一样”，甲方说“合同白纸黑字写着呢”。扯了三个月，谁也说不清。

问题出在哪？合同签的时候没说清楚“在什么环境下测、用什么工具测、测几次、取哪个值”。

浙江省电子信息产品检验研究院在介绍验收测试业务时，明确提到测试依据是招标书、委托合同、软件需求说明书及相关行业标准、国家标准。但这些依据在合同里引用得越明确，后期扯皮的空间就越小。引用得越模糊，扯皮的空间就越大。

海南省住房公积金管理局的采购需求里写得就很清楚：“软件验收测试范围应全部覆盖系统设计文档中所有功能和非功能性要求，以及该项目软件开发合同、合同附件和合同变更过程中产生的各类功能点”。测试范围=合同+需求文档+变更文档。范围定了，后面谁也赖不掉。

二、合同里的测试范围到底怎么写才不扯皮？

1. 被测软件信息要精确

被测软件名称、版本号、软件著作权登记号（如有）、主要功能模块清单，这些都得写清楚。名字写错了，版本号对不上，后面全是坑。

2. 测试类型与范围要量化

功能测试要写：依据哪一版需求规格说明书（精确到版本号和日期），覆盖哪些具体功能模块。还要明确排除哪些内容，比如“不含性能测试与安全测试”。

性能测试要写：覆盖哪些具体接口或场景，测试指标要量化，响应时间不超过多少毫秒（在什么并发数下、取P95还是P99）、吞吐量不低于多少TPS、错误率不超过多少百分比。

安全测试要写：覆盖OWASP Top 10的哪些漏洞类型、明确排除哪些安全测试类型。

3. 测试环境与工具要明确

测试环境要写具体配置：几核几G的服务器、什么操作系统版本、什么数据库版本、什么中间件版本。测试工具也要写清楚：用JMeter还是LoadRunner，用Burp Suite还是别的工具，工具版本号是多少。

环境差异条款也要写：如果因为测试环境与生产环境差异导致结果偏差，以什么为准？最好约定“以合同约定的环境为准”或“以双方协商的第三方环境为准”。

4. 测试依据要按优先级排

测试依据按优先级排序：

• 本合同及附件

• 需求规格说明书（精确到版本号）

• GB/T 25000.51-2016《系统与软件工程 系统与软件质量要求和评价》

• 项目合同及补充协议

5. 测试标准与通过准则要可衡量

功能测试通过率不低于多少百分比，核心功能清单里的每一项通过率必须100%。性能测试在什么并发数下，多少百分比的请求响应时间不超过多少毫秒，错误率不超过多少百分比。安全测试无高危漏洞，中危漏洞在几个以内且满足什么条件。致命和严重级缺陷修复率100%，一般和建议级缺陷修复率不低于多少百分比。

6. 争议处理条款要提前约定

双方对测试结果有争议时，优先以GB/T 25000.51-2016标准为判定依据。如果还是达不成一致，可共同委托具备CNAS资质的第三方检测机构进行复测，复测结论为最终判定依据，复测费用由责任方或双方协商承担。

软件测试范围

一个容易被忽略的点：需求变更怎么处理。项目过程中需求变了，测试范围要不要变？合同里得写清楚变更流程，需求变更必须书面通知测试方，测试范围同步调整，费用和时间相应调整。不写这一条，后期需求变了测试没跟上，扯皮是必然的。

三、签合同的时候多写两页纸，验收的时候少扯三个月皮

合同里测试范围写不清楚，验收就是一场豪赌。赌甲方不会较真，赌专家不会细看。

470万的项目，因为一行字被卡掉70万。开发团队拼命加班，验收时甲方一句“功能都对，但没法用”，项目前功尽弃。测试范围没有分层，核心功能、次要功能、探索性测试混在一起，验收时该深测的没深测，该浅测的浪费了时间。

签合同的时候多写两页纸，验收的时候少扯三个月皮。 把“测什么、怎么测、什么算过”在签合同的时候就定死。后面的事情，按合同办就行了。

标签：验收测试报告、甲方交付测试