测试篇-性能测试综述

性能测试方案#

明确测试目标#

业务需求：确定关键业务场景（如登录、支付、查询等）的性能指标（响应时间、吞吐量、错误率等）。
性能指标：设定基准值（如 95% 请求响应时间不超过 2 秒）、峰值（如支持 10 万用户并发）和容错能力。
非功能需求：稳定性、扩展性、资源利用率（CPU、内存、磁盘 I/O、网络带宽）等。

测试范围#

系统范围：被测系统（SUT）的边界（前端、后端、数据库、第三方服务等）。
测试类型：负载测试、压力测试、稳定性测试、容量测试等。

测试环境#

环境搭建：尽可能与生产环境一致（硬件配置、网络拓扑、数据库规模）。
数据准备：使用真实或模拟数据（需覆盖典型场景，避免数据倾斜）。

场景设计#

单场景测试：针对单一功能（如用户登录）的性能测试。
混合场景测试：模拟真实用户行为（如同时登录、下单、查询）。
峰值测试：模拟突发流量（如秒杀活动）。
稳定性测试：长时间运行（如 7×24 小时）观察内存泄漏或性能下降。

执行策略#

逐步加压：从低负载逐步增加到峰值负载，观察性能拐点。
多轮迭代：优化后重复测试，验证改进效果。

结果分析与报告#

性能基线：记录当前性能状态作为基准。
问题定位：结合日志、监控数据定位瓶颈（如数据库慢查询、代码死锁）。
优化建议：提出代码、配置或架构层面的优化方案。

性能测试关注点#

系统层面#

CPU、内存、磁盘 I/O、网络带宽的使用率。
操作系统参数配置（如 Linux 内核参数）。

应用层面#

代码执行效率（如算法复杂度、线程池配置）。
数据库性能（慢查询、索引缺失、连接池配置）。
中间件性能（如 Redis 缓存命中率、消息队列堆积）。

网络层面#

延迟、丢包率、带宽瓶颈。
CDN 或负载均衡器的性能。

业务层面#

用户并发量、TPS（每秒事务数）、RT（响应时间）。
业务成功率（如错误率不超过 0.1%）。

性能测试方法#

基准测试（Benchmark Test）#

目的：确定系统在正常负载下的性能基线。
方法：单用户或低并发场景测试。

负载测试（Load Test）#

目的：验证系统在预期负载下的表现。
方法：逐步增加并发用户数，观察响应时间和资源消耗。

压力测试（Stress Test）#

目的：找到系统性能极限和崩溃点。
方法：持续加压直至系统崩溃，记录最大承载能力。

并发测试（Concurrency Test）#

目的：验证多用户同时操作时的资源竞争问题。
方法：模拟高并发场景（如抢购）。

稳定性测试（Endurance Test）#

目的：检测长时间运行下的内存泄漏或性能衰减。
方法：持续运行 12 小时以上，观察资源占用趋势。

容量测试（Capacity Test）#

目的：确定系统最大处理能力，为扩容提供依据。
方法：逐步增加数据量或用户数，直到性能不达标。

常用性能测试工具#

负载生成工具#

JMeter（开源）：
- 支持 HTTP、JDBC、FTP 等多种协议。
- 可扩展性强，支持 BeanShell 脚本和插件。
- 适合 Web 应用和 API 测试。
LoadRunner（商业）：
- 功能全面，支持复杂场景录制和 IP 欺骗。
- 适合企业级大型系统。
Gatling（开源）：
- 基于 Scala，高性能，报告直观。
- 适合高并发场景。
Locust（开源）：
- 基于 Python，分布式压测，支持自定义脚本。
- 灵活性高。

监控与分析工具#

Prometheus + Grafana：
- 实时监控系统资源、应用指标和自定义指标。
- 可视化展示性能趋势。
APM 工具（如 New Relic、SkyWalking）：
- 追踪代码级性能问题（如慢 SQL、方法耗时）。
JVM 监控工具（如 JConsole、VisualVM）：
- 分析 Java 应用内存、线程、GC 情况。
数据库工具（如 Percona Toolkit、MySQL 慢查询日志）：
- 定位 SQL 性能问题。

云测试平台#

BlazeMeter：兼容 JMeter 脚本的云端压测服务。
AWS Load Testing：基于 AWS 的分布式压测方案。

测试场景和测试用例#

根据测试关注点#

系统层面#

1. CPU 使用率

场景：高并发用户请求导致 CPU 负载上升。
- 用例：模拟 1000 并发用户执行查询操作，持续 10 分钟。
  - 步骤：
    1. 使用 JMeter 配置 1000 线程组循环执行查询 API。
    2. 监控服务器 CPU 使用率（如通过 Prometheus+Grafana）。
  - 预期结果：CPU 使用率峰值≤80%，无持续满载现象。
  - 通过标准：CPU 未达到瓶颈，系统未崩溃。

2. 内存泄漏

