1. 项目概述为什么需要“分组并发”在性能测试的世界里我们常常会听到“并发用户数”这个概念。很多新手会简单地认为设置100个线程就是模拟100个用户同时向服务器发起攻击。但现实中的用户行为远比这复杂。想象一下一个电商平台的秒杀场景一部分用户在疯狂刷新商品页面一部分用户在提交订单还有一部分用户可能在浏览其他商品或填写收货地址。这些用户的行为模式、请求路径和服务器压力点是截然不同的。如果我们只是简单粗暴地用100个线程去重复请求同一个商品详情页得到的测试结果很可能失真无法真实反映系统在混合业务场景下的承载能力。这就是“分组并发”要解决的问题。它不是一个JMeter内置的、名叫“分组并发”的组件而是一种测试策略和设计思路。其核心思想是将虚拟用户线程按照不同的业务角色或行为模式进行分组为每个组配置独立的并发策略、执行逻辑和断言规则从而模拟出更贴近真实生产环境的复杂负载场景。我遇到过不少项目在测试时接口单独压测都表现良好但一上线就出现各种性能瓶颈根源往往就在于测试场景过于单一没有模拟出用户行为的“混合”与“交错”。掌握分组并发意味着你的性能测试从“小学生做算术”进阶到了“解多元方程”能更精准地定位系统瓶颈比如是商品查询服务扛不住还是订单服务先崩溃。2. 核心思路拆解构建分组的逻辑与架构要实现分组并发我们需要在JMeter中搭建一个清晰的逻辑架构。核心在于利用JMeter的线程组作为天然的分组容器。每一个线程组都可以视为一类具有相同行为特征的用户群。2.1 分组维度与策略选择在动手之前必须先想清楚“按什么来分”。常见的分组维度有业务角色这是最直观的维度。例如浏览用户组只执行商品列表查询、商品详情查看等读操作请求频率高但逻辑简单。购物车用户组执行添加商品到购物车、查看购物车等操作涉及少量的写操作。下单用户组执行提交订单、支付等核心事务操作对数据库和事务一致性要求最高是压力测试的重点。用户行为流模拟一个完整业务流程中不同阶段的用户。例如在注册流程中可以分成“填写信息组”、“获取验证码组”、“提交注册组”。流量配比根据生产环境的监控数据或业务预估设定不同组之间的线程数比例。例如通常浏览用户远多于下单用户比例可能是浏览组:购物车组:下单组 7:2:1。实操心得不要一开始就追求复杂的多组混合。建议从2个组开始例如“只读组”和“读写混合组”先验证测试脚本和分组逻辑的正确性。分组越多测试结果的分析复杂度呈指数级上升。2.2 JMeter测试计划结构设计一个典型的分组并发测试计划结构如下所示在JMeter GUI中的树状结构测试计划 ├── 线程组浏览用户 (线程数70, Ramp-Up: 10, 循环次数永远) │ ├── HTTP请求默认值 (配置服务器、端口等) │ ├── CSV 数据文件设置 (读取浏览用户账号) │ ├── 事务控制器浏览会话 │ │ ├── HTTP请求获取首页 │ │ ├── 固定定时器 (思考时间2秒) │ │ ├── HTTP请求搜索商品 │ │ └── HTTP请求查看商品详情 │ └── 监听器 (仅本组)查看结果树、聚合报告 ├── 线程组下单用户 (线程数10, Ramp-Up: 30, 循环次数100) │ ├── CSV 数据文件设置 (读取下单用户账号含登录信息) │ ├── HTTP请求用户登录 (用于提取token) │ ├── 正则表达式提取器 (或JSON提取器) (提取登录token) │ ├── 事务控制器下单流程 │ │ ├── HTTP请求添加购物车 (携带token) │ │ ├── HTTP请求创建订单 (携带token) │ │ └── HTTP请求模拟支付 (携带token) │ └── 监听器 (仅本组)聚合报告、响应时间图 └── 监听器 (全局)聚合报告、TPS曲线图、服务器性能监控图关键点解析独立的线程组每个组是独立的并发执行单元拥有自己的线程数、启动时间和循环逻辑。差异化的配置“浏览组”的Ramp-Up时间较短模拟用户快速涌入而“下单组”的Ramp-Up时间较长因为实际下单用户不会在瞬间爆发。循环次数也不同浏览行为可能持续更久。数据隔离使用不同的CSV文件为不同组准备测试数据防止数据冲突如多个线程用同一账号下单导致锁冲突。监听器作用域部分监听器如查看结果树可以放在线程组内只查看该组请求详情便于调试。全局监听器则用于评估整体性能。3. 核心细节解析与实操要点理解了架构我们来看看实现分组并发时需要特别注意的几个技术细节这些细节直接决定了测试的逼真度和有效性。3.1 参数化与数据隔离让每个用户“独立”行动参数化是性能测试的基石在分组并发中尤为重要。你必须确保不同组的用户以及同一组内的不同用户使用的是独立的数据集避免因共享资源如同一个商品ID、同一个用户账号导致测试失真。实现方案为每个线程组准备独立的CSV文件browse_users.csv: 包含大量用于浏览的用户ID或随机标识。order_users.csv: 包含具有下单权限的真实用户账号、密码。在“CSV 数据文件设置”中正确配置文件名指向对应的CSV文件。变量名称定义为如browse_user,order_user,order_pwd。遇到文件结束符再次循环?对于浏览用户通常选择True因为浏览行为可以无限循环。对于下单用户如果数据量有限可以选择False并在线程组设置有限的循环次数模拟真实用户池。遇到文件结束符停止线程?对于下单这类关键业务建议设为True确保测试在可用数据用尽后优雅停止而不是报错。注意绝对不要在多个线程组中共用同一个CSV文件配置除非你非常清楚自己在做什么比如模拟多组用户抢购同一批商品。这极易导致数据读取错乱和不可预知的测试行为。3.2 定时器与思考时间模拟真实用户节奏用户不是机器人操作之间会有间隔。在分组并发中不同用户组的“思考时间”模式也不同。浏览用户组操作间隔较短且随机。适合使用随机定时器Gaussian Random Timer或均匀随机定时器Uniform Random Timer。例如在每次页面请求后添加一个“固定定时器均匀随机定时器”模拟用户阅读页面内容的时间。下单用户组流程性更强每个步骤登录、加购、下单、支付之间的间隔可能有一定规律但也会有变化。可以在关键事务步骤间添加固定的思考时间再辅以随机定时器。配置示例浏览组事务控制器: 浏览会话 ├── HTTP请求: 获取首页 ├── 固定定时器 (1000毫秒) // 基础等待时间 ├── 均匀随机定时器 (随机延迟最大值2000毫秒) // 在0-2秒内随机等待 └── HTTP请求: 搜索商品实操心得不要忽略思考时间它直接影响测试的并发压力和吞吐量TPS计算结果。一个设置了合理思考时间的测试其TPS更能反映系统在真实用户访问模式下的处理能力。压测时可以通过调整或移除定时器来进行“压力极限”测试。3.3 关联与状态保持让会话“活”起来对于需要登录的组如下单组关联是必须的。你需要从登录响应中提取Token、Session ID等认证信息并传递给后续请求。提取器选择正则表达式提取器适用于提取HTML或文本响应中的内容通用性强但编写稍复杂。JSON提取器如果响应是JSON格式这是最佳选择语法简单直观。边界提取器适用于提取左右边界明确的内容。变量作用域在JMeter中提取的变量默认作用域是当前线程即单个虚拟用户。这正好符合我们的需求每个用户保持自己的会话状态。确保将提取器放在登录请求的子层级。传递方式在后续需要认证的请求中在HTTP头管理器或参数中使用${变量名}的格式引用提取到的值。示例下单组的登录与关联线程组: 下单用户 ├── HTTP请求: POST /api/login │ └── JSON提取器 │ │ 变量名称: auth_token │ │ JSON Path表达式: $.data.token ├── HTTP请求: POST /api/cart/add │ └── HTTP信息头管理器 │ │ Authorization: Bearer ${auth_token}4. 实操过程与核心环节实现下面我们以一个简化的电商场景为例手把手搭建一个包含“浏览用户”和“秒杀用户”两个组的分组并发测试。4.1 环境与数据准备创建测试数据文件在JMeter的bin目录下创建test_data文件夹。创建browse_data.csv内容如下仅一列模拟用户标识browse_id user_001 user_002 ... (可生成数百行)创建seckill_data.csv内容如下需要真实的可登录账号username,password,product_id test1example.com,pass123,10086 test2example.com,pass123,10086 ... (账号数量约等于秒杀线程数)启动JMeter创建新的测试计划。4.2 构建“浏览用户组”添加线程组右键测试计划 - 添加 - 线程用户 - 线程组。名称改为01-浏览用户组。线程数50 模拟50个并发浏览用户。Ramp-Up时间5 5秒内启动所有50个线程每秒启动10个。循环次数勾选“永远”。添加CSV数据文件设置右键01-浏览用户组- 添加 - 配置元件 - CSV 数据文件设置。文件名${__P(user.dir)}/test_data/browse_data.csv(使用属性引用相对路径更灵活)。变量名称browse_id。其他选项默认。添加HTTP请求默认值可选简化配置右键01-浏览用户组- 添加 - 配置元件 - HTTP请求默认值。服务器名称或IP填写你的测试服务器地址。端口号如 8080。构建浏览业务流程使用事务控制器组织右键01-浏览用户组- 添加 - 逻辑控制器 - 事务控制器。命名为“浏览流程”。在事务控制器下添加第一个HTTP请求名称首页访问。路径/index.html。方法GET。添加固定定时器线程延迟设为2000毫秒。添加第二个HTTP请求名称搜索商品。路径/api/product/search。方法GET。参数keyword手机。添加随机定时器随机延迟最大值设为3000毫秒。添加第三个HTTP请求名称查看商品详情。路径/api/product/${browse_id}(这里用浏览ID模拟不同商品实际中可从搜索响应提取)。方法GET。4.3 构建“秒杀用户组”添加第二个线程组右键测试计划 - 添加 - 线程用户 - 线程组。名称02-秒杀用户组。线程数20 模拟20个抢购用户。Ramp-Up时间2 秒杀场景用户瞬间涌入。循环次数1 每个用户只抢一次。添加CSV数据文件设置文件名指向seckill_data.csv。变量名称username,password,product_id(与CSV列头对应)。“遇到文件结束符停止线程”True。添加同步定时器右键02-秒杀用户组- 添加 - 定时器 - Synchronizing Timer。模拟用户组的数量20 与线程数一致。这是实现“绝对并发”的关键。它会让这20个线程在到达这个定时器时等待直到凑齐20个再同时释放发起下一个请求完美模拟秒杀瞬间。构建秒杀业务流程HTTP请求登录。提取token。添加同步定时器位置在登录之后秒杀请求之前。HTTP请求秒杀请求。路径/api/seckill/${product_id}。方法POST。添加HTTP信息头管理器Authorization: Bearer ${auth_token}。可选添加响应断言检查秒杀是否成功。4.4 配置监听器与执行为每个组添加独立的聚合报告分别右键两个线程组 - 添加 - 监听器 - 聚合报告。这样可以清晰对比两组业务的性能表现如浏览的TPS高但秒杀的响应时间长、错误率高。添加全局监听器右键测试计划 - 添加 - 监听器 -Summary Report(汇总报告) 和Active Threads Over Time(随时间活动线程数)。Active Threads Over Time图表可以直观展示两个线程组的并发用户数随时间的变化情况验证分组并发是否按预期执行。保存并运行测试点击运行按钮。观察两个线程组是否按各自的节奏启动和执行。通过查看结果树调试时用和聚合报告来分析结果。5. 常见问题与排查技巧实录在实际操作分组并发时你会遇到各种“坑”。下面是我总结的一些典型问题及解决方法。5.1 问题线程组执行顺序混乱或不符合预期现象测试开始后感觉所有请求混在一起看不出分组效果。排查检查测试计划面板上的选项“独立运行每个线程组”是否被勾选。如果勾选JMeter会完全执行完第一个线程组再开始执行第二个。对于需要模拟混合场景的分组并发这个选项通常不勾选让所有线程组同时启动。检查各线程组的Ramp-Up时间。如果“浏览组”的Ramp-Up是100秒而“秒杀组”是10秒那么秒杀组的用户会先全部启动完毕浏览组的用户还在缓慢增加。这符合某些场景但需确认是否符合你的测试设计。技巧使用Active Threads Over Time监听器是验证各组并发负载曲线是否符合设计的最佳工具。5.2 问题不同组之间的变量互相干扰现象A线程组定义的变量在B线程组的请求中被引用导致错误或数据错乱。原因JMeter变量默认是线程局部的但通过__setProperty和__P函数可以设置全局属性。如果误用了全局属性会导致干扰。解决严格隔离确保每个线程组使用自己独立的CSV数据文件和变量命名空间。变量名可以加前缀区分如browse_id,order_user。谨慎使用BeanShell/JSR223在这些脚本中修改变量时明确指定作用域。避免无意中修改了全局属性。调试方法使用Debug Sampler和View Results Tree监听器查看每个请求发出前该线程所拥有的所有变量值确认是否混入了其他组的变量。5.3 问题同步定时器导致线程卡死现象使用了同步定时器的线程组测试运行后一直等待不结束。原因同步定时器的“模拟用户组的数量”设置大于该线程组当前存活的线程数。比如设置了等待50个线程但该线程组因为循环结束或错误只剩下30个活跃线程那么这30个线程会永远等下去。解决确保“模拟用户组的数量”小于等于线程组的线程数。在秒杀场景中通常设置为等于线程数。为同步定时器设置超时时间默认是0无限等待。可以设置一个合理的超时如30000毫秒超时后未凑齐的线程会继续执行。关键技巧对于循环次数1的线程组使用同步定时器要格外小心。每次循环都会经过定时器如果第一次循环后就有线程因错误退出第二次循环就可能永远凑不齐。因此同步定时器通常用于只执行一次的场景如秒杀或需要精确控制每次循环并发点的场景。5.4 问题测试结果聚合报告数据解读困难现象得到了多份报告不知道如何综合评估系统整体性能。解决分层分析先看每个线程组独立的聚合报告了解各组业务的性能基线平均响应时间、TPS、错误率。再看测试计划级别的汇总报告了解整体吞吐量和总请求数。关联分析当“下单组”的错误率飙升时观察“浏览组”的响应时间是否也同步变长。如果是说明瓶颈可能出现在数据库连接池、网络带宽或某个共享服务如Redis上。使用Transactions per Second和Response Times Over Time等监听器将两个线程组的曲线叠加在同一时间轴上可以直观看到业务混合负载下的相互影响。定义复合指标例如你可以定义一个“核心事务成功率”下单成功请求数 / 总的下单请求数* 100%。在混合场景下即使整体请求成功率高但这个指标可能很低这就精准定位了问题。5.5 性能测试资源监控遗漏现象测试结果显示响应时间变慢但不知道是应用服务器CPU满了还是数据库锁等待严重。技巧分组并发测试时资源监控更要细化。如果可能为不同业务组打上不同的标签Tag。例如在请求的Header或参数中添加X-Biz-Group: Browse或X-Biz-Group: Order。在应用日志和监控系统如GrafanaPrometheus中可以根据这个标签来分别统计不同业务组的请求量、耗时和对应的服务器资源CPU、内存、数据库连接数。这样当性能下降时你可以明确地说“在混合负载下当浏览QPS达到1000时下单业务的数据库CPU使用率达到了90%导致其响应时间从200ms恶化到2000ms。” 这样的结论对于开发团队优化具有直接的指导意义。分组并发不是JMeter的一个功能开关而是一种综合运用线程组、定时器、控制器、配置元件和监听器来构建复杂场景的测试设计能力。它要求测试人员不仅熟悉工具操作更要理解业务逻辑和系统架构。从简单的两组对比开始逐步增加复杂度持续观察和分析结果你就能设计出越来越逼真、有效的性能测试场景真正让性能测试成为系统稳定性的守护者。