去年帮一个做电商的压力朋友看服务器，他跟我说网站每到晚上八点就卡得打不开。测试我问他做过压力测试没有，软件他反问那是压力什么。这让我意识到，测试很多人对压力测试软件的软件理解还停留在“听说过”的阶段。

压力测试软件做的压力事情很直接：模拟大量用户同时访问你的系统，看它扛不扛得住。测试就像给一座桥不断加重量，软件直到它变形或者断裂，压力只不过这里用的测试是虚拟用户和并发请求。LoadRunner 算是软件这个领域的老牌选手，功能全，压力但那个界面和授权费用让人头疼。测试JMeter 是软件 Apache 家的开源工具，我用得最多，脚本写起来灵活，就是报告界面丑了点。还有 Locust，用 Python 写测试脚本，代码即配置，对开发者友好。

我自己的习惯是从小规模开始。先跑 50 个并发，观察响应时间曲线。如果平稳，加到 200。再平稳，加到 500。有一次测一个 API 接口，100 并发时平均响应 80ms，200 并发时跳到 300ms，500 并发直接超时。问题出在数据库连接池——默认配置只有 10 个连接。这种瓶颈不跑压力测试根本发现不了，开发环境里永远只有你一个人在点。

工具的选择没那么重要。JMeter 能做的事 Locust 也能做，LoadRunner 能生成的报告 JMeter 加个插件也能凑合。关键是你得清楚要测什么。是测登录接口的极限吞吐量？还是测订单提交在峰值时会不会丢数据？目标不同，脚本设计、监控指标、判断标准都不一样。见过有人拿压力测试工具跑首页静态页面，跑出几千的 QPS 然后沾沾自喜，这跟测了个 Nginx 默认页有什么区别。

压测环境也是个容易被忽略的点。拿生产环境直接压？胆子太大了。但完全隔离的测试环境又往往和线上配置不一致，测出来的数据参考价值打折扣。我的做法是尽量让测试环境的硬件配置、网络拓扑、中间件版本和生产对齐，数据量可以小一些，但结构要一致。不然你测出来能扛 1000 并发，上线后 300 就挂了，那才叫尴尬。

结果解读比测试本身更考验人。TPS 曲线突然下跌的那个拐点，就是系统的瓶颈位置。但拐点之后不一定就是崩溃，有时候系统会进入一个降级运行的区间——响应变慢但请求不丢。这时候要看业务能不能接受。一个后台报表系统响应从 1 秒变成 5 秒，可能没人投诉。一个支付接口从 200ms 变成 2 秒，用户早就关掉页面了。

压力测试软件不会告诉你系统有没有 bug，它只告诉你系统在压力下的表现。至于这个表现是好是坏，得你自己判断。工具跑出来的数字是冷的，但解读数字的人得有温度。我见过团队因为压测报告里一个“错误率 0.1%”吵了一下午，最后发现是测试脚本里一个参数没做参数化，跟系统本身没关系。

说到底，压力测试软件就是个放大镜。它把你系统里平时看不见的裂缝放大给你看。裂缝一直都在，只是没人去压而已。