政务系统验收只做了功能测试，评审专家要求补性能测试报告怎么办？

验收会开到一半，评审专家翻完材料，抬头问了一句：“性能测试报告呢？”

你愣了一下。功能测试报告厚厚一摞，用例通过率、缺陷清单、修复记录全都有，怎么还要性能报告？专家把合同翻到技术指标那一页，指着其中一行字：“系统需支持500并发用户，响应时间不超过2秒。这行指标，你们用什么证明？”

答不上来，项目卡住，验收暂停，尾款结算往后拖。这种事在政务信息化项目里太常见了。

功能测试与性能测试

一、为什么功能测试过了，还被要求补性能报告？

因为功能测试和性能测试，证明的是两件完全不同的事。

功能测试回答的是“系统做对了吗”，登录能不能进、审批流程能不能走通、数据算得对不对。它证明的是业务逻辑的正确性。

性能测试回答的是“系统扛得住吗”，500人同时提交审批会不会崩、高峰期响应时间会不会飙到10秒、连续跑72小时内存会不会泄漏。它证明的是系统在真实负载下的承载能力。

政务系统有一个特点：用户量集中、访问时段集中。上班时间，几千人同时登录、同时提交、同时查询，流量瞬间冲高。功能测试在这个场景下什么都证明不了，你一个人点，系统当然不卡；五千个人一起点，数据库连接池可能瞬间耗尽。

评审专家要性能测试报告，不是在刁难你，是在确认：这套系统上线后，能不能扛住真实的业务压力。

二、补测流程：跟常规测试有什么不一样？

补测不是从头再来一遍。功能测试已经做过的部分，不需要重复。补测的核心是针对性能指标做专项验证。

第一步，先翻合同。

找出合同或任务书里所有跟性能相关的量化指标。并发用户数、响应时间、吞吐量、资源利用率，每一项都要列出来。这些指标就是补测的测试依据。

第二步，确认测试环境。

性能测试对环境的敏感度远高于功能测试。硬件配置、网络带宽、数据库版本、中间件参数，要尽可能对齐生产环境。在开发机上跑出来的性能数据，到了验收现场站不住脚。

第三步，设计测试场景。

性能测试不是“跑个压测工具看看”。要设计具体的业务场景，模拟500个用户同时登录、同时提交审批、同时查询报表。每个场景对应合同里的哪条指标，要一一对应上。

第四步，执行测试与数据采集。

阶梯式加压，从低并发开始，逐步往上加。记录每个台阶的响应时间、吞吐量、资源利用率、错误率。测试过程中监控全程开着。

第五步，出具报告。

报告要明确标注测试依据、测试环境、测试场景、实测数据。结论必须直接回应合同里的指标，“在500并发下，P95响应时间1.8秒，满足合同约定的≤2秒要求”。

软件测试时间

三、时间上来得及吗？

常规性能测试周期是7到15个工作日。如果验收节点很近，可以走加急通道，3到5个工作日出报告。但加急有前提：环境必须提前搭好，测试场景必须提前锁定，数据必须提前准备好。

有一个容易被忽略的点：如果性能测试发现了瓶颈，开发团队需要修复，修复后还要回归验证。这个“测→修→复测”的循环，是影响整体周期最大的变量。系统本身问题多，加急也快不起来。

建议在验收前2到3周启动补测流程，给整改和复测留出缓冲时间。

政务系统验收，功能测试保“能用”，性能测试保“扛得住”。评审专家要求补性能报告，不是刁难，是验收流程的硬性要求。补测不可怕，可怕的是环境没搭好、场景没锁定、时间没留够未选好一家CNAS认可范围覆盖性能测试的机构。

标签：性能测试报告、功能测试报告