第2章：性能测试基础
大家好，我是老张。今天咱们聊聊性能测试最基础的东西。说实话，很多做了两三年的测试工程师，对这几个概念的理解还是模模糊糊的。我记得刚入行那会儿，领导让我做个压力测试，我愣是跟负载测试搞混了，结果被批了一顿。嗯，咱们今天就把这些概念彻底理清楚。
2.1 性能测试到底是个啥？
性能测试，说白了就是回答一个问题：你的系统到底行不行？
不是功能上能不能用，而是——
- 用户多了会不会卡？
- 数据量大了会不会崩？
- 跑个三天三夜会不会内存泄漏？
我个人的理解是：性能测试就是用工具模拟真实用户的行为，去验证系统在特定负载下的表现。 你想想看，一个PIS系统，如果早晚高峰时乘客刷票刷不出来，那还叫啥智慧交通？
核心定义：性能测试是一种非功能测试，目的是评估系统在特定工作负载下的响应速度、稳定性和资源使用情况。
2.2 性能测试的三大分类
很多新手容易把这三类搞混。我建议你记住一个场景：你开了一家奶茶店。
2.2.1 负载测试
负载测试，就是看看你的系统在预期范围内表现如何。
举个例子：PIS系统设计时说能支持5000个并发用户。那我们就模拟3000、4000、5000个用户，看看响应时间、吞吐量是不是还在可接受范围内。
我在项目中遇到过一件事：某PIS系统负载测试做到4500用户时，响应时间突然从200ms飙到2秒。后来发现是数据库连接池配小了。嗯，这就是负载测试的价值——找到系统性能的拐点。
我的习惯：负载测试一般从50%的预期负载开始，每次增加10%-20%，直到达到目标值。别一上来就怼满，容易把系统搞崩。
2.2.2 压力测试
压力测试就狠一点了——我要看看你到底能扛多少。
还是那个奶茶店的例子：你说能服务5000人，我偏要试试6000、7000、8000人。看看你什么时候会崩溃，崩溃后能不能自己恢复。
我曾经做过一个PIS系统的压力测试，模拟了1.2万并发用户。结果系统在8000人时就开始报错，9000人时直接挂了。但有意思的是，把压力降下来后，系统自己恢复了——这说明系统的弹性还不错。
注意：压力测试不是要把系统搞死就完事了。关键是要记录：
- 崩溃时的负载量
- 崩溃前的表现（响应时间、错误率）
- 恢复时间
- 恢复后数据是否完整
2.2.3 稳定性测试
稳定性测试，也叫耐久性测试。说白了就是让系统长时间运行，看看会不会出幺蛾子。
我建议至少跑24小时，最好是72小时。为什么？因为很多问题不是马上能暴露的——
- 内存泄漏：跑几个小时可能看不出来，跑一天就现原形了
- 连接池耗尽：慢慢积累，到某个时间点突然崩溃
- 日志文件撑爆磁盘：这个我踩过坑，曾经有个系统跑了3天，日志文件把磁盘塞满了
| 测试类型 | 目的 | 负载水平 | 持续时间 |
|---|---|---|---|
| 负载测试 | 验证预期负载下的表现 | 预期负载的50%-120% | 短（30分钟-2小时） |
| 压力测试 | 找到系统的极限 | 超过预期负载的150%-300% | 短（10分钟-1小时） |
| 稳定性测试 | 验证长时间运行的可靠性 | 预期负载的70%-80% | 长（24-72小时） |
2.3 关键性能指标
做性能测试，你得知道看什么数据。我总结了三个最核心的指标，其他的都是这三个的衍生。
2.3.1 响应时间
响应时间就是用户从发出请求到收到响应的时间。单位通常是毫秒。
但这里有个坑：平均值会骗人。
举个例子：100个请求中，99个是100ms，1个是10秒。平均值才199ms，看起来不错对吧？但那个10秒的请求，用户早就骂娘了。
所以我建议看这几个值：
- P50（中位数）：一半请求比这个快，一半比这个慢
- P95：95%的请求比这个快
- P99：99%的请求比这个快
- 最大值：最慢的那个请求
PIS系统的响应时间建议：
- 查询类接口：P99 < 500ms
- 数据推送：P99 < 1s
- 文件上传/下载：P99 < 5s
2.3.2 吞吐量
吞吐量就是单位时间内系统能处理多少请求。常见单位有：
- TPS（Transactions Per Second）：每秒事务数
- QPS（Queries Per Second）：每秒查询数
- RPS（Requests Per Second）：每秒请求数
我个人习惯用TPS，因为一个事务可能包含多个请求，更能反映系统的真实处理能力。
你想想看：一个PIS系统，如果TPS只有100，但早晚高峰有1万个用户同时查车次，那响应时间肯定惨不忍睹。
2.3.3 并发用户数
并发用户数是个最容易搞混的概念。
很多人以为并发用户数就是系统同时在线的人数。不对！并发用户数是指同时向系统发起请求的用户数。
举个例子：一个PIS系统有10万注册用户，但同一时刻只有1000个人在查车次。那并发用户数就是1000，不是10万。
我的经验：并发用户数一般是在线用户数的10%-20%。你可以根据业务特点估算。比如地铁PIS系统，早晚高峰时并发比例会高一些，可能到30%。
2.4 三个指标的关系
这三个指标是互相制约的。我画个简单的逻辑：
并发用户数 ↑ → 系统负载 ↑ → 响应时间 ↑ → 吞吐量 ↓为什么会这样？因为系统资源是有限的。当并发用户数增加时，每个请求能分到的CPU、内存、IO资源就少了，响应时间自然就长了。响应时间一长，单位时间内能处理完的请求就少了，吞吐量就下降了。
所以做性能测试时，不能只看一个指标。我见过有人报告说"系统TPS达到5000"，但没提响应时间已经10秒了——这有啥意义？
正确的做法：在响应时间达标的前提下，看系统能支持多少并发用户数，能达到多少吞吐量。
2.5 避坑指南
最后分享几个我踩过的坑：
- 不要用生产环境做性能测试——我曾经有个同事直接在线上做压力测试，结果把数据库搞挂了，被扣了绩效
- 测试环境要跟生产环境尽量一致——配置差太多，测出来的数据没有参考价值
- 先做基准测试，再做负载测试——先知道系统在零负载时的表现，才能对比出问题
- 监控要到位——CPU、内存、磁盘IO、网络、数据库连接池，一个都不能少
好了，这一章的内容就到这里。下一章咱们聊聊性能测试工具的选择，我会重点讲JMeter和Locust的实战用法。到时候见！