详解性能测试类型

详解性能测试类型

性能测试是确保系统在高负载、复杂场景下稳定运行的关键环节。以下是常见性能测试类型的详细解析，涵盖定义、目标、执行方法及实际案例，帮助你精准选择测试策略。

前提条件

已熟悉性能测试曲线，可参考：性能测试曲线模型。

一、基准测试

1. 定义

在单用户、单请求场景下，测量系统基础性能指标（如响应时间、吞吐量）。

基准测试

2. 目标

建立性能基线，确定系统在无干扰条件下的最优性能，作为后续测试的参考基准。
识别初始性能问题（如 SQL 查询效率、代码逻辑缺陷）。

提示

这里的后续测试的参考基准，主要包括两方面：

多用户性能测试的参考基准；
软硬件发生变化后再测试，观察变化对于性能产生的影响。

3. 场景示例

新功能上线前验证基础性能。
硬件/软件升级后对比性能变化。
测量静态资源（如图片）的加载速度。

4. 执行步骤（JMeter）

线程组设置：1 个线程，1 次循环。
取样器：添加 HTTP 请求，禁用所有定时器。
监听器：使用查看结果树（View Results Tree）记录响应时间。

5. 关键指标

平均响应时间（≤ 500ms 为佳）。
无错误请求（错误率 0%）。
CPU/内存占用率。
数据库查询效率。

注意

关闭其他应用程序，减少环境干扰。
多次执行取平均值，避免偶发波动。

二、负载测试（重要）

1. 定义

逐步增加并发用户数，验证系统在不同负载下的表现，找到系统的最优负载和最大负载。

负载测试

注意

一般说的压测指的就是负载测试，用于找到系统的最优负载和最大负载，确定系统的瓶颈。

2. 目标

确认系统能否处理设计容量内的请求。
发现性能瓶颈（如慢SQL、缓存失效）。
确认系统能否处理日常高峰流量。
发现性能拐点，如响应时间陡增的临界值（最大负载）。

3. 场景示例

模拟 1000 用户同时浏览商品详情页，持续 10 分钟。
验证促销活动期间 API 的吞吐量是否达标。

4. 执行步骤（JMeter）

**线程组选择：**选择 Concurrency Thread Group 控制加压节奏。
线程组设置：阶梯式增加线程数（如 100 → 500 → 1000）。
监听器：添加 汇总报告（Aggregate Report，分析 TPS 和错误率。

5. 关键指标

TPS（目标值：根据业务需求设定，如 ≥ 200 TPS）。
系统资源使用率（CPU ≤ 70%，内存无持续增长）。

6. 典型问题

数据库慢查询导致 TPS 下降 → 优化索引或分库分表。
线程池满导致请求排队 → 调整线程池配置。

三、压力测试（重要）

1. 定义

施加超出系统设计容量的负载，测试极限性能、容错能力和故障恢复能力。

2. 目标

找到系统崩溃的临界点最大负载。
验证降级策略和容灾机制是否生效。
验证故障后的自动恢复机制。

3. 场景示例

模拟 5000 用户抢购 100 件限量商品。
金融系统在突发流量下的熔断机制验证。
突然切断数据库连接，观察服务是否自动切换至备用节点。
数据库连接耗尽时的错误处理策略。

4. 执行步骤（JMeter）

线程组选择：使用 Ultimate Thread Group 模拟流量尖峰。
线程组设置：瞬时高并发（如 5000 线程，0 秒启动）。
监控系统日志：记录错误类型（如 503 Service Unavailable）。

5. 关键指标

系统崩溃前的最大 TPS。
故障恢复时间（如 5 分钟内自动重启）。

注意

提前备份数据，避免测试导致生产数据丢失。
压测后检查日志，分析崩溃原因（如内存溢出）。

四、并发测试

1. 定义

验证多用户同时操作同一功能时的数据一致性和系统行为。

2. 目标

确保高并发下业务逻辑正确（如库存扣减，防止超卖）。
检测资源竞争问题（如死锁、脏读）。

死锁

3. 场景示例

100 用户同时提交同一商品的订单，验证库存是否正确扣减。
多线程更新用户积分，检查最终一致性。
多人同时编辑文档的冲突处理。

4. 执行步骤（JMeter）

使用 Synchronizing Timer 实现多线程同时触发请求。
添加 JSON Extractor 提取库存字段，断言结果是否合理。
数据库监控：检查事务锁和死锁日志。

5. 测试设计技巧

使用事务监控工具（如DTM）
结合分布式锁（Redis Redlock）

6. 关键指标

数据一致性（如库存扣减数量 = 成功订单数）。
无死锁或线程阻塞（通过 jstack 分析线程状态）。

7. 典型问题

超卖：使用分布式锁（Redis Lock）或乐观锁（版本号）。
响应超时：优化事务粒度或引入异步处理。

8. 经典案例

机票预订系统未处理并发支付时，出现同一座位被重复售出。

五、稳定性测试

1. 定义

长时间运行测试（通常 12-24 小时），验证系统在持续负载下的可靠性。

2. 目标

发现内存泄漏、线程阻塞、资源逐渐耗尽等问题。
确认系统在长期运行后性能是否稳定。
验证日志轮转、磁盘空间管理等机制

3. 场景示例

模拟 500 用户持续访问系统 24 小时。
验证日志文件是否滚动归档，避免磁盘占满。

4. 执行步骤（JMeter）

线程组设置：固定线程数（如 500），循环运行 24 小时。
使用 Garbage Collection 监控工具（如 VisualVM）观察内存趋势。
定期检查日志文件大小和数据库连接池状态。

