1. 性能测试完整流程详解

1.1. 需求分析与目标确认

性能测试的目的不是要跑压测工具，而是想通过相应的手段识别系统的瓶颈，保障系统在目标场景下的稳定性和相应能力。如果没有明确的性能目标，测试结果将没有意义，优化方向也会迷失。

常见误区包括：

• “把接口压一压” 就是性能测试
• 只关注 TPS 或 QPS，而忽略资源使用、响应时间、可用性
• 没有明确的业务目标或上线场景支撑

性能测试的需求并不是测试或者研发拍脑袋决定的，通常来源于以下几个方面：

来源	内容
业务需求文档	日活量、访问高峰期预测、使用人群
历史数据	上一版本的 TPS/QPS、慢查询数据
运维指标	CPU、内存、磁盘、带宽的报警阈值
架构设计文档	分布式部署、限流策略、缓存设计
SLA/SLO 要求	如：99% 接口响应时间<200ms, 99.9% 的可用性等

1.2. 计划与场景设计

性能问题的暴露往往是一个逐层放大的过程：接口没有问题，链路之间可能有问题；链路没问题，全链路的资源争抢、瓶颈、依赖就可能暴露问题。
因此我们需要从最小颗粒度的接口开始，逐层抽象到整个业务系统，最终设计出覆盖全面、风险可控、逐层定位的性能测试场景。

1.2.1. 单接口压测

目的：验证单个接口在不同负载下的性能极限和稳定性

应用场景：

• 新开发或重构的接口
  
• 接口性能瓶颈排查
  
• 网关或中间层性能验证
  

设计要素：

• 固定参数、构造 mock 数据、动态参数，需要根据接口实现评估
  
• 并发阶梯上升测试（如 10→100→500 QPS）
  
• 分析 TPS、响应时间、错误率、资源使用情况
  

1.2.2. 单链路压测

目的：验证某一完整业务流程在负载下的性能表现

链路定义：多个接口组成一个完整用户动作路径（前后端协作逻辑链）

应用场景：

• 重点核心链路性能保障（如发送消息链路）
  
• 新业务流程上线前的性能评估
  
• 依赖系统集成验证
  

设计要素：

• 明确业务路径中每一个接口
  
• 统一会话上下文（如 token、cookie）
  
• 保证链路间逻辑与数据关联完整
  
• 并发压测模拟典型业务负载
  

1.2.3. 多链路组合压测

目的：模拟系统在真实运行中多个业务并发执行的场景

应用场景：

• 高并发、多业务并行的系统（如收发消息、云文档编辑等）
  
• 验证资源争抢、锁冲突、数据库并发能力
  
• 典型日常负载/高峰期混合负载模拟
  

设计要素：

• 链路权重配置（如收发消息 40%，文档编辑 30%，文档分享 30%）
  
• 设置不同业务比例组合并发
  
• 引入高峰期行为模拟
  

1.2.4. 全链路压测

目的：模拟生产环境真实高负载下系统全景运行状态，验证系统承压能力、瓶颈位置、异常恢复能力

应用场景：

• 上线前全链路压测
  
• 灰度环境大促演练
  
• 微服务架构压力传播路径验证
  

设计要素：

• 构造真实生产级数据（用户、商品、订单等）
  
• 覆盖所有核心业务路径
  
• 后台任务、消息队列、缓存等全部纳入
  
• 引入 Chaos、限流、降级等机制联动演练
  

典型示例：

• 模拟双 11 零点流量冲击整个系统
  
• 从用户访问首页→浏览→下单→支付→发货的全链路，打通缓存、搜索、DB、MQ、第三方接口等
  

关键关注点：

• 系统限流、熔断、降级机制是否生效
  
• 整体资源使用（带宽、内存、CPU、连接池）
  
• 异常恢复能力（如服务节点故障、网络波动）
  

1.3. 环境与数据准备

1.3.1. 环境准备

环境准备的原则：

• 真实性优先：环境应尽量接近生产，模拟出真实负载下的行为和瓶颈
  
• 隔离性保障：确保测试行为不会影响真实用户和业务数据
  
• 成本可控：压测环境不必 100% 按照生产资源规格建设，可适当缩小规模，但要评估比例影响
  
• 监控完备：监控能力必须和生产持平甚至更强，否则无法正确定位性能瓶颈
  

环境类型	特点	适用场景
生产环境压测（影子压测）	数据最真实，但风险高	核心系统灰度验证
准生产环境（beta）	与生产相似，推荐首选	上线前性能验证
独立压测环境	资源可控，安全性高	新功能验证、接口

1.3.2. 测试数据准备

性能测试的数据准备，不是随便造几条数据，而是要覆盖真实业务场景 + 满足测试维度多样性 + 可重复使用。

1. 数据维度设计

