美食预订应用压力测试中带依赖关系的线程并行执行方案咨询

核心改造思路 #

放弃原有的按操作类型拆分独立线程组的设计，改为按单用户业务生命周期设计执行链路，全局仅保留1个前置线程做公共准备工作，所有虚拟用户各自按业务顺序串行执行操作，多个虚拟用户同时启动即可实现「整体操作并发、单用户链路有序」的真实业务场景效果。

具体实现步骤 #

• 调整全局前置逻辑：将原Thread0改为仅执行1次的全局前置线程（如JMeter的Setup线程组），批量生成所有测试用户需要的token，存入全局变量池供后续虚拟用户按需取用，不要把单个token设为全局变量避免串用。
• 重构单用户业务执行流：把原Thread1~Thread4的操作按业务依赖顺序整合为单用户链路，每个步骤产生的参数仅存在当前用户的局部作用域：
  1. 执行餐品菜单相关操作，提取餐品ID、菜单ID等参数存入用户局部变量
  2. 读取上一步的餐品参数，执行加购、金额计算操作，提取购物车ID、计算金额存入局部变量
  3. 读取上一步的购物车、金额参数，执行创建订单操作，提取订单ID存入局部变量
  4. 读取上一步的订单ID，执行确认订单操作
• 配置并发规则：将整合后的单用户链路线程组的并发数设置为目标压力值，如需阶梯加压可配置并发爬升周期，不同虚拟用户的执行进度天然不同，即可模拟出「部分用户看菜单、部分用户加购、部分用户确认订单」的真实并发场景。

关键注意事项 #

• 严格区分全局变量和用户局部变量：全局变量仅存储所有用户通用的配置类参数，每个用户链路产生的业务参数必须存在当前用户的局部作用域，避免不同用户之间参数串扰导致业务报错。
• 可在每个操作步骤之间添加随机思考时间（1~3秒），更贴合真实用户的操作习惯，压力测试结果更接近实际生产表现。
• 如果需要单独统计每个操作的性能指标，可给每个步骤加独立的事务控制器，后续报表可以单独查看每个接口/操作的响应时间、成功率数据。

示例（JMeter配置逻辑） #

测试计划
├── Setup线程组（原Thread0逻辑，线程数1，循环1次）
│   ├── 批量登录接口
│   └── 提取所有用户token存入全局属性tokenList
└── 业务压力线程组（并发数按测试需求设置）
    ├── 计数器：按序号取tokenList里的token作为当前用户的请求头
    ├── 事务控制器：菜单查询（原Thread1逻辑）
    │   ├── 菜单查询请求
    │   └── 提取餐品ID存入局部变量meal_id
    ├── 事务控制器：加购算价（原Thread2逻辑）
    │   ├── 加购请求（参数传${meal_id}）
    │   └── 提取购物车ID存入局部变量cart_id
    ├── 事务控制器：创建订单（原Thread3逻辑）
    │   ├── 创建订单请求（参数传${cart_id}）
    │   └── 提取订单ID存入局部变量order_id
    └── 事务控制器：确认订单（原Thread4逻辑）
        └── 确认订单请求（参数传${order_id}）

内容的提问来源于stack exchange，提问作者Shankar PK