3. 性能测试基础：测试类型与工具选型

性能测试这事儿，说白了就是给系统“称体重”。你得知道它到底能扛多少活，什么时候会累趴下。我做了这么多年性能优化，见过太多上线前没测透，结果被用户流量冲垮的案例。今天咱们就把这块地基打牢。

3.1 三种核心测试类型

性能测试不是一锤子买卖。我个人习惯把它分成三类，每类解决不同的问题。

3.1.1 负载测试

负载测试，就是看系统在“正常”工作状态下的表现。比如你预期每天有10万用户访问，那就模拟10万用户来跑一跑。

核心目标：

• 验证系统能否支撑预期流量
• 找到系统的最佳工作点
• 确认响应时间、吞吐量是否达标

我在项目中遇到过一件事：某电商平台做双11前的负载测试，模拟了80%的预期流量，一切正常。结果上线当天，流量只到了60%就开始卡顿。后来发现是测试数据太“干净”，没有考虑真实用户的数据分布。嗯，这里要注意：测试数据一定要贴近生产环境。

3.1.2 压力测试

压力测试就有点“暴力”了。它要找到系统的极限在哪里。说白了，就是一直加压，直到系统崩溃。

核心目标：

• 找到系统的性能拐点
• 观察系统崩溃后的恢复能力
• 验证限流、降级等保护机制是否生效

我曾经做过一个支付系统的压力测试。加压到正常流量的3倍时，系统突然返回了大量500错误。你以为这是坏事？其实不是。这说明我们的限流阈值设置得太高了，应该提前触发保护。你想想看，与其让系统直接挂掉，不如优雅地拒绝一部分请求。

3.1.3 稳定性测试

稳定性测试，也叫“耐力测试”。它不追求高并发，而是看系统能不能长时间稳定运行。比如跑个72小时，看看内存会不会涨，连接会不会断。

核心目标：

• 发现内存泄漏问题
• 验证连接池、线程池的回收机制
• 检查日志、监控系统是否正常工作

我记得有个项目，负载测试和压力测试都过了，结果上线一周后，数据库连接池被耗尽。原因就是某个接口没有正确释放连接。稳定性测试就是专门抓这种“慢性病”的。

3.2 测试工具选型

工具选得好，测试事半功倍。我这些年用过不少工具，挑三个最常用的聊聊。

3.2.1 JMeter

JMeter 是老牌工具了，功能非常全面。它支持各种协议，HTTP、JDBC、JMS 都能测。

优点：

• 图形化界面，上手快
• 插件生态丰富
• 支持分布式压测

缺点：

• 资源消耗大，单机并发有限
• 脚本维护成本高

我个人习惯用 JMeter 做中小型项目的性能测试。它的图形化界面确实方便，团队成员都能看懂。

3.2.2 Locust

Locust 是用 Python 写的，脚本就是代码。它最大的特点是“轻量”和“灵活”。

优点：

• 代码化脚本，易于版本管理
• 支持分布式，扩展性好
• Web 界面实时查看结果

缺点：

• 需要 Python 基础
• 协议支持不如 JMeter 全面

来看一个简单的 Locust 脚本示例：

from locust import HttpUser, task, between

class WebsiteUser(HttpUser):
    wait_time = between(1, 5)
    
    @task
    def index_page(self):
        self.client.get("/")
    
    @task(3)
    def view_item(self):
        self.client.get("/item?id=1001")

这段代码模拟了用户访问首页和商品详情页的行为。你看，代码非常简洁，而且可以轻松集成到 CI/CD 流水线中。

3.2.3 wrk

wrk 是个命令行工具，用 C 语言写的。它最大的特点就是“快”。

优点：

• 性能极高，单机可以压出几十万 QPS
• 资源消耗极低
• 适合做基准测试

缺点：

• 只支持 HTTP 协议
• 功能单一，没有图形界面

我一般用 wrk 做快速验证。比如改了个配置，想知道效果怎么样，跑一下 wrk 几秒钟就出结果了。

wrk -t12 -c400 -d30s http://localhost:8080/api

这条命令的意思是：用12个线程，保持400个并发连接，持续压30秒。

3.3 工具选型对比

特性	JMeter	Locust	wrk
上手难度	低	中	高
脚本灵活性	中	高	低
单机性能	中	中	高
协议支持	多	中	少
分布式支持	好	好	差
适用场景	综合测试	灵活定制	基准测试

3.4 知识体系总览

下面这张图，把本章的核心内容串起来了。你可以把它当作一个“速查地图”。

好了，性能测试的基础就聊到这儿。记住一点：测试不是走过场，而是为了发现真实问题。你投入多少心思，系统就会回报你多少稳定。