目标：能够对个人编写的项目进行接口的性能测试
同样是一辆车，五菱能跑，法拉利也能跑，但为什么价格差那么多？因为性能不同。软件也一样，功能实现了只是"能开"，性能好才是"开得爽"。
一、什么是性能测试？
功能测试在前， 再执行性能测试
简单说，功能测试 回答"系统能不能做这件事"，而性能测试回答"系统做得有多快、能扛住多少人"。
比如你做一个购物网站：
-
功能测试：用户能登录、能下单、能支付 ✅
-
性能测试：双十一那天，10000人同时下单，页面会不会卡死？响应时间会不会超过3秒？ ❌
性能测试就是：在真实或模拟的环境下，用工具给系统施加一定的负载，监控各项指标，发现性能问题（如页面打不开、加载慢、服务器无响应等）。
概念：为了发现系统性能问题或 获取系统性相关的指标 而进行测试
二、核心性能指标 ------ 如何衡量"好不好"？
2.1 并发数
并发用户数，分两种视角：
-
业务层 ：**实际使用系统的用户总数。**比如公司有5000人，最多同时2500人在线，业务并发就是2500。
-
服务器层 ：Web服务器建立的HTTP连接数或处理线程数
小提示：不是所有在线用户都会同时"搞事情"。真正给服务器压力的，是那些正在提交订单、查询数据的用户
2.2 吞吐量
**单位时间内系统能处理的请求/事务数量，**直接体现系统的负载能力。吞吐量越高，性能越好。
常见单位：
-
TPS（每秒事务数）：一个完整业务（如下单）的每秒处理量。
-
公式：总成功事务数 / 总运行时间
-
例子：1分钟处理1000个订单 → TPS ≈ 16.7
-
-
QPS（每秒查询数）：
- 如果单个事务就是一次查询，QPS = TPS。
实际估算TPS时，别傻傻按全天平均。
用二八定律 ：80%的请求发生在20%的时间里。
例如一天10万订单 → 理论TPS=1.2，实际按二八定律≈4.6。如果有高峰时段数据（比如晚上8~9点5万单），则TPS≈13.9，再考虑业务增长30% → 18左右。
2.3 响应时间
从你点击按钮，到页面上收到最后一个字节的时间。包括：
-
前端展现时间：浏览器渲染页面
-
系统响应时间：服务器+数据库+网络等
用户在乎的是主观感受------超过3秒就烦，超过5秒可能直接关掉。
空闲区：并发少，响应快，吞吐量低。
线性增长区：并发增加，吞吐量成比例增加，响应时间平稳。
饱和点（拐点） ：系统处理能力达到极限。性能测试的核心目标就是找到这个拐点。
过饱和区：请求排队，响应时间暴涨，吞吐量反而下降，甚至崩溃。
| 阶段 | 并发用户数 | TPS | 响应时间 | 状态 |
|---|---|---|---|---|
| 空闲区间 | 少 | 低 | 短 | 系统轻松 |
| 线性增长 | 增加 | 线性上升 | 缓慢增加 | 正常运行 |
| 拐点 | 临界值 | 达到峰值 | 开始明显变长 | ⚠️ 性能瓶颈 |
| 过饱和 | 过多 | 下降 | 急剧增加 | ❌ 系统濒临崩溃 |
2.4 资源利用率
服务器吃得消吗？看CPU、内存、磁盘、网络的使用率。
如果CPU长期100%，那肯定扛不住了。
三、不同角色眼中的性能
不同的角色看待性能测试的侧重点不同
从客户端发送一个请求到客户到收到请求的整个过程中，各个阶段都可能存在在问题
| 角色 | 关注点 |
|---|---|
| 终端用户 | 响应快不快（主观时间） |
| 运维人员 | 全局利益：最大并发 vs 响应时间的平衡。 比如100万用户响应3秒 vs 500万用户响应8秒，可能选后者 |
| 开发人员 | 算法效率、内存泄漏、架构可扩展性、SQL调优 |
| 测试人员 | 场景设计、脚本编写、缺陷定位，需要广博的知识（DB、JVM、网络等） |
不需要一个人搞定所有，但知道各方关注点，才能做好性能测试。
四、性能测试的五大分类
4.1 基准测试
也称为单用户测试
主要用于监测被测系统在较低压力下的运行状态并记录相关数据。当性能测试环境确定后，通常选取业务模型中的重要业务做基准测试，对被测系统施加一定压力，从而获取被测系统**在单用户运行情况下的各项性能指标，**对多用户并发场景和混合场景等提供参考依据。
用一个用户跑一遍核心业务，记录各项指标（响应时间、CPU占用等）。作为后续对比的"标尺"。
就像你先空手跑一次100米，记下时间，再负重跑就知道影响了多少。
类比：一颗白菜能存放多久？先测一颗！
4.2 并发测试
评估多个用户同时操作时的性能表现，发现内存泄漏、线程锁、资源争用等问题。
类比：100个人同时登录，会发生什么？
4.3 负载测试
逐步增加负载 （比如从100用户慢慢加到10000用户），同时保持性能指标不超标（比如响应时间<2秒），测出系统最大能扛多少负载。
类似举重：不断加重量，直到运动员动作变形（指标超标），之前的重量就是最大负载。逐步增加并发负载，直到某项性能指标达到安全临界值，确定系统最大承受量。
4.4 压力测试
超过预期负载，直到系统崩溃，找出只有在高负载下才会出现的缺陷。
负载测试 vs 压力测试的区别：
负载测试：在满足性能指标（如响应时间≤2秒）前提下，找最大负载（如1万用户）
压力测试：继续加压到2万、3万用户，直到系统崩溃，找极限点
⚠️ 负载 vs 压力
| 维度 | 负载测试 | 压力测试 |
|---|---|---|
| 目标 | 找到满足性能指标下的最大负载 | 找到系统崩溃极限 |
| 负载程度 | 正常～峰值（仍在指标内） | 超过峰值～崩溃 |
| 类比 | 举重运动员动作标准时的最大重量 | 再加到动作变形甚至受伤的重量 |
| 产出 | 容量规划数据 | 系统健壮性、崩溃恢复能力 |
4.5 稳定性测试
在一定的负载下（通常是正常负载的80%左右），长时间运行（比如3×24小时），看系统会不会内存泄漏、日志爆炸、越来越慢。
类比：不是看谁跑得快，而是看谁跑到最后！
