性能测试基础：目的、分类与关键术语
说实话，我入行那会儿，对性能测试的理解特别单纯。觉得就是拿工具跑一跑接口，看返回快不快。直到有一次，我负责的一个支付系统在上线前压测，TPS死活上不去，数据库连接池爆了，整个服务挂了半小时。那次事故教会我一个道理：性能测试不是跑个脚本就完事，它是一套系统的诊断方法。今天我就把自己这些年踩过的坑，跟各位好好聊聊。
我们到底为什么要做性能测试？
你想想看，一个接口上线前，功能测试已经跑通了，为什么还要做性能测试？答案其实很直接：功能和性能是两个维度的事情。
- 评估系统能力：我的系统到底能扛多少并发？在峰值流量下会不会崩？
- 发现性能瓶颈：是数据库慢，还是代码有锁，还是网络带宽不够？
- 验证系统稳定性：跑一晚上会不会内存泄漏？长期压力下会不会越来越慢？
- 容量规划：业务增长50%，我该加几台机器？
说白了，性能测试最核心的目标只有一个：保证线上业务在预期压力下，能稳定、快速地返回正确结果。这也是我们学这门课要回答的核心问题。
性能测试的三大分类
分类这事，不同公司叫法可能不一样，但核心就是三类。我画个图帮你理清楚。
负载测试
负载测试，说白了就是模拟真实用户场景。我记得有一次给电商平台做压测，上线前预估高峰期有1000人同时下单。我们就在测试环境模拟这个量级，看看每个接口的响应时间是否还在100ms以内。
压力测试
压力测试比负载测试更狠一点。它是为了找到系统的极限。我习惯逐步加压，先100并发，然后200、500、1000，直到TPS不再增长，或者响应时间突然飙升。这个拐点，就是系统的瓶颈所在。
稳定性测试
稳定性测试也叫耐久测试。你可能遇到过，系统刚上线跑半小时一切正常，跑了两三个小时后突然变慢。嗯，这就是稳定性问题。我见过最典型的案例是，一个接口每次调用都会创建新线程但不销毁，24小时后线程数飙到20000，直接把CPU打满。
四个你必须背下来的关键术语
这几个术语，在面试和实战中都绕不开。我建议你不仅要记住定义，更要理解它们之间的换算关系。
| 术语 | 全称 | 核心含义 | 我平时怎么用 |
|---|---|---|---|
| TPS | Transactions Per Second | 每秒完成的事务数 | 核心指标，评估系统吞吐能力 |
| QPS | Queries Per Second | 每秒完成的查询数 | 常用于读接口，也泛指API调用量 |
| 响应时间 | Response Time / Latency | 从发请求到接收响应的时间 | 关注P99和P999，比平均时间更有价值 |
| 并发数 | Concurrency / Vusers | 同时向系统发起请求的用户/连接数 | 结合TPS和响应时间推算系统承载能力 |
重要公式：并发数 = TPS × 平均响应时间（秒）
举个例子：如果一个接口TPS是1000，平均响应时间是200ms。那么你需要维持的并发数就是 1000 × 0.2 = 200。这个公式在制定压测方案时特别实用。
为什么TPS和QPS不能混用？
很多人觉得TPS和QPS差不多。其实严格来说，TPS强调的是“事务”，一个事务可能包含多个查询。比如下单这个接口，它背后可能有查库存、扣库存、生成订单、推送消息四个数据库操作。在接口层面，我们通常用TPS。在数据库层面，我们才看QPS。
响应时间的四个关键分位
我在项目里写性能报告，从来不看“平均响应时间”。为什么？因为平均值很容易被少数慢请求拉高，反而掩盖了真实问题。我建议你盯住这四个分位：
- P50（中位数）：一半的请求比这个值快，一半比这个值慢。能反映大多数用户的真实感受。
- P90：90%的请求在P90以内。这个值如果太高，说明有小部分用户已经感受到卡顿了。
- P99：99%的请求处理完毕的时间。这是性能测试最常用的硬指标，我一般要求P99 ≤ 200ms。
- P999：千分之九十九点九的请求处理完毕的时间。用来排查极端情况下的慢请求。
性能测试的“冰山模型”
你想想看，为什么同样的接口，到了线上就比压测环境慢很多？很多时候，问题藏在你看不见的地方。我习惯用一个“冰山模型”来思考这个问题：
- 水面之上（看得见）：TPS、响应时间、并发数、错误率。这些是监控系统可以直接报出来的。
- 水面之下（需要深入排查）：CPU使用率、内存占用、GC日志、线程池状态、数据库连接池等待、慢SQL、网络带宽、IO等待、锁竞争。
这其实是整个性能测试的核心逻辑：用压力把“水面之下”的问题逼出来。如果你只盯着TPS，而不去看系统层面的指标，就等于在打一场看不见敌人的仗。
好，这一章关于性能测试的基础就说到这里。记住，明确目的、选对分类、吃透术语，是后续所有诊断与优化的地基。后面几章我们会开始动手做具体的压测和诊断。