性能测试方案

明确测试目标

• 业务需求：确定关键业务场景（如登录、支付、查询等）的性能指标（响应时间、吞吐量、错误率等）。
• 性能指标：设定基准值（如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%。

最佳实践

1. 分层设计：

   • 基础层：用基准测试覆盖核心接口的单用户性能（关注点：响应时间）。
   • 业务层：用负载/压力测试验证复杂场景（关注点：吞吐量、错误率）。
   • 系统层：用稳定性测试检查资源泄漏（关注点：内存、连接池）。

2. 矩阵覆盖法：
   将关注点与方法组成矩阵，确保每个关注点至少被一种方法覆盖。例如：

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