5. 关键指标

内存使用率波动（持续增长提示内存泄漏）。
无渐进式性能下降（如每小时 TPS 下降 ≤ 1%）。
线程死锁检测。
日志错误率趋势。

6. 典型问题

JVM Full GC频率随时间增加
数据库连接池未释放导致耗尽

7. 典型案例

某社交App在连续运行72小时后，因未关闭文件句柄导致服务器崩溃。

注意

设置监控告警（如 Prometheus + Alertmanager）。
测试后执行内存快照分析（如 Eclipse MAT）。

提示

稳定性测试的三个阶段

第一个阶段：恒定压力阶段
目标是为了检验在恒定的大压力下，系统的服务是否稳定，比如是否存在吞吐量TPS指标的波动，响应延迟的抖动、毛刺等。波动情况必须在恒定的压力下进行验证，如果是波动的压力，出现吞吐量波动或者响应延迟的长尾现象会难以捕捉分析，难以区分是业务的问题还是服务的问题，为性能问题定位带来较大难度。
第二个阶段：基于一定的产品压力模型的，已上线产品
我们不难观察产品线上的典型业务及业务比例，那么在过去的七天或者一个月的时间内，产品每天的业务模型是什么样的？根据线上监控及统计不难得出。这个阶段就是为了模拟线上的这种业务模型下，也即是存在峰谷变化的压力、典型的一些Web产品每天的压力模型是比较固定的，比如每天早上9点，下午4点，晚上10点都会存在压力峰值。这种方式的模拟会为系统的稳定性带来一定的压力，如用户量突增等情况，会不会导致错误或宕机等。
第三个阶段：是在恒定压力下，引入异常干扰，注入异常用例
如CPU波动、网络延迟、主节点挂掉或重启等异常情况的出现，来充分拷打产品的稳定性和可靠性。在google的测试之道中也有提及这种模式，虽然没有更多细节暴漏出来，不过在这方面还是值得探索的。

稳定性测试怎么做，这篇文章彻底讲透了！

六、容量测试

1. 定义

通过渐进式加压，确定系统能承载的最大承载能力（用户数或数据量），为扩容提供依据。

2. 目标

找到系统的理论容量上限（如：最大TPS，最大连接数，最大并发数，最多数据条数等）。
评估硬件升级或架构优化的必要性。
制定弹性伸缩策略阈值。

3. 场景示例

逐步增加用户数，直到响应时间超过 2 秒。
填充数据库至 1TB，测试查询性能是否达标。

4. 执行步骤（JMeter）

使用 Concurrency Thread Group 逐步增加并发用户（每次 +100）。
监控数据库磁盘空间和网络带宽使用情况。
记录系统崩溃前的最大用户数或数据量。

5. 关键指标

最大支持用户数（如 8000 用户时响应时间达标）。
数据库最大存储量（如 500GB 时查询性能下降）。

6. 关键输出

服务器规格与QPS的对应关系表
数据库分库分表策略验证

7. 优化方向

水平扩展：增加服务器节点或使用云弹性伸缩。
垂直扩展：升级 CPU/内存或使用 SSD 存储。

七、其他测试类型补充

测试类型	关键点
尖峰测试	瞬时流量突增（如秒杀开始），验证系统能否快速扩容或限流。
配置测试	调整系统参数（如 JVM 堆大小），找到最优配置组合。
故障转移测试	模拟节点宕机，验证集群能否自动切换（如 Kubernetes Pod 重启）。
拓展性测试	验证系统水平/垂直扩展后的性能提升比例，常用于云原生架构。

八、测试类型对比矩阵

测试类型	负载特点	核心目标	典型指标
基准测试	单用户/低负载	建立性能基线	单请求响应时间
负载测试	逐步增加系统负载量	验证预期负载能力	TPS、错误率
压力测试	超设计负载	发现崩溃点及恢复能力	系统崩溃阈值
稳定性测试	长时间稳定负载	检测资源泄漏	内存泄漏率、线程阻塞
并发测试	高并发操作	确保数据一致性	数据冲突次数
容量测试	渐进式加压	确定最大容量	硬件资源与QPS关系

九、工具选择建议

JMeter：适合 HTTP、JDBC、JMS 等协议，支持分布式压测。
Gatling：高并发场景下性能更优，脚本用 Scala 编写。
Locust：Python 编写，适合灵活定制分布式压测。
云压测平台（如阿里云 PTS）：避免自建压力机，快速生成大规模流量。

十、工具链选择建议

快速验证场景：JMeter + Prometheus + Grafana 监控看板
复杂业务流：LoadRunner 配合 Jenkins 流水线
云原生架构：k6 结合 Kubernetes 压力注入
全链路压测：阿里云PTS + 影子数据库

十一、总结：测试策略设计

明确目标：根据业务需求选择测试类型（如电商大促前需执行负载+压力测试）。
生产环境压测：使用流量镜像和影子表避免污染真实数据。
渐进式加压：先基准测试，再逐步增加负载，逐步过渡到破坏性压力测试，避免直接高压导致系统崩溃。
监控全覆盖：从应用层（APM 工具）到基础设施（服务器资源）全面监控。
混沌工程结合：在压力测试中随机注入节点故障，验证系统韧性。
结果驱动优化：根据测试结果制定优化清单，优先级排序（如先解决数据库锁，再优化代码）。

提示

通过组合使用这些测试方法，可以全面评估系统的性能表现，为架构优化提供数据支撑。

实际项目中常采用混合策略，例如在容量测试过程中同时进行稳定性监测，或在压力测试中验证系统的并发控制机制。