政务系统上线前必须做软件指标测试吗？不做会怎样？
政务系统上线那天要是扛不住，事后倒查，第一份被翻出来的材料往往就是指标测试报告。
有没有、写了什么数字、在什么条件下测的，这三件事决定了后续讨论的性质。是“交付时就不合格”，还是“当时合格、现在超出约定范围需要扩容”。前者是责任事故，后者是资源问题。差别就在这几页纸上。
可偏偏很多人直到验收前一周才意识到这份材料的存在。招标文件里那句“需提供软件指标测试报告”，在漫长的开发周期里一直被当成套话，没人当真，也没人拆解它到底要什么。等终于有人想起来问，离上线已经没剩多少时间了。
软件指标测试
一、先说清楚，“软件指标测试”到底指什么
这个词其实不是标准术语。招标文件里这么写的，多半是经办人自己概括的。它一般指两件事，混在一起就容易乱：
一是定量的性能指标验证。
并发用户数、平均响应时间、吞吐量、成功率、CPU和内存占用、长时间运行的稳定性。这些必须有数字、有条件、可复现。
二是需求里所有“可量化条款”的逐条验证。
比如“数据查询结果返回时间≤2秒”“支持同时在线用户不少于1000”“系统可用性不低于99.9%”。测完一条勾一条，最后给结论：满足、部分满足、不满足。
注意它不等于功能测试。功能测试回答“能不能用”，指标测试回答“够不够快、够不够稳、够不够多”。一个系统功能全通、指标全挂，这种情况我们见得太多了：界面点得开，50个人一起点就超时。你说它合格吗？从功能上说合格。从合同上说，不合格。
二、“必须”这两个字，得看谁在说
我不想骗你说“国家规定所有政务系统上线前都必须做”。没有这样一条放之四海而皆准的规定。真实情况是分层的：
第一层，合同和技术协议。
只要里面写了可量化的指标，测试就是履约的一部分。这不是政策问题，是合同法问题。对方有权要求你证明你做到了。这一层就已经足够“必须”了。
第二层，验收和财政审计要求。
很多地方对信息化项目验收有明确的材料清单，第三方测试报告常列其中；财政投资项目还要过绩效评价和审计。缺了这一页，材料就不全，款就卡在流程里。这一层跟系统做得好不好没关系，纯粹是手续。
第三层，等保、政务云入网、上线审批。
这些是硬门槛，不过不能上线。但它们管的是安全和接入，不管你的响应时间是3秒还是30秒。
所以更准确的回答是：不是法律逼着你做，是你的合同、你的验收流程、你的回款节点逼着你做，而且这三样东西，比法律更难商量。
三、那不做，到底会怎样
最轻的一种：验收会上被退回。
专家翻到指标那一页，问“数据呢”，你答不上来。结论通常是“补充材料后复议”。听起来不严重对吧？但你得重新排期、重新协调环境、重新走流程。政务项目的节奏你是知道的：领导的时间、评审专家的档期、财政的支付窗口，都不是你想约就能约的。拖一个月是常态，拖一个季度也不稀奇。
中等的一种：款付不出来。
财务和审计不看演示，他们看材料。系统跑得再顺，材料清单上少一项，签字就走不下去。乙方最难受的就是这个：活干完了，钱进不来，运维还得继续垫着人。为了省那点测试费，把回款卡死半年，这笔账怎么算都不划算。
最重的一种：上线那天崩了，责任全是你的。
这才是真正要命的。政务系统有个特点，它的流量不是均匀来的，是脉冲式的。社保缴费截止日、报名截止前夜、补贴发放第一天。平时一百个人用，峰值两万个人涌进来。你没测过，就只能赌。赌输了是什么场面？页面打不开、群众投诉、媒体截图、领导被约谈，然后倒查：交付的时候到底合不合格？
不做指标测试的后果
这时候你能掏出一份带日期、带章、写明“在500并发条件下核心接口平均响应时间2.1秒”的报告，这件事的性质就变了。它从“你们没做好”变成“当时是合格的，峰值超出约定范围，需要扩容”。前者是责任事故，后者是资源问题。
四、但也不是所有政务系统都得做全套
如果是纯内部使用、用户就几十个人、不涉及对外服务、合同里也没写定量指标，那跑一遍功能确认测试基本就够了。或者系统是买的成熟产品、只做少量配置化落地，自研部分很薄，性能风险主要在平台方那边，这时候你去压测自己的那层，意义不大。
反过来，只要沾下面任何一条，就别省了：面向公众或大规模公务人员使用、有明确的并发或响应时间条款、涉及资金发放或资格审批、要接政务云、要过等保三级、要在某个固定日期扛住一波流量。
指标测试不是装个工具跑一下就出数。场景要设计、脚本要开发、数据要准备、首轮跑完要分析瓶颈、你们要整改、整改完要复测、最后才能定稿出报告。顺利的话两三周，变量主要在你们调优的速度。
而且政务项目有个额外的麻烦：测试窗口要协调。生产环境或类生产环境不是你想占就能占的，要避开业务高峰期、要跟运维排期、有时候还要等上级单位批。这些时间都不在你手里。
卡到上线前一周才想起来找机构？神仙也救不了。那时候的选择只剩下两个：带病上线，或者延期。而这两个结局，都比早两周启动贵得多。
标签：政务系统上线、软件指标测试