第3章性能测试方法论

3、性能测试方法论：负载测试、压力测试、稳定性测试、容量规划测试

说到性能测试，很多刚入行的朋友容易混淆几个概念。我见过不少团队，把负载测试和压力测试混为一谈，结果上线后出了大问题。今天咱们就把这四种测试方法掰开揉碎了讲清楚。

负载测试，说白了就是给系统加活干。我习惯这么理解：就像让一个人搬砖，先搬10块，再搬20块，看看他什么时候开始喘气。

在SCADA系统里，我们通常关注几个核心指标：

举个例子，我曾经帮一个水处理项目做负载测试。客户说他们最多500个站点同时在线。我按这个量级测了，发现CPU占用率才30%。但我不放心，又加到了800个站点——好家伙，响应时间直接飙到了3秒以上。

关键点：负载测试的目标是找到系统在正常负载下的表现，而不是把它搞崩溃。

压力测试和负载测试不一样。负载测试是「慢慢加量」，压力测试是「往死里怼」。我做过一个电力调度项目，客户要求系统必须能扛住2000个遥测点的突发数据洪峰。

怎么测？我写了个脚本，模拟所有站点同时上报数据：

// 压力测试脚本片段
for (int i = 0; i < 2000; i++) {
    SendTelemetry(siteId[i], randomData());
    // 不等待，直接发下一条
}

结果呢？系统在第37秒的时候挂了。数据库连接池耗尽，消息队列爆满。嗯，这就是压力测试的价值——找到那个临界点。

注意：压力测试一定要有监控手段。我曾经有一次没开监控，系统挂了都不知道，白白浪费了半天时间。

稳定性测试，我管它叫「熬鹰测试」。让系统连续跑72小时甚至168小时，看看会不会出幺蛾子。

你想想看，SCADA系统是要7×24小时运行的。有些bug平时不出现，跑个两三天就冒出来了。比如内存泄漏，我遇到过最夸张的一次，系统跑了48小时后，内存占用从2GB涨到了12GB。

稳定性测试的几个要点：

我的经验：稳定性测试期间，每天都要检查日志。有些错误日志被淹没了，你不翻出来看，根本不知道系统已经在崩溃边缘了。

容量规划测试，说白了就是回答一个问题：「明年站点翻倍了，系统还能不能扛？」

我习惯用表格来记录测试数据：

站点数量	CPU使用率	内存占用	响应时间	结论
500	25%	4GB	200ms	正常
1000	45%	7GB	350ms	正常
1500	68%	11GB	680ms	临界
2000	92%	15GB	1.8s	超标

看到没？从1500到2000，响应时间翻了一倍多。这说明系统在1500站点时已经接近瓶颈了。我建议客户在站点数达到1200时就考虑扩容。

核心思路：容量规划不是等系统扛不住了再想对策，而是提前预判，留出余量。

这四种测试不是孤立的。我一般按这个顺序来：

我曾经犯过一个错误：直接跳过了负载测试，上来就做压力测试。结果系统崩了，但根本不知道是正常负载下就有问题，还是压力太大导致的。后来我学乖了，一步一个脚印来。

避坑指南：测试环境要尽量和生产环境一致。我见过有人用低配机器做测试，结果上线后在高配机器上反而出了问题——因为配置不同，线程池参数、连接池大小都不一样。

好了，这四种测试方法就讲到这里。下一章咱们聊聊具体的测试工具和脚本怎么写。记住一句话：没有经过充分测试的系统，上线就是赌博。