查看原文
其他

如何设置 JMeter 线程组?

宋赟 毕小烦 2023-02-13

作者:宋赟  编辑:毕小烦

最近有不少测试同学问我 JMeter 线程组如何设置并发的问题,发现很多人对线程组里的参数不是很清楚,今天就科普一下 JMeter 线程组的信息,也简单介绍一下不同场景的并发策略。

1. 线程组是什么

一个线程相当于一个虚拟用户,线程组顾名思义是多个线程的一个集合,是执行特定测试用例的用户池,是任何一个测试计划的开始点,它能使本线程组内的所有元件按照设定的测试用例来执行,故要执行性能测试的元件都必须在某个线程组下,否则没法控制。


在线程组的 GUI 页面中,我们可以模拟用户线程数、启动所有线程所需时间、执行测试的次数,也可通过调度器来执行测试的循环时长、定时执行等。

1.1 添加线程组的步骤

测试计划 -- 右键 --添 加 -- 线程(用户)-- 线程组


1.2 线程组中的参数


  • 名称:线程组名称,自定义,没什么要求,默认也可,若有多个线程组,建议能有辨识度,和业务有关联性
  • 注释:对该线程组做解释,自定义内容,也可为空

1.3 取样器错误后要执行的动作

  • 继续:当请求出错后继续运行。我们常规压测中,一般都是有大量的线程并发,而个别请求出现响应异常也属正常现象,只要错误率不是特别高即可。另外可能由于性能问题导致响应异常能够记录下来,也可供我们对服务是否有性能问题或稳定性作为一项参考依据。
  • 启动下一进程循环:当有请求出错后同一脚本中剩下的请求不再执行,而是重新开始执行。
  • 停止线程:当有请求出错后则停止当前线程,不再执行。如果我们运行了 10 个线程,其中某个线程有请求出错后,则会停止这个线程,只有9个线程并发了。如果错的越多,线程停止的就会越多,执行时间长了,运行的线程因为较少,对服务器的负载压力下降,导致压测结果没有参考性了
  • 停止测试:当有请求出错后则停止所有线程,但不管线程执行到哪个请求,都会执行完当前循环的线程组内所有请求后才停止。
  • 立即停止测试:当有请求出错后,立即停止整个测试场景。

1.4 线程属性

  • 线程数:模拟的用户数,一个线程是一个用户。
  • Ramp-Up时间(秒):启动所有线程所需时间,单位为秒,比如 100 个线程要在 1 秒钟内启动完,则每个线程启动间隔时间为10 ms。
  • 循环次数(永远):请求重复执行的次数。勾选永远则不能填入次数且会一直执行;不勾选永远,在输入框中输入数字则表示请求重复执行对应的次数。
  • 延迟创建线程直到需要:勾选则按照 Ramp-Up 时间启动线程并运行;不勾选则先启动所有线程,再按照 Ramp-Up 时间启动请求。
  • 调度器:设置开始运行时间。
  • 持续时间(秒):执行多长时间,单位是秒,必然执行 5 分钟则填 300。
  • 启动延迟(秒):点执行按钮后不运行线程,等待延迟时间过后开始运行线程。

2. setUp 和 tearDown 线程组

当压测需要有前提条件或预设值时,会用到 setUp 线程组;当压测执行完成后要做一些清理或预后工作时,会用到 tearDown 线程组。

2.1 setUp 线程组

「setUp 线程组」用于执行预测试操作,它的配置项与普通的线程组完全一样,不同之处在于 setUp 线程是在执行常规线程组之前执行。通常用在运行测试任务前,做初始化工作。例如建立数据库连接初始化工作。


2.2 tearDown 线程组

「tearDown 线程组」用于执行测试后操作,它的配置项与普通的线程组完全一样,不同之处在于 tearDown 线程组是在完成常规线程组执行之后执行。


3. 线程组在测试场景中的应用

在 JMeter 中,压测场景设置是在线程组里完成的,在线程组里我们需要组合用户的各种操作,特别是在复杂场景下,还需要配合多个控制器来进行场景设置,今天这里先不讲复杂场景,先把我们常用的场景如何在 JMeter 中完成设置讲一下。

下面通过两个场景粗略讲解下不同场景下使用的不同压测策略。

3.1 场景一

压测目标:购物场景【登录-挑选商品-加入购物车-支付】,这个场景的性能目标是响应时间不超过 1s,各接口 TPS 需要达到 50 以上。

测试分析:针对这种类型的场景我们一般压测时建议选择按时间执行该性能场景,执行可参考以下进行,具体线程数、Ramp-Up 时间以及持续时间可根据实际情况调整。

线程数Ramp-Up时间循环次数调度器持续时间
11永远300s
501永远300s
1001永远300s
......1永远300s

3.2 场景二

压测目标:每天平均有 20 个左右的用户会进行导出操作,导出次数最多 60 次,希望导出响应时间不超过 3 秒。

测试分析:针对这类次数型场景建议选择按循环次数执行该性能场景压测。

线程数Ramp-Up时间循环次数调度器持续时间
1160××
1016××
2013××
3012××

通过以上两个场景,我们大概可以看出,一般涉及到次数或对请求量要求较低的情况,可以使用循环次数,但绝大部分场景用按时间循环会比较多,这场景设置不是绝对的,需要根据业务场景及用户使用习惯、再配合脚本请求相关设置等众多因素综合考虑。

以上两个场景情况作为引导读者更好理解不同场景使用不同压测策略,不作为压测策略推荐,仅供参考。

总结

本文粗略的讲了下线程组的定义及相关参数说明,并对线程组在测试场景中如何应用作了案例讲解,希望对大家有帮助。

推荐阅读

如何测试微信小程序?

如何实现基于场景的接口自动化测试用例?

测试计划应该怎么做?

测试左移的一点思考

设计一款简单的接口自动化测试框架


性能测试中的系统资源分析之 网络

性能测试中的系统资源分析之 磁盘

性能测试中的系统资源分析之 内存

性能测试中的系统资源分析之 CPU


如何进行基准测试?

用 Calcite 解决造数时的数据源适配问题

如何测试微信公众号?

数据工厂低代码平台探索与实践

我们用到的 3 种 Mock 测试方案

前端性能测试怎么做?

如果你想玩转 Dubbo 接口测试?一定要知道这 3 种姿势

测试人员如何快速熟悉新业务?

可用性保障平台的自动化测试探索与实践

如何测试 Redis 缓存?


如何保障需求质量(下):你应该做到的

如何保障需求质量(上):你应该知道的

(完)


如果文章对你有帮助,记得留言、点赞、加关注哦!


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存