性能测试

性能测试

性能测试是一种通过模拟真实用户行为和系统负载，来验证软件在响应时间、吞吐量、资源占用、稳定性等关键指标上是否达标的技术活动。

我干这行八年多，经手过银行核心系统、电商大促平台、还有医疗影像上传服务的性能测试。最常遇到的情况是：开发说“功能都跑通了”，一到压测就崩——数据库连接池打满、CPU飙到95%、接口超时率突然从0.1%跳到40%。

它不是点几个按钮就能出报告的事。真正的性能测试得拆成好几步：先明确目标（比如“双11零点要扛住5000笔/秒下单”），再设计场景（登录+加购+下单+支付链路怎么配比），然后选工具（JMeter居多，但高并发下用Gatling或k6更稳），最后还得会看监控——光看TPS数字没用，得同时盯JVM堆内存、GC频率、MySQL慢查询、Nginx 502数量。

很多团队把“跑了一遍JMeter脚本”就叫做了性能测试，这其实只是压力生成，离发现问题差得远。

去年有个客户，上线前做了所谓“全链路压测”，结果大促当天库存扣减错乱。复盘发现，他们只压了API层，根本没连真实数据库，事务隔离级别也设错了。测试环境跟生产环境差了一层Redis缓存，而那个缓存恰好是库存校验的关键节点。

性能测试的核心不是找bug，而是找瓶颈。有时候问题不在代码，而在配置——比如Tomcat默认最大线程数150，而实际需要800；有时候问题在依赖服务，比如调用的第三方短信网关平均响应从200ms涨到2秒，直接拖垮整个下单流程。

• 不能只测单接口：真实业务是链路式的，下单失败可能卡在风控服务，而不是订单服务本身
• 数据必须够真：用10万条相同用户ID压测，和用10万条分散手机号+不同收货地址，结果可能差3倍
• 环境差异必须记账：测试机CPU核数、磁盘类型（SSD还是机械盘）、网络延迟，每项都要和线上对齐，否则结论无效
• 基线必须保留：每次发版前跑一次相同脚本，对比响应时间和错误率变化，这才是持续性能管理

别迷信“99.99%可用性”这种虚数。我见过太多报告写“系统支持10万并发”，结果一查是单台机器空跑静态页——加上登录态校验、DB读写、日志落盘，实际能撑3000就不错了。

性能测试做扎实了，省下的不只是服务器钱，更是半夜被电话叫醒改紧急预案的时间。