性能测试基础

概念：为了发现系统的性能问题来获取系统性能相关的指标而进行的测试

⼀般在真实环境、特定负载条件下，通过⼯具模拟实际软件系统的运⾏及其操作，同时监控性能各项 指标，最后对测试结果进⾏分析来确定系统的性能情况。

常见的性能测试的指标

如何来评价性能的好坏，通常通过指标来进行推测

吞吐量

吞吐量是指在单位时间内系统成功处理的请求数量或数据量，是衡量系统处理能力的关键指标。

分类：

TPS：每秒处理的事务数，用于衡量一个系统在单位时间内能够处理的事务数

计算公式：总共请求成功的事务数/总共处理事务数的时间

举例1：某⼀系统1分钟处理1000个业务，那么TPS=1000/60=16.7

并不是在平均的时间内处理的，因此：

二八定律：80%的事务在20%的时间内处理完成

TPS=100000*0.8/24*60*60*0.2=4.6

一般来说，吞吐量越大，性能越好

QPS:每秒查询率

如果⼀个事务中只有⼀个接⼝且是查询接⼝，则QPS=TPS

响应时间

验证系统处理速度快不快。

应⽤系统从请求发出开始，到客⼾端接收到最后⼀个字节数据所消耗的时间。 对于web系统⽽⾔，系统响应时间包含前端展现时间和系统响应时间。

前端展现时间：⻚⾯渲染时间。

系统响应时间：包含服务器、数据库、通讯⽹络等响应时间。

• X轴：VU（虚拟用户数/并发数）

• Y轴：TPS（吞吐量）

• 曲线从原点上升，到达峰值点 c 后下降

• 标注了 a、b、c、d 四个关键点

当并发⽤⼾较少，系统吞吐量低，系统响应时间较短，我们认为系统处于空闲区间。

随着系统并发⽤ ⼾增加，系统吞吐量开始呈线性增⻓，系统性能进⼊了线性增⻓区间。

吞吐量在某个点上达到了饱和点，也称之为拐点。在这之后⽤⼾请求不再被⽴即处理，响应时间随之 变⻓，吞吐量也逐渐降低，系统性能进⼊了过饱和区间。

系统性能的拐点通常是性能测试的主要⽬的。

资源利用率

通过查看系统占⽤的情况分析资源瓶颈。

服务器：CPU、内存、磁盘、⽹络等

性能测试的分类

基准测试

基准测试(BenchmarkTesting)⼜称单⽤⼾测试，主要⽤于监测被测系统在较低压⼒下的运⾏状 况并记录相关数据。当性能测试环境确定以后，通常选取业务模型中的重要业务做基准测试，对 被测系统施加⼀定压⼒，从⽽获取被测系统在单⽤⼾运⾏情况下的各项性能指标，为多⽤⼾并发 测试和混合场景测试等提供参考依据

并发测试

模拟多个用户同时访问系统，验证系统在并发场景下的正确性和性能表现。

类型	说明	示例
**绝对并发**	同一时刻发起请求	0点秒杀，10000人同时点击
**相对并发**	时间段内持续请求	1分钟内 1000 个用户轮流操作
**逐步加压**	并发数阶梯式增长	100→200→500→1000 用户

并发数（Concurrent Users）
    ↓
产生 → 吞吐量（TPS/QPS）→ 系统处理能力
    ↓
影响 → 响应时间（RT）→ 用户体验
    ↓
导致 → 错误率（Error Rate）→ 系统稳定性
    ↓
反映 → 资源利用率（CPU/内存/IO）→ 瓶颈定位

负载测试

目的: 确定系统在正常和峰值负载下的性能表现
方法: 逐步增加并发用户数，观察系统性能变化
关键: 找到系统的"最佳负载点"和"最大负载点"

典型场景:
  - 电商网站：模拟日常 1000 并发用户购物
  - 银行系统：模拟月末转账高峰期的负载

压力测试

目的: 测试系统在极端负载下的行为和恢复能力
方法: 持续加压直到系统崩溃或性能急剧下降
关键: 找到系统的"崩溃点"和"恢复能力"

典型场景:
  - 将并发数从 1000 逐步增加到 10000
  - 观察系统何时开始报错、响应时间何时急剧上升
  - 验证系统崩溃后能否自动恢复

稳定性测试

目的: 验证系统在长时间运行下的稳定性
方法: 保持中等负载持续运行数小时甚至数天
关键: 发现内存泄漏、连接池耗尽等累积性问题

典型场景:
  - 系统以 70% 最大负载持续运行 72 小时
  - 监控内存使用是否持续增长
  - 检查日志是否有异常堆积

压力测试和负载测试的区别

负载：能承受多少负载，能不能扛得住

压力：系统什么时候会坏，坏在哪里

维度	负载测试	压力测试
**负载水平**	正常到峰值（预期范围内）	超出正常范围（极限负载）
**负载曲线**	阶梯式上升，寻找拐点	持续高压，直至系统崩溃
**是否要让系统崩溃**	❌ 不需要	✅ 需要
**关注点**	性能指标是否达标	系统容错和恢复能力