1. 性能测试基础

1.1 性能测试到底在测什么？

先问大家一个问题：你写了一个接口，本地跑起来响应时间 5ms，你觉得稳了。结果上线后用户一多，直接飙到 5 秒。为什么会这样？

这就是性能测试要解决的问题。说白了，性能测试就是「在特定负载下，观察系统能不能扛得住、跑得快」。我个人的理解更直白一些：它是在模拟真实用户的行为，看看系统会不会崩、会不会慢、会不会丢数据。

我记得刚入行那会儿，有个同事把性能测试和压力测试混为一谈。其实它们有区别，后面我会细说。但核心目标就三个：

• 验证系统能不能满足预期的性能指标（比如 QPS 要达到 1000）
• 发现系统的性能瓶颈（到底是 CPU 不够，还是数据库慢？）
• 评估系统的稳定性和容量（能支撑多少用户同时在线？）

1.2 性能测试的分类，你分得清吗？

很多新手容易把各种「性能测试」名词搞混。我按自己的经验，把它们分成四类：

类型	目的	典型场景
负载测试	验证系统在预期负载下的表现	模拟 1000 用户并发访问首页
压力测试	找到系统的极限在哪里	逐步增加并发，直到系统崩溃
稳定性测试	验证系统长时间运行是否正常	持续压测 24 小时，观察内存泄漏
容量测试	评估系统能支撑的最大用户数	根据业务增长预测，规划扩容

嗯，这里要注意：实际项目中，这些测试往往是组合使用的。比如先做负载测试确认基线，再做压力测试找极限，最后跑稳定性测试看长期表现。

1.3 性能回归：为什么每次改代码都要重新测？

性能回归测试，说白了就是「每次代码变更后，重新跑一遍性能测试，确保新代码没有让性能变差」。你想想看，一个功能迭代，可能只是加了一个日志，结果导致数据库连接池被占满。这种事情我遇到过不止一次。

性能回归的核心逻辑很简单：

1. 建立基线：在代码变更前，跑一次完整的性能测试，记录所有指标。
2. 执行变更：部署新代码。
3. 对比测试：用同样的场景和参数，再跑一次。
4. 分析差异：响应时间变长了？吞吐量下降了？CPU 使用率升高了？

1.4 吞吐量：系统真正的「产能」

吞吐量，英文叫 Throughput，是性能测试里最核心的指标之一。它衡量的是「单位时间内系统能处理多少请求」。常见的单位有：

• QPS（Queries Per Second）：每秒查询数，常用于读场景。
• TPS（Transactions Per Second）：每秒事务数，常用于写场景。
• RPS（Requests Per Second）：每秒请求数，通用指标。

我个人的习惯是，在压测报告中优先关注 TPS，因为它更能反映系统的真实处理能力。举个例子：一个下单接口，QPS 可能很高，但每个请求只查一次数据库。而 TPS 包含了整个下单流程（查库存、扣余额、生成订单），更能体现系统的负载能力。

吞吐量和响应时间的关系，就像「流水线」和「单件工时」：

• 响应时间短，不一定吞吐量高（比如串行处理，一次只能处理一个）。
• 吞吐量高，不一定响应时间短（比如并行处理，但每个请求排队时间长）。

1.5 本章知识体系图

下面这张图，是我自己总结的性能测试基础框架。你可以把它当作一张「地图」，后续章节都会围绕这些核心概念展开。

1.6 本章小结

这一章我们聊了性能测试的「骨架」：

• 性能测试的定义：模拟负载，验证系统表现。
• 四种分类：负载、压力、稳定性、容量，各有各的用途。
• 性能回归：每次改代码都要重新测，别偷懒。
• 吞吐量：系统的「产能」，用 QPS/TPS 来衡量。

我个人觉得，理解这些基础概念，比学会用工具更重要。工具只是手段，思路才是核心。下一章我们会深入具体的压测工具和实战场景，到时候这些概念都会用上。