了解JMeter的朋友都知道，它不仅能做简单的接口测试、还支持性能测试。接口类型不仅支持Rest、SOAP，也可扩展WebSocket、Socket等。无论你用Jmeter做哪种测试，哪种接口类型，哪种网络协议，你都必须添加使用Jmeter线程组，线程组在Jmeter中占据主导地位，它是任何一个测试计划的起点，所有的逻辑控制器、采样器、处理器、报告等都必须放在线程组之下，也就是说你若使用Jmeter做接口测试或性能测试，那么线程组是必不可少的。本文分为三个方面为大家介绍Jmeter的线程组，主要从：线程组介绍、线程组设置、线程组分类三方面来阐述。
一、线程组介绍
线程组元件是任何一个测试计划的开始点。在一个测试计划中的所有元件都必须在某个线程组下。所有的任务都是基于线程组：
通俗理解：
- 线程组：就是一个线程组，里面有若干个请求;
- 线程：一个线程就是一个“虚拟用户”;
- 请求：一个线程组里面有若干个请求。
对应关系：
例如：1个线程组里面有10个请求，线程数为10个，跑完后得到：
理解为：(10个线程数)10个人，每个人都要跑这10个请求，所以：10*10=100：
并发数：100;线程数：10;
PS：线程组也可以看作是一个虚拟用户组。线程组中的每一个线程都可以理解为一个虚拟用户。
二、线程组设置
我们把线程组的设置分成3个区域：
区域一：在采样器失败后怎么处理(LoadRunner里面也有类似的运行设置选项，对比去学习)
1、continue：继续执行接下来的操作;
2、Start Next Thread Loop：开始下一次循环;
3、stop Thread：停止线程，退出该线程(不再执行此线程的操作);
4、stop Test：等待当前执行的采样器结束后，结束整个测试;
5、Stop Test Now：马上停止测试。
区域二：线程属性
1、Number of Threads(users)：线程数，相当于模拟的用户数量;
2、Ramp-up Period(in seconds)：达到指定线程需要的时间，例如线程数为100，时间设定为10s，那么就是10s加载100个线程，每秒启动的线程数=100/10=10;
3、Loop Count：如果填具体的数值，就是循环对应的次数;如果选择“Forever”，则一直执行下去，直到手动停止;
4、Delay Thread creation until needed：延迟线程创建，直到需要才创建。
区域三：调度器配置
需要选中调度器(scheduler)，调度器配置才生效。
【实例】现用一个普通的线程组测试一个简单的http接口测试，测试前添加设置下线程组及其他元件：
第一步：添加一个线程组，添加后选择采样器。因接口、报文或外部等原因导致接口执行错误后的一个后置行为，对于各个选项多选一，目前我选择接口执行错误后让其继续执行。
第二步：因为非性能测试，所以线程组设置1即可，即是单个“虚拟用户”。
第三步：关于调度器配置不同版本的Jmeter会有不同的改动，目前Jmeter版本V5.1.1调度器配置在原有的基础上容易理解和执行，使用调度器之前需“开启”调取度按钮(点击打勾即可)，按照功能提示选择接口的启动延迟时间和持续时间。注意：使用调度器后中间循环次数则作废。
第四步：添加http请求并设置域名、路径等并填入请求报文;(添加路径：线程组→添加→取样器→HTTP请求)
第五步：添加HTTP信息头管理器，用于存储request的head部分，并写入对应接口的request的head部分：(添加路径：线程组→添加→配置原件→HTTP信息头管理器)
最后就可以添加察看结果树，然后点击运行就可以看到结果了!(添加路径：线程组→添加→监听器→察看结果树)
三、线程组分类
从系统的角度来看，Jmeter的线程组主要分为系统原生线程组和可拓展线程组。原生线程组配合调度器、定时器、前后置处理器和逻辑控制器等等已经可以满足大部分测试的需求，但是若要求多维度来设计用户并发数，原生线程组已经不能满足需求。此时，我们可以新增插件的线程组使其更加强大，可自定义设置多种场景等功能，可以更加接近真实用户的使用场景。
(一)原生线程组
1、thread group(线程组)
这个就是我们通常添加运行的线程。通俗来讲一个线程组，可以看做一个虚拟用户组，线程组中的每个线程都可以理解为一个虚拟用户。上文所介绍使用的例子就是此线程组。
2、setup thread group(设置线程组)
一种特殊类型的ThreadGroup，可用于执行预测试操作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试前进行定期线程组的执行;类似LoadRunner的init，测试开始时进行初始化的工作。
不同的是执行顺序---它会在普通线程组执行之前被触发。
应用场景举例：
A、测试数据库操作功能时，用于执行打开数据库连接的操作。
B、测试用户购物功能时，用于执行用户的注册、登录等操作。
3、teardown thread group(拆线组)
一种特殊类型的ThreadGroup，可用于执行测试后动作。这些线程的行为完全像一个正常的线程组元件。不同的是，这些类型的线程执行测试结束后执行定期的线程组;类似LoadRunnner的end，测试结束时进行回收工作。
不同的是执行顺序---它会在普通线程组执行之后被触发。
应用场景举例：
A、测试数据库操作功能时，用于执行关闭数据库连接的操作。
B、测试用户购物功能时，用于执行用户的退出等操作。
(二)可拓展线程组
1、Concurrency Thread Group(递增式并发线程组)
这个可以模仿递增式并发(只能递增不能递减)，并可设置递增次数、递增时长、到达目标递增数量保持时长等等：
参数解释：
- Target Concurrency：目标并发(总线程数)
- Ramp Up Time：加速时间(总加速时长)
- Ramp-Up Steps Count：加速步骤计数(总加速/递增次数)
- Hold Target Rate Time：保持目标速率时间(到达总线程数后持续时长)
- Time Unit：时间单位(分钟或者秒)
- Thread Iterations Limit：线程迭代次数限制(循环次数)
- Log Threads Status into File：将线程状态记录到文件中(将线程启动和线程停止事件保存为日志文件);
现设计这样一个场景：
这意味着：
3分钟除以5步，每步0.6分钟;100个用户除以5步，每步20个用户;每0.6分钟将添加20个用户，直到达到100个用户，达到100个线程后，所有这些线程将继续运行，并一起打到服务器6分钟。
2、Stepping Thread Group(逐步线程组)
这个可以模仿递增式并发(不但递增还可以递减)，并可设置递增次数、递增启动延迟、递增时长、到达目标递增数量保持时长等等：
参数解释：
1、线程组最大用户数：100个
2、初次加载用户前等待时间：10秒，此时没有用户进入
3、第一次加载用户数：10个用户开始
4和5：每隔10秒加10个用户
6、ramp-up在几秒内启动线程组
7、持续压测60秒，一分钟
8、和9：退用户，每10秒退出10个用户
10、上面各种设置的图形表示
3、bzm - Arrivals Thread Group(bzm-到达线程组)
跟Concurrency Thread Group线程组功能作用大同小异。参数解释：
- Target Rate：目标线程数(总线程数)
- Ramp Up Time：所需多少加载时间(总加速时长)
- Ramp Up Steps Count：所需多少个加载梯次(总递增/加速次数)
- Hold Target Rate Time：持续运行时间(到达总线程数后持续时长)
- Time Unit：可以选择用分钟还是秒来做单位
- Thread lterations Limit：线程迭代次数限制。如果我们只需要运行每个用户一次以模拟用户的实际行为，则可能会很有用。在我们的例子中，该字段为空，因此每个用户将运行不确定的迭代，直到调度结束。
- Log Thread Status into File：将线程状态记录到文件中
- Concurrency Limit：最大并发数限制。以避免出现内存不足的问题。在我们的例子中是1000，这是一个很大的数字。
现设计这样一个场景：
所以以上设置就等于：3min除以5步,等于每步加速后持续0.6分钟，100个用户除以5步,等于每步加速20个用户，达到100个用户后持续跑6mn。
4、Ultimate Thread Group(最终线程组)
这个线程就比较难以理解，但是功能也比较强大。它可以对负载中的线程组进行复杂的管理。通过在线程计划中具有无限数量的行来完成此操作，这可以为线程组的不同部分启用不同的配置。该插件跟Stepping Thread Group线程组有些类似，不过这个是多个线程组设置的结合。执行的时候，每个线程组是同时按照自己的规则开始执行的，每一时刻，得到的结果都是两个线程组的叠加。
形象比喻：
并发的用户就像浪花一波一波的不断涌入系统，拍打服务器，考验我们的系统能否顶住压力并平稳运行
我们的网站正在平稳运行的时候，突然有一波1000用户同时访问，我们称之为第一浪潮。访问了30s之后，第一浪潮在15s内逐渐退出系统。
在第一浪潮退出系统的同时，第二波2000用户在极短时间内又突然涌入网站，我们称之为第二浪潮。在访问30s之后，第二浪潮在15s内也逐渐退出了系统。
在第二浪潮退出系统的同时，第三波3000用户又突然涌入网站，我们称之为第三浪潮。在访问30s之后，第三浪潮在15s内也逐渐退出了系统。
在第三浪潮退出系统的同时，第四波1000用户又突然涌入网站，我们称之为第四浪潮。在访问30s之后，第四浪潮在15s内也逐渐退出了系统。
添加单个线程组Row 和 添加多个线程组Row：
参数解释：
- Start Threads Count：一共要启动的线程数。图中本次测试一共启动100个线程(用户/并发)。
- Initial Delay, sec：最开始延迟时间，单位秒。设置为0，就是点击了立即执行。
- Startup Time, sec：启动设置的100个线程并发一共需要的时间，单位秒。图中设置10秒(线程组的加速期)
- Hold Load For, sec：保持加压时间，单位秒。图中10秒。
- Shutdown Time：多久时间内全部释放关闭，单位秒。图中10秒。
【实例】
1、需求：要求此接口用户的访问量“分波式”访问，每个时期、每波都有不同用户量访问，每波的用户访问量呈现出递增然后逐次递减的状态，单波用户量最大并发不可超过70。
2、分析：根据需求实现具体场景，可得出普通线程组并不能实现，普通线程组一般实现为“直线式”的需求场景(配合其他元件实现略不同)，那么此时Ultimate Thread Group线程组便可为之实现：
3、步骤：
第一步：根据需求场景“每个时期、每波都有不同用户量访问”现设置添加多Row，每Row的Start Threads Count(开始线程计数)，初始用户的数量为：10、30、50、70、50、30、10，此时每波用户访问量递增→递减和单波用户不可超过70的需求配合关闭时间已经满足。
第二步：每Row的Initial Delay,sec(延迟启动时间，单位秒)设置每时间间隔5s：0s、5s、10s、15s、20s、25s、30s，这样是为了满足不同组的启动延迟时间，若每个线程组不同的用户都在同一时间节点启动那不是递增式并发，那是同步式并发。
第三步：每Row的Startup Time,sec(启动时间)，意指每个线程组的线程在多少s内全部启动，目前设置为1s，即是每组线程组的线程数从启动开始到启动结束话费时长为1秒。
第四步：每Row的Hold Load For,sec(持续运行)，意指每个线程组的线程在启动达到设置的线程数后持续运行多长时间，单位秒。此时需求每组线程运行后达到顶峰后呈现出“递减”状态，所以持续运行时间应该也是设置为递减：30、25、20、15、10、5、0(单位s)。
第五步：Shutwn Time(关闭时间)，这个可配合上面四个可设置：0、5、10、15、10、5、0。这样是为了满足“每波用户访问量递增→递减”的需求
好啦!主功能配置已经完成，看下具体线程组效果图：
此时，运行后为了确保线程组的变化运行轨迹，添加一个Active Threads Over Time用来查看随时间变化的活动线程：(添加路径：线程组→添加→监听器→jp@gc - Active Threads Over Time)
最后，即可添加察看结果树、聚合报告、响应时间图等分析此接口的接口各个返回指标等：
Ultimate Thread Group(最终线程组)实现原理：TA跟Stepping Thread Group线程组有些类似，不过这个是多个线程组设置的结合。执行的时候，每个线程组是同时按照自己的规则开始执行的，每一时刻，得到的结果都是两个线程组的叠加。
总结，对于系统原生Jmeter线程组只要下载安装并配置环境变量Jmeter即可使用，可拓展线程组需要下载特定的插件进行安装和配置，虽麻烦但是配置好的线程组功能是比较强大的，且可满足多种类型的用户和需求场景，值的感兴趣的小伙伴一试!
【本文是51CTO专栏机构“AiChinaTech”的原创文章，微信公众号( id: tech-AI)”】
