一、性能测试基础

1.1 什么是性能测试

性能测试，说白了就是让系统在特定负载下跑一跑，看看它到底行不行。

我经常跟团队里的小伙伴说：功能测试是问「能不能用」，性能测试是问「好不好用」。你想想看，一个电商网站，功能全对，但一到双十一就卡死，这能叫好用吗？

性能测试的核心，就是模拟真实用户的行为，给系统施加压力，然后观察它的响应速度、吞吐量、资源消耗这些指标。嗯，这里要注意，不是随便压一压就完事了，得有目标、有方法、有分析。

1.2 性能测试的目的与价值

我刚开始做性能测试那会儿，总觉得这就是个「找茬」的活。后来踩过几次坑才明白，性能测试的真正价值在于——提前发现问题，而不是等问题上线了再补救。

具体来说，性能测试的目的有这几个：

• 验证系统是否达标：比如接口响应时间要求 200ms 以内，TPS 要过 1000，压一压就知道行不行
• 发现性能瓶颈：到底是数据库慢，还是代码写得烂？压测结果会告诉你
• 评估系统容量：系统最多能扛多少人？什么时候该扩容？这些数据得靠压测来摸
• 辅助调优决策：改了个缓存策略，效果怎么样？压一下前后对比，一目了然

我在项目中遇到过最典型的案例：一个支付系统，功能测试全过，上线前压了一下，结果发现并发 200 的时候数据库连接池就爆了。幸亏发现得早，不然上线那天就是事故现场。

1.3 性能测试的分类

性能测试不是只有一种玩法。根据不同的目的，我一般把它分成四类。这四类各有各的侧重点，咱们一个一个说。

1.3.1 负载测试

负载测试，就是逐步增加并发用户数，看系统在不同负载下的表现。说白了，就是在找「系统能承受的合理范围」。

举个例子：一个登录接口，从 10 个并发开始，每次加 10 个，一直加到 200。观察响应时间的变化曲线。你会发现，一开始响应时间很稳，到某个点突然飙升——那个点就是系统的拐点。

我曾经帮一个电商平台做负载测试，发现他们的商品详情页在并发 500 的时候响应时间从 80ms 飙到了 2s。查了半天，原来是 Redis 缓存没命中时，直接查了 MySQL 的慢查询。嗯，这就是负载测试的价值——帮你找到那个「临界点」。

1.3.2 压力测试

压力测试和负载测试有点像，但目的不同。压力测试是让系统一直处于高负载状态，看它会不会崩溃，崩溃后能不能恢复。

我习惯把压力测试叫做「极限测试」。你想想看，系统在 80% 的 CPU 使用率下跑 1 小时，内存会不会泄漏？连接池会不会耗尽？这些都是压力测试要回答的问题。

1.3.3 稳定性测试

稳定性测试，也叫「耐久测试」。它的核心是：系统在正常负载下，长时间运行会不会出问题？

我见过太多系统，刚上线时好好的，跑了一周就开始变慢。为什么？内存泄漏、线程泄漏、缓存失效……这些问题在短时间压测里根本发现不了。

稳定性测试一般跑 24 小时到 72 小时，负载控制在峰值的 60%-80%。重点关注这几个指标：

• 内存使用率是否持续增长（泄漏信号）
• 响应时间是否逐渐变慢（性能退化）
• 错误率是否随时间上升（资源耗尽）

1.3.4 并发测试

并发测试，很多人理解错了。它不是单纯地看系统能支持多少用户，而是看多个用户同时操作同一资源时，系统能不能正确处理。

举个例子：两个人同时抢购最后一件商品，系统会不会出现超卖？两个人同时修改同一条订单，数据会不会错乱？

这就是并发测试要干的事。我建议在做并发测试时，重点关注：

• 锁机制是否生效（乐观锁、悲观锁）
• 事务隔离级别是否合适
• 幂等性设计是否到位

1.4 知识体系总览

说了这么多，咱们用一张图来总结一下这四种测试的关系。我画了个简单的结构图，方便你理解：

这张图很直观：性能测试是根，下面分出四条分支。负载测试找拐点，压力测试测极限，稳定性测试查泄漏，并发测试验锁机制。实际项目中，我一般会先做并发测试，再做负载测试，然后跑稳定性测试，最后用压力测试收尾。

好了，这一章的内容就到这儿。性能测试的基础概念，说白了就是搞清楚「测什么」和「为什么测」。下一章咱们聊聊具体的工具和实战方法。

想要更多资料，联系可可