场景：系统长时间运行后内存未释放。
- 用例：持续运行系统 48 小时，模拟用户登录、操作、退出流程。
  - 步骤：
    1. 使用 Locust 模拟每日活跃用户行为（如每小时 500 用户）。
    2. 监控 JVM 堆内存（如通过 VisualVM）。
  - 预期结果：内存占用曲线平稳，无持续增长趋势。
  - 通过标准：内存使用率波动在 ±5% 以内。

3. 磁盘 I/O 性能

场景：大量文件上传 / 下载导致磁盘读写瓶颈。
- 用例：模拟 100 用户同时上传 1GB 文件。
  - 步骤：
    1. 使用 JMeter 的 HTTP 请求上传大文件。
    2. 监控磁盘 IOPS 和读写延迟（如通过 Linux iostat）。
  - 预期结果：磁盘利用率≤90%，平均延迟≤50ms。
  - 通过标准：文件上传成功且无超时错误。

应用层面#

1. 数据库慢查询

场景：复杂 SQL 查询导致响应时间过长。
- 用例：执行多表关联查询（10 万条数据）。
  - 步骤：
    1. 通过应用触发查询接口，记录 SQL 执行时间。
    2. 检查 MySQL 慢查询日志是否记录该语句。
  - 预期结果：查询时间≤2 秒，慢查询日志无记录。
  - 通过标准：优化索引后查询时间下降 50%。

2. Redis 缓存命中率

场景：缓存失效导致频繁穿透到数据库。
- 用例：模拟 90% 缓存命中率的读取场景。
  - 步骤：
    1. 使用 Gatling 模拟用户高频读取热点数据（如商品详情）。
    2. 监控 Redis 的keyspace_hits和keyspace_misses指标。
  - 预期结果：缓存命中率≥90%。
  - 通过标准：数据库查询次数显著减少（如下降 80%）。

3. 线程池配置

场景：线程池过小导致请求排队。
- 用例：模拟突发流量（如 500 并发请求，线程池容量 100）。
  - 步骤：
    1. 使用 JMeter 发送 500 并发请求至后端服务。
    2. 监控线程池活跃线程数和队列堆积情况（如通过 Spring Boot Actuator）。
  - 预期结果：队列等待时间≤1 秒，无请求被拒绝。
  - 通过标准：调整线程池后吞吐量提升 30%。

网络层面#

1. 高延迟场景

场景：跨地域访问导致网络延迟增加。
- 用例：从不同地区（如美东、欧洲）调用 API。
  - 步骤：
    1. 使用 BlazeMeter 配置多地理节点压测。
    2. 测量平均响应时间（RT）。
  - 预期结果：RT≤3 秒（跨国访问）。
  - 通过标准：启用 CDN 后 RT 下降至≤1 秒。

2. 带宽瓶颈

场景：视频流媒体服务占用大量带宽。
- 用例：模拟 1000 用户同时观看 1080P 直播。
  - 步骤：
    1. 使用 LoadRunner 模拟视频流请求。
    2. 监控服务器出口带宽（如通过iftop）。
  - 预期结果：带宽利用率≤80%，无卡顿现象。
  - 通过标准：启用负载均衡后带宽分配均衡。

业务层面#

1. 高并发下单（电商场景）

场景：秒杀活动导致瞬时流量激增。
- 用例：模拟 1 万用户同时抢购 100 件商品。
  - 步骤：
    1. 使用 JMeter 配置 1 万线程在 1 秒内启动。
    2. 验证订单成功率及库存一致性。
  - 预期结果：成功订单数 = 100，无超卖或重复下单。
  - 通过标准：数据库事务隔离级别优化后无脏读。

2. 业务成功率

场景：支付接口在高负载下的错误率。
- 用例：模拟每秒 500 笔支付请求（持续 5 分钟）。
  - 步骤：
    1. 使用 Gatling 发送支付请求，监控 HTTP 状态码。
    2. 统计错误率（如 5xx 错误占比）。
  - 预期结果：错误率≤0.1%。
  - 通过标准：熔断机制触发后错误率降至 0%。

3. 混合场景性能

场景：用户同时执行登录、浏览、下单操作。
- 用例：模拟 70% 用户浏览、20% 用户加购、10% 用户支付。
  - 步骤：
    1. 使用 Locust 按比例分配行为模型。
    2. 监控整体 TPS 和 RT（如 95 分位数≤2 秒）。
  - 预期结果：TPS≥500，业务链路无阻塞。
  - 通过标准：各接口响应时间波动在 ±10% 以内。

根据测试方法#

基准测试（Benchmark Test）#

目标

确定系统在低负载或单用户场景下的性能基线，为后续测试提供对比依据。

场景

单用户操作：无并发压力，测试系统最优性能表现。
典型用例：用户登录、商品详情页加载、简单查询。

测试用例

用例 1：单用户登录响应时间

