JMeter业务流程压测

一、什么是业务流程压测

业务流程压测，是指按照真实用户的操作路径，把多个接口串起来进行压测。

例如电商系统中，一个真实用户可能会这样操作：

登录
→ 浏览商品
→ 查看商品详情
→ 加入购物车
→ 提交订单
→ 支付

如果你只压其中一个“下单接口”，结果往往不真实，因为真实业务中：

下单前要登录
下单前要查商品
下单时要校验库存
下单后可能还要支付

所以：

业务流程压测，本质上是在模拟真实用户行为链路，而不是单个接口。

二、为什么单接口压测不够

很多初学者一开始只会这样做：

1000个线程
一直压 /api/order/create

这样虽然能测出接口极限，但不能代表真实生产流量。

原因有几个：

1. 缺少上下文依赖

真实请求通常依赖前置数据，例如：

token 来自登录
productId 来自商品查询
cartId 来自购物车接口
orderId 来自下单接口

如果这些前置步骤没有执行，单压一个接口的数据就不完整。

2. 流量结构失真

真实业务中，不同接口流量占比不同。

例如电商系统：

浏览商品 70%
查看详情 20%
下单 8%
支付 2%

如果你只压支付接口，就完全不符合线上情况。

3. 瓶颈判断会偏差

真实链路里，瓶颈可能不在你压的那个接口，而在链路前后的依赖系统中，例如：

登录服务
商品服务
Redis
数据库
消息队列

所以企业级压测必须做 流程压测。

三、业务流程压测的目标

业务流程压测主要解决以下问题：

1. 验证系统整体链路性能

不是只看某一个接口，而是看完整流程能否跑通、是否稳定。

2. 模拟真实业务流量结构

让压测更接近线上真实访问模式。

3. 发现跨服务瓶颈

例如：

登录很快，但下单很慢
下单很快，但支付依赖第三方导致整体 RT 高
某一步数据库锁竞争严重

4. 评估系统端到端承载能力

例如：

系统每秒能支撑多少真实下单用户

这个比单接口 QPS 更有业务价值。

四、JMeter业务流程压测的基本结构

一个典型的业务流程压测脚本，结构通常是：

Test Plan
 └ Thread Group
     ├ CSV Data Set Config
     ├ HTTP Header Manager
     ├ Login API
     │   └ JSON Extractor(token)
     ├ Search Product API
     │   └ JSON Extractor(productId)
     ├ Add Cart API
     │   └ JSON Extractor(cartId)
     ├ Create Order API
     │   └ JSON Extractor(orderId)
     ├ Pay API
     ├ Assertions
     └ Listeners

这里面你会发现，前面学过的内容全都串起来了：

参数化
关联
请求头管理
断言
监听器

所以第 10 篇，其实是在整合前面第 6 到第 9 篇的能力。

五、一个真实电商流程示例

下面我们用一个简化的电商流程来说明。

步骤1：登录

请求：

POST /api/login

{
  "code": 200,
  "token": "abc-token"
}

处理方式：

使用 JSON Extractor 提取 token
保存为 ${token}

步骤2：查询商品列表

请求：

GET /api/product/list
Authorization: Bearer ${token}

{
  "code": 200,
  "data": [
    { "productId": 1001 },
    { "productId": 1002 }
  ]
}

处理方式：

提取 productId
保存为 ${productId}

步骤3：加入购物车

请求：

POST /api/cart/add
Authorization: Bearer ${token}

{
  "productId": "${productId}",
  "count": 1
}

{
  "code": 200,
  "cartId": "cart123"
}

处理方式：

提取 cartId
保存为 ${cartId}

步骤4：创建订单

请求：

POST /api/order/create
Authorization: Bearer ${token}

{
  "cartId": "${cartId}"
}

{
  "code": 200,
  "orderId": "order999"
}

处理方式：

提取 orderId
保存为 ${orderId}

步骤5：支付

请求：

POST /api/pay
Authorization: Bearer ${token}

{
  "orderId": "${orderId}"
}

六、如何设计真实的流量比例