维度	说明	示例
用户数据	有效用户量、登录态	生成 x 万用户
群聊/私聊结构	群成员分布、群数量	x 人大群，x 人小群
...	内容敏感	...

2. 数据构造方法

• 离线构造脚本（推荐）：使用 Python/Golang 编写批量注册/造数脚本
  
• 数据库直接导入（需谨慎）：适合大体量测试数据
  
• Mock 服务：对依赖系统未就绪部分进行 mock 返回
  
• 动态预热脚本（常用）：每次压测前动态登录、获取 token、构建上下文
  

1.4. 脚本开发

脚本开发是连接 “性能测试需求分析” 与 “压测执行” 的桥梁环节。无论是单接口压测，还是复杂的多链路全链路压测，脚本都是整个过程的执行载体。

1.4.1. 输入准备

输入项	说明
接口定义	接口 URL、请求方式、Headers、参数结构等
用例场景	关键接口链路、参数组合、依赖顺序
数据依赖	例如接口依赖登录的 token
响应断言	是否成功（status code、字段内容等）
TPS 目标	用于设计线程数、请求频率的依据

1.4.2. 脚本设计方式（单接口→全链路）

1. 单接口：

   • 验证接口的稳定性与性能瓶颈（如登录、搜索）
     
   • 设计并发参数：用户、QPS、持续时间等
     
   • 搭配断言 + 数据文件驱动测试（如 CSV）
     

2. 单链路脚本开发：

   • 模拟一次完整操作流程，如：登录→搜索商品→下单→查询订单
     
   • 关键点：参数关联（如 token、订单 ID）、请求顺序与依赖、用户行为还原
     

3. 多链路/业务流程脚本开发：

   • 支持多个角色（买家/卖家/系统任务等）
     
   • 并行执行多个链路压测，体现真实业务压力结构
     

1.4.3. 可维护性与复用性建议

• 参数化设计：将业务参数抽出，支持脚本复用
  
• 模块化结构：按链路或模块拆分，便于组合使用
  
• 封装通用函数：如签名计算、断言逻辑、动态提取
  
• 支持回归验证：加入功能正确性断言，提前发现错误响应
  
• 敏感信息隔离：Token、密码参数放置于 config 文件或 secrets 环境变量中
  

1.5. 测试执行

根据预设场景和目标，稳定、可控地施加压力，并采集关键性能指标，辅助问题定位与性能评估。

1.5.1. 执行前准备 Checklist

项目	说明
压测环境准备	环境隔离，配置一致，监控联通
数据初始化	测试数据准备好，并且数据状态正常
服务监控接入	Prometheus/Grafana/APM 工具等
日志、链路追踪打开	包括 Nginx、应用服务、数据库慢查询
观察指标定义	RT、TPS、错误率、CPU、内存、GC 等
脚本冒烟	小流量压测验证逻辑正确性
依赖方沟通	告知被测系统负责人，避免误报警

1.5.2. 流量控制与压测模式

1. 常见压测流量模型

模型	说明	示例
恒定并发	模拟固定用户数持续操作	50 并发持续 10 分钟
阶梯增长	模拟高峰来临过程	每 5 分钟增加 10 并发
峰值冲击	快速打满系统能力	高并发短时间强打压
混合场景	多接口/多链路同时发压	收发消息，打开文件并行
波浪式	模拟系统高峰低谷流量模式	凌晨压测流量 1 倍，工 10 倍

2. 发压策略建议

• 从小流量逐步升压，观察系统响应变化；
  
• 每个阶段稳定观察 10~30 分钟，确保性能趋势稳定；
  
• 压测过程中持续观察：RT 是否持续上升？错误率是否激增？后台是否出现线程阻塞、慢查询、GC 卡顿等？
  

1.6. 结果监控与收集

压测过程的核心是采数据、看变化。以下的数据只是一小部分的维度，实际上的问题排查可能会涉及更多性能数据的分析与评估对比。

1.6.1. 监控维度

维度	指标	工具
应用层	RT、TPS、错误率、接口 P95/P99	JMeter、Locust
系统层	CPU、内存、GC、负载、磁盘 IO、网络 IO	Prometheus、Grafana
数据库	连接数、慢查询、QPS、锁等待、缓存命中率	MySQL Dashboard
中间件	Kafka TPS、Redis QPS、MQ 消息堆积	业务自研平台
链路追踪	某一请求经过的服务链路耗时分布	SkyWalking、Jaeger

1.6.2. 异常识别与瓶颈定位

问题类型	特征	定位手段
接口超时	RT 飙高，JMeter 报超时	链路追踪 + 服务日志
错误率升高	TPS 下跌，5xx、4xx 增多	日志分析 + 接口返回码
CPU 撑满	TPS 持平但延迟高	top/Grafana 观测线程
GC 卡顿	RT 波动大，GC 次数/耗时高	jstat/GC 日志分析
数据库瓶颈	连接数满、锁等待、慢 SQL	explain+slowlog 分析
缓存穿透/雪崩	Redis 请求激增，DB 被打爆	Redis 监控/fallback