步骤：
1. 使用 JMeter 配置 1 个线程（用户），循环 10 次执行登录接口请求。
2. 记录每次请求的响应时间（RT）。
预期结果：
- 平均 RT ≤ 500ms，标准差 ≤ 50ms。
通过标准：
- 无 HTTP 错误，RT 波动在 10% 以内。

负载测试（Load Test）#

目标

验证系统在预期最大负载下的表现，如响应时间、吞吐量是否符合需求。

场景

预期并发用户：模拟日常高峰流量（如电商大促期间 5000 并发用户）。
典型用例：多用户同时下单、查询库存、支付。

测试用例

用例 2：5000 并发用户商品搜索

步骤：
1. 使用 LoadRunner 模拟 5000 用户同时执行商品关键词搜索（如 “手机”）。
2. 逐步加压：每 30 秒增加 500 用户，直至达到 5000 并发。
3. 监控指标：TPS（每秒事务数）、RT（95 分位数）、错误率。
预期结果：
- TPS ≥ 1000，RT ≤ 2 秒，错误率 ≤ 0.5%。
通过标准：
- 吞吐量稳定，无资源（CPU / 内存）持续超过 80%。

压力测试（Stress Test）#

目标

找到系统性能极限及崩溃点，验证超负载下的容错能力。

场景

超出预期负载：模拟远超设计容量的突发流量（如 10 倍日常峰值）。
典型用例：秒杀活动流量暴增、API 被恶意刷量。

测试用例

用例 3：10 万并发用户抢购压测

步骤：
1. 使用 Gatling 配置 10 万用户瞬间启动，请求秒杀接口。
2. 持续加压直至系统崩溃（如出现大量 5xx 错误或服务不可用）。
3. 记录崩溃时的并发量、错误类型及恢复时间。
预期结果：
- 系统在崩溃前至少承载 8 万并发，崩溃后 10 分钟内自动恢复。
通过标准：
- 关键服务（如订单库存）未出现数据不一致。

并发测试（Concurrency Test）#

目标

验证多用户同时操作时的资源竞争与同步问题（如死锁、数据脏读）。

场景

高竞争操作：同一资源被频繁修改（如库存扣减、账户余额更新）。
典型用例：多人同时修改同一订单、抢票场景。

测试用例

用例 4：100 用户并发修改同一商品库存

步骤：
1. 使用 JMeter 配置 100 线程同时发送 “库存扣减 1” 的请求。
2. 初始库存为 100，验证最终库存是否为 0。
3. 检查数据库事务日志是否存在死锁或超时。
预期结果：
- 最终库存 = 0，无超卖或负数库存。
通过标准：
- 数据库事务隔离级别（如使用乐观锁）有效避免脏读。

稳定性测试（Endurance Test）#

目标

检测系统在长时间运行下的性能衰减（如内存泄漏、连接池耗尽）。

场景

持续负载运行：模拟系统 7×24 小时服务，无间断处理请求。
典型用例：金融系统日终批量处理、物联网设备持续上报数据。

测试用例

用例 5：72 小时持续订单处理

步骤：
1. 使用 Locust 模拟每小时 1000 用户下单，持续 72 小时。
2. 监控 JVM 堆内存、数据库连接池使用率、线程泄漏。
3. 每 12 小时重启一次压测工具，避免工具自身资源泄露。
预期结果：
- 内存占用波动范围 ≤ 10%，无 OOM（内存溢出）错误。
通过标准：
- 吞吐量（TPS）下降幅度 ≤ 5%。

容量测试（Capacity Test）#

目标

确定系统最大处理能力（用户数 / 数据量），为扩容提供依据。

场景

数据量扩展：数据库单表数据从百万级增长到亿级。
用户量扩展：注册用户从 10 万逐步增加到 100 万。

测试用例

用例 6：亿级数据量下的查询性能

步骤：
1. 向数据库插入 1 亿条测试数据，构建复合索引。
2. 使用 JMeter 模拟 100 并发用户执行分页查询（page=10000, size=10）。
3. 监控 SQL 执行时间及磁盘 I/O。
预期结果：
- 查询时间 ≤ 1 秒，索引覆盖率达 100%。
通过标准：
- 分库分表后查询性能提升 50%。

最佳实践#

分层设计：
- 基础层：用基准测试覆盖核心接口的单用户性能（关注点：响应时间）。
- 业务层：用负载 / 压力测试验证复杂场景（关注点：吞吐量、错误率）。
- 系统层：用稳定性测试检查资源泄漏（关注点：内存、连接池）。
矩阵覆盖法：
将关注点与方法组成矩阵，确保每个关注点至少被一种方法覆盖。例如：

负载测试压力测试稳定性测试
CPU 使用率 ✅ ✅
内存泄漏 ✅
数据库性能 ✅ ✅

	负载测试	压力测试	稳定性测试
CPU 使用率	✅	✅
内存泄漏			✅
数据库性能	✅	✅