企业里做流程压测时，不是每个步骤都按 100% 执行。

因为真实用户行为不是完全一致的。

例如：

登录 100%
浏览商品 100%
加入购物车 30%
下单 10%
支付 8%

也就是说：

100 个人登录
100 个人浏览
30 个人加入购物车
10 个人下单
8 个人支付

这才更接近真实业务。

在 JMeter 中，这类比例控制通常通过以下方式实现：

Throughput Controller
If Controller
Random Controller

七、常见控制器在流程压测中的作用

1. Simple Controller

用于组织脚本结构，让流程更清晰。

例如：

登录模块
商品模块
订单模块
支付模块

2. Transaction Controller

用于统计一整段业务流程的总耗时。

例如：

下单流程总耗时
= 加购 + 创建订单 + 支付

这在企业里非常重要，因为老板和业务方往往关心的是：

一个完整下单流程耗时多少

而不是某个单独接口耗时多少。

3. Throughput Controller

用于控制某一分支执行比例。

例如：

30%用户加入购物车
10%用户下单

这个组件是做业务流量建模的关键。

八、事务与单接口的区别

在流程压测里，要区分两种指标：

1. 接口级指标

例如：

登录接口 RT
查询商品 RT
下单接口 RT

2. 事务级指标

例如：

登录到下单整条链路耗时
下单到支付完整事务耗时

企业里通常两者都要看：

接口级指标用于定位瓶颈
事务级指标用于衡量业务体验

九、企业级脚本设计原则

做业务流程压测时，建议遵循以下原则。

1. 尽量贴近真实用户行为

不要为了图省事，把流程压成一个接口。

2. 数据必须真实可用

例如：

登录账号足够多
商品数据足够多
库存数据不能全一样
避免所有线程抢同一个订单号

3. 每一步都要校验结果

例如：

登录是否成功
商品是否查到
购物车是否创建成功
订单是否创建成功

否则前一步失败，后面全是脏数据。

4. 不要忽略思考时间

真实用户操作之间通常有停顿，例如：

登录后会浏览几秒
看商品详情要几秒
确认订单也要时间

所以可以通过 Timer 模拟 think time。

例如：

浏览商品后等待 2~5 秒

5. 要能分模块定位问题

如果流程太大、结构太乱，出了问题很难定位。

建议把脚本拆成模块：

登录模块
商品模块
购物车模块
订单模块
支付模块

十、业务流程压测常见问题

1. 前置接口失败，后续全部失败

例如登录失败后没有 token，后面所有接口都 401。

解决方式：

增加断言
增加调试监听器
在失败时中断当前线程逻辑

2. 数据被重复消费

例如：

同一个商品库存被抢光
同一个订单被重复支付
同一个用户重复提交

解决方式：

做好测试数据隔离
使用唯一 ID
准备充足测试数据

3. 流量模型不合理

例如所有用户都直接下单，没有浏览行为。

这样虽然压测能跑，但与真实业务严重不符。

4. 压测结果无法解释

例如流程整体 RT 高，但不知道是哪一步慢。

解决方式：

同时看事务级和接口级指标
给关键步骤加 Transaction Controller
配合服务端监控一起看

十一、一个推荐的电商压测模型

你可以先用一个简单版本练手：

场景A：普通用户浏览

登录 → 浏览商品列表 → 查看详情

占比：

70%

场景B：购物车用户

登录 → 浏览商品 → 加入购物车

占比：

20%

场景C：下单用户

登录 → 浏览商品 → 加购 → 下单

占比：

8%

场景D：支付用户

登录 → 浏览商品 → 加购 → 下单 → 支付

占比：

2%

这是一个很典型的企业流量模型雏形。

十二、总结

JMeter 业务流程压测，是把多个接口按照真实业务顺序串联起来进行压测。

它相比单接口压测，更接近企业真实场景，因为它能模拟：

真实用户行为
真实数据依赖
真实流量比例
真实业务链路

一个完整流程压测通常会结合这些能力：

参数化
接口关联
断言
Timer
Controller
事务统计