1.7. 分析与报告

在这里的核心目标是：  
1. 汇总并分析压测期间的关键性能指标  
2. 发现性能瓶颈，定位异常  
3. 评估系统是否满足业务性能目标  
4. 为优化和容量规划提供决策依据  
5. 对外形成结构清晰、结论明确的性能测试报告  

1.7.1. 压测结果的核心指标分析

1. 压测数据指标

指标	说明	分析关注点
TPS/QPS	每秒处理请求数	是否达到预期目标
响应时间（RT）	平均、P90、P95、P99	是否符合 SLA 要求
成功率	有效响应数/总请求数	是否出现错误
错误率	5xx/超时/断言失败等	哪些类型最多？集中在哪？
并发数	实际活跃线程数	压力是否真实落到系统

2. 系统服务资源

指标	说明	分析关注点
系统资源	CPU、内存、IO、网络流量、连接数等	有无资源瓶颈

3. 中间件核心性能指标

Redis（缓存）

指标	说明
instantaneous_ops_per_sec	每秒命令执行数（类似 QPS）
keyspace_hits/misses	命中率，命中低代表缓存不生效
latency	响应时间，高峰期时尤为重要
used_memory_rss, used_memory_peak	实际占用内存，是否接近上限
connected_clients	当前连接数，是否稳定，是否打满
evicted_keys, expired_keys	是否频繁淘汰，是否存在热点键被清除问题

MySQL（数据库）

类别	指标
性能	Queries, QPS, Slow_queries
性能	Threads_running
资源	CPU, Buffer pool usage, IO wait
连接	Threads_connected, Max_used_connections
异常	InnoDB row lock wait, Deadlocks

1.8. 优化与验证

“优化与验证”是承上启下的关键模块，目标是根据压测分析结果，驱动系统调优并验证优化是否有效，确保最终上线版本性能稳定、可支撑预期业务量。

以后再细聊吧

2. 性能测试场景设计精髓

性能测试的成败，很大程度上取决于场景设计的科学性与贴合实际业务的能力。设计合理的场景不仅能发现真实瓶颈，还能评估系统是否具备承接未来增长的能力。

2.1. 识别关键业务场景（用户旅程）

常见识别方式：

• 业务日志分析（如接口调用量、慢接口）
  
• 产品功能矩阵分析
  
• 用户核心操作路径（注册→浏览→下单→支付）
  
• 报警日志/问题记录回溯（历史抖动点）
  
• 新业务或核心流程变更部分优先保障
  

示例：IM 系统

• 登录鉴权→获取好友列表→获取历史消息→发消息→收消息→群发
  

2.2. 设计负载模型

负载模型决定了压测目标和策略。应根据业务发展阶段、测试目的不同，匹配不同类型的压测模型。

2.2.1. 负载测试（阶梯式、波浪式）

目的：模拟真实业务压力下的系统表现

• 阶梯式增长（线性上涨，观察系统是否能逐步抗压）
  
• 波浪式压力（高低起伏模拟真实日常高峰、波谷）
  适用：日常容量验证、上线前回归测试等
  

2.2.2. 压力测试（摸高）

目的：突破系统瓶颈上限，发现故障点

• 施加超过正常预期的负载
  
• 观察 TPS 崩溃点、错误率、系统反应（降级 or 崩溃）
  适用：容量规划、服务保护策略验证
  

2.2.3. 稳定性测试

目的：验证系统在长时间运行下的稳定性

运行 8h~72h 不等，重点关注内存泄漏、连接泄漏、数据积压，其实我们跑的是 7*24 小时。

2.2.4. 并发测试

目的：验证系统对并发突发请求的处理能力

一般用于秒杀、拼团等突发流量场景

要求场景中包含随机性、冲突性（如同一个商品库存扣减）

2.3. 模拟真实用户行为

2.3.1. 用户分布

• 模拟不同角色/客户端/地区/终端比例
  
• 如 IM：普通用户：运营账号=95:5；移动端：Web 端=9:1
  避免单一用户压爆系统，影响结果真实性
  

2.3.2. 数据参数化

• 用户 ID、Token、订单号等避免重复数据导致缓存命中、幂等化绕开问题。
  
• 支持动态生成、从 CSV/数据库中加载。
  

2.3.3. 接口关联

• 登录→获取 token→用 token 访问后续接口
  
• 场景逻辑需要前后数据串联，如订单创建后的订单 ID→查询支付状态
  

2.3.4. 设计有效的断言和事务

• 判断接口响应是否成功、关键字段是否存在
  
• 防止 “压测跑通了，业务其实报错”
  
• 建议使用响应码 + 响应值校验双保险