性能测试概念篇：从"能用"到"抗打"，把指标、拐点与测试类型一次讲透
很多系统在功能上"能跑"，但用户用起来会骂街：页面转圈、偶发打不开、双十一直接进不去、查询要等到天荒地老。来看本质区别------功能测试回答"能不能做"，性能测试回答"做得怎么样、在多大压力下还能做"。
1）什么是性能测试：用真实负载把系统"逼出真面目"
来看一个很形象的类比：五菱和法拉利从功能上都能载人、都能跑，但加速、座椅材质、操控体验完全不同。软件也一样：
- 功能层面：页面能打开、按钮能点、订单能提交
- 性能层面：打开要多久、并发高时会不会卡死、资源会不会打满
来看定义：性能测试 是为了发现系统性能问题或获取性能相关指标而进行的测试。通常在真实环境 、特定负载条件下，通过工具模拟用户操作并监控各项性能指标，最后分析结果来判断系统性能状况。
来看"性能问题"在软件里的常见表现（以购物系统为例）：
- 购物过程中页面突然打不开，刷新后又好了（不稳定/抖动）
- 双十一期间无法进入商品页面（容量不足/过载）
- 页面加载时间过长，让用户一直等待（响应时间过慢）
- 查询数据时间过长、服务器无响应、列表迟迟不出（后端/数据库/网络瓶颈）
2）常见性能指标：没有指标就没有结论
性能测试本质是"测量学"。来看几组最常用指标，它们决定了你怎么设计场景、怎么判断是否达标。
2.1 并发数：到底有多少人同时在用
来看两个视角：
- 业务视角的并发用户数：实际同时使用系统的用户总数（比如同时在线 2500 人）
- 服务器视角的并发：Web 服务器在一段时间内处理浏览器请求建立的 HTTP 连接数，或生成的处理线程数
再来看一个更贴近真实业务的例子：5000 员工使用系统，最多同时 2500 人在线；这些人会浏览、填单、提交、查询。
- 业务并发用户数可以说是 2500
- 但"实际压力最大的并发"往往来自提交/查询这类重操作（不是纯浏览）
2.2 吞吐量：单位时间能处理多少请求/事务
来看定义：吞吐量是单位时间内系统能处理的并发量，直接反映系统承载能力。吞吐量越高，系统能承受的并发越多，性能越好。
但吞吐量不能只看"并发用户数"，还要看思考时间（用户两次操作之间的间隔）。来看一个经典对比：
- A 场景：100 并发用户，每人每隔 1 秒发 1 个请求 → 吞吐量=每秒 100 请求
- B 场景：1000 并发用户，每人每隔 10 秒发 1 个请求 → 吞吐量=每秒 100 请求
吞吐量相同，但 A 场景思考时间短、请求更"密"，对系统资源占用更高。结论是：并发人数相同/吞吐相同，不等于压力相同。
2.3 响应时间：从发请求到收完最后一个字节
来看定义：响应时间是从请求发出开始，到客户端接收到最后一个字节数据所消耗的时间。
对 Web 系统而言，响应时间通常由两段组成：
- 前端展现时间：页面渲染时间
- 系统响应时间：服务器、数据库、通讯网络等耗时
也可以把链路拆得更细：客户端时间 → DNS → 网络 → 服务端 → 数据库 → 返回网络 → 客户端呈现。定位性能问题时，拆分很关键：慢在渲染？慢在网络？慢在数据库？
3）并发、吞吐、响应时间的关系：性能"拐点"是主战场
来看系统性能随并发增长的典型曲线（非常重要，几乎所有容量评估都绕不开它）：
- 空闲区间：并发少、吞吐低、响应时间短
- 线性增长区间：并发增加，吞吐量近似线性增加，系统还能扛
- 饱和点/拐点：吞吐量到达峰值（系统吃满关键资源）
- 过饱和区间 ：再加并发，请求不再被立即处理，响应时间显著变长，吞吐量反而开始下降
来看关键结论：找拐点往往是性能测试的主要目的之一------因为它对应系统"最大可用能力"的边界。
4）事务、TPS、QPS：把"业务动作"量化成可算的数
4.1 事务：一个完整功能单元
来看事务的定义：一个接口可以是一个事务，多个接口组成一个事务，一个完整流程也可以是一个事务。事务代表一个完整的功能动作（例如"下单"可能含多个接口调用）。
4.2 TPS：每秒处理事务数
来看公式：
TPS = 总事务数 / 总运行时间（秒）
来看例子 1：1 分钟处理 1000 个业务：
- 运行时间 = 60 秒
- TPS = 1000 / 60 = 16.666... ≈ 16.7
来看例子 2：某天最高 10 万笔交易，估算 TPS（假设每笔交易=1事务）
- 理论平均：一天 86400 秒
- TPS = 100000 / 86400 = 1.1574... ≈ 1.2
但真实世界交易不会均匀分布，通常"高峰更集中"。
两种更现实的估算法：
-
没有更详细数据时，用二八规律（80% 事务集中在 20% 时间完成）：
- 高峰事务数 = 100000 × 0.8 = 80000
- 高峰时间 = 86400 × 0.2 = 17280 秒
- TPS = 80000 / 17280 = 4.6296... ≈ 4.6
-
有更详细数据时：例如 5 万笔交易集中在晚上 8~9 点（1 小时=3600 秒）
-
TPS = 50000 / 3600 = 13.888... ≈ 13.9
-
若按业务年增长 30% 估算下一年：
- 事务数 = 50000 + 50000×0.3 = 65000
- TPS = 65000 / 3600 = 18.055... ≈ 18
-
4.3 QPS：每秒查询率
来看定义：QPS 是每秒查询率。若一个事务中只有一个接口且该接口是查询接口，则 QPS = TPS。
5）资源利用率：性能瓶颈常常藏在"资源饱和"
性能问题定位离不开资源监控。来看常盯的资源项：
- 服务器 CPU
- 内存
- 磁盘
- 网络
通过资源利用率的变化趋势，能更快判断瓶颈大概在"算力、内存、IO、网络、数据库、中间件、架构设计"等哪一层。
6）性能测试关注点：不同角色关注不同"性能真相"
来看一个请求从客户端到服务器再到数据库的全链路：每一段都可能慢，但不同角色关注重点不同。
6.1 终端用户：主观响应时间
用户最关心的是"点了按钮多久有结果"，包含系统响应时间 + 前端展现时间。
6.2 系统运维人员：容量、健康度与权衡取舍
运维更关注高并发下系统整体健康状态、容量规划、稳定性与可扩展性，并经常做权衡：
来看一个典型取舍题：
- A：100 万并发，登录 3 秒
- B：500 万并发，登录 8 秒
运维往往可能更偏向 B（全局利益最大化），而不是只盯单次响应快慢。
6.3 设计/开发人员：算法、架构与最佳实践
开发关注算法效率、架构扩展性、避免内存泄漏、数据库设计与优化、让系统"天然可扩展"。
6.4 性能测试人员：场景设计、脚本执行与缺陷定位
性能测试人员的工作重点在于：性能场景设计、脚本开发与执行，以及性能缺陷排查定位。并且需要较宽的知识面（系统/存储/网络/数据库/JVM GC/多线程等），因为性能问题往往跨层发生。
7）性能测试分类：到底该做基准、并发、负载、压力还是稳定性？
来看常见五类测试，它们的目的完全不同，别混着用。
7.1 基准测试（Benchmark）：单用户/低压力下先摸清底数
又称单用户测试：在较低压力下监测系统运行状况并记录性能数据。通常选择核心业务做基准测试，得到单用户情况下的响应时间、资源占用等，为后续多用户并发/混合场景提供参考。
7.2 并发测试（Concurrency）：同一时刻一起做，会发生什么
用于评估"某些特定操作同时发生"时的表现，比如多用户同时登录、同时下单、同时更新同一条数据。并发测试除了能拿到性能指标，还能挖出并发特有问题：内存泄漏、线程锁、资源争用、数据库写入错误等。通常需要性能工具用多线程/多进程模拟并发虚拟用户。
7.3 负载测试（Load）：在预期负载范围内，系统能扛到哪
负载测试关注系统在预期不同负载 下的行为。做法通常是逐步增加并发/进程数量，监测性能变化，直到某些指标达到安全临界值，从而确定"满足指标要求时的最大负载量"。
来看类比：像举重运动员不断加重量，找到"身体状况保持正常时能举起的最大重量"。
举一个具体判定例子：要求响应时间 ≤ 2 秒。随着访问量增加，响应时间变长；当访问量超过 1 万人时响应时间 > 2 秒，则可认为在"≤2秒"指标约束下，系统最大负载量≈1万人。
负载测试常用于性能验证、性能诊断、性能调优。
7.4 压力测试（Stress）：把系统推到极限，看看它怎么坏
压力测试关注系统在高于预期/高于容量需求 或资源匮乏条件下的行为。通过逐步增加负载，使某些资源达到饱和甚至失效，发现只在高负载下出现的问题（同步问题、内存泄漏等），并找出性能拐点与系统最大服务级别。
负载测试 vs 压力测试：核心区别
来看一句话区分：
- 负载测试：在性能指标要求前提下，找"最大可用负载"
- 压力测试：继续加压到极限，找"系统崩溃点/极限容量与退化方式"
举例：要求响应时间 2 秒
- 负载测试可能发现：访问量 1 万以内 ≤2 秒，>1 万就超 2 秒 → 最大可用负载约 1 万
- 压力测试会继续加：2 万时 5 秒，3 万时崩溃 → 极限容量约 3 万，并记录系统如何退化
压力测试常用于性能诊断、性能调优、容量规划。
7.5 稳定性测试：长时间跑，看看会不会"慢慢死"
稳定性测试是在负载测试基础上做更长时间运行，检查系统稳定性。这里的"长时间"通常指 3×24 小时以上。目标是挖出内存泄漏、资源不释放、性能衰减等"时间型问题"。
8）总结
- 先做基准：单用户跑通链路，拿到底数（响应时间/资源占用）
- 再做负载：逐步加并发，找到"满足指标的最大负载"与性能拐点
- 补并发场景：挑关键共享资源操作（登录/抢购/写入）做并发测试，挖并发缺陷
- 必要时做压力：推到极限，为容量规划与预案（限流/降级/熔断）提供依据
- 最后做稳定性：长时间运行验证"不会慢慢变坏"