每天15分钟JMeter入门篇(三):认识JMeter的逻辑控制器

  • Post author:
  • Post category:其他



其他文章



每天15分钟JMeter入门篇(一):Hello JMeter



每天15分钟JMeter入门篇(二):使用JMeter实现并发测试



每天15分钟JMeter入门篇(三):认识JMeter的逻辑控制器



每天15分钟JMeter入门篇(四):认识JMeter中的函数



每天15分钟JMeter入门篇(五):认识JMeter中的Test Fragment



每天15分钟JMeter入门篇(六):学会用好JMeter中的断言



每天15分钟JMeter入门篇(七):认识JMeter中的监听器



每天15分钟JMeter进阶篇(1):JAVA 取样器的基本使用





前言

通过阅读以下内容,你可以:

  1. 了解JMeter中的逻辑控制器。
  2. 没有了。

这次的文章就是讲逻辑控制器的。

从这篇开始,我们才开始真正接触到JMeter的核心功能。在上一篇文章中我们用JMeter实现了一个简单的并发场景,其中用到了一个事务控制器,它就是JMeterd的逻辑控制器之一。

JMeter的强大来源于BeanShell、逻辑控制器、公式,当然它还有很多很炫的功能,但是我认为这三个功能构成了JMeter的核心。简单的说,学习逻辑控制器的意义在于我们可以设定JMeter性能测试的行为,复杂的性能测试场景都需要借助各种逻辑控制器的组合来实现。

看文章只能”知道“它是什么,还是要自己下去每个控制器实际用一遍,看到效果了,才能说自己会用了。



让我们开始吧

在5.4.1.中,JMeter的逻辑控制器一共有17种,按照用途大体可以分为三类:事务控制器、循环控制器、行为控制器。所有的逻辑控制器如图:

kongzhiqi.png

除了仅一次控制器,其他的控制器都可以互相嵌套,先死记住:只有仅一次控制器不能嵌套其他的控制器。

下面的内容就是纯文字介绍了。这里只能走马观花的介绍一遍,先有个概念吧。后续的文章里会用到这些逻辑控制器,到时再结合脚本做详细介绍,不然写的再多你也背不下来



如果(if)控制器

条件控制器,顾名思义是按照判断条件是否成立,来决定其下面的元件是否执行。跟编码中的if判断是一个概念。设置界面如下:

if.png

上图中黄色高亮的部分是if判断表达式的录入框。如果你的JMeter没有这种高亮效果,请升级到5.4.1

  • Use status of last sample 这应该是5.4.1新增的,很赞的选项,点一下它会替你生成${JMeterThread.last_sample_ok},它的作用是使用上一个取样器的结果,非常的方便,不用自己写一大堆的判断了。
  • Interpret Condition as Variable Expression,勾选后控制器会使用变量表达式来判断,例如${__javascript(…)},如果勾选了则JMeter会计算javascript中表达式的值
  • Evaluate for all childrun 判断条件是否针对所有子节点。如果启用这个选项,在有多个子节点嵌套的情况下容易导致逻辑混乱。默认不勾选,就只会在if控制器入口的地方判断一次,默认状态就已经足够满足绝大部分的测试场景。



事务控制器

可以说是JMeter最核心的控制器了。事务控制器的最根本的作用是度量事务的性能,包括执行次数、响应时间、异常率、吞吐量(TPS),网络流量。添加事务控制器后,我们就可以在聚合报告里看到这些指标。

其中异常率,是事务控制器下所有的取样器都执行成功了,这个事务才算成功。

设置界面如下:

shiwu.png

之前我们的脚本中已经添加过一个事务控制器和聚合报告了,具体的操作可以参考:

每天15分钟JMeter基础篇(二):使用JMeter实现并发测试



循环控制器

循环控制器和while控制器一样,都是用来循环执行的。区别在于循环控制器是按照执行次数来控制的,也就是你可以设定元件执行多少次;而while循环是按照条件表达式的结果来控制的,例如如果进度为100%则退出while循环。

设置界面如下:

loop.png

特别注意那个循环次数中”永远“的复选框,如果勾选后,那么在脚本的持续运行时间内,循环控制器下的元件会重复执行;直到脚本停止。



while控制器

顾名思义,用来实现while循环功能,这是一个很有用的控制器,现在很多前后端分离架构的系统,都使用异步任务的方式来处理业务。例如导出100W条订单的记录需要10秒,程序并不会阻塞在那里,它会提交一个异步任务就直接返回,然后通过一个定时的进程轮训任务进度。那么在性能测试中如果没有异步等待就会导致脚本提交频率异常高。这里的异步任务等待就可以用while循环来实现。设置一个退出条件例如进度100%或等待次数60次,不满足时则一直循环。

界面如下:

image.png

注意那个Condition文本框,while循环的判断条件就写在那里。



临界部分控制器

按照文档,这个控制器的目的是为了控制并发场景下,各个元件执行顺序混乱的问题。但是实例看的不是很明白,JMeter在一个线程组下取样器,本身就是按照顺序执行的呀。所以这里先Mark一下,等回头学明白了我再修改补充。



Foreach控制器

作用是从【用户自定义的变量】里读取数据,并执行循环。界面如图:

foreach.png

其中,输入变量前缀是和另一个元件【用户自定义的变量】配合使用的,这里你先可以简单的理解为:这里定义一个前缀例如TEST_,那么在脚本运行的时候它会去【用户自定义的变量】里循环读取TEST_XX1,TEST_XX2的值,有多少个TEST_XX,就会循环多少次。

开始循环字段(不包含):循环变量的下标的起点;

结束循环字段(含):循环变量下标的终点

输出变量名称:循环控制器生成的变量名称,其他线程可以通过该名称引用变量的值

数字之前加上下划线,默认勾选,使用起来会比较便利。



Include控制器

对于脚本设计来说一个非常重要的控制器,你可以将一个复杂的性能测试分为不同的测试场景,每个测试场景是一个TestPlan,每个TestPlan放到一个【测试片段】的元件中,有Include调用,它可以实现团队内部的分工协作:你弄订单的,我弄查询的,设置好变量和参数化后各自提交,然后作为一个整体来执行。在使用版本管理工具的团队中,这个控制器就显得很重要了,它可以避免所有人的修改都提交到一个jmx文件中导致冲突。

Include控制器界面如图:

include.png

配置界面没什么需要特别解释的,但是有两点需要特别注意:

  1. Include只能包含测试片段,这是一个元件,后面会介绍,现在先知道他怎么用就行。测试片段里包含你的Jmx脚本;
  2. 如果测试片段的Jmx中包含有参数或者用户定义的变量,那么这些变量需要定义在外部的测试计划jmx中。不能只写在测试片段的Jmx中。简单的说就是公共的变量和参数放在外部。



交替控制器

交替控制器的作用是,它下面节点的取样器会以交替的方式执行。这个控制器我用的很少,因为我的性能测试场景中暂时没有碰到需要交替执行的情况,只在排查问题时用到,也就是两个请求反复交替执行,先保存、再删除,再保存,再删除。

界面如图:

jiaoti.png



仅一次控制器

不要看它的名字叫仅一次,就以为它没什么用,实际上这个控制器用的很频繁。考虑一下这个性能测试需求:要求测试以下性能测试场景,用户A登录系统;提交订单、查询订单、删除订单,100用户在线(有称之为100并发的)执行20分钟。你可能觉得把这五个请求搞出来放到脚本里,设置上100并发执行时间20分钟,然后直接run不就行了吗?其实是不可以的。因为你的脚本是循环执行,每一次循环都是执行一次用户登录,所以20分钟执行下来你的在线用户肯定是高于100的,对吧。这个时候仅一次控制器就派上用场了,你可以把登录的请求放在仅一次控制器中,这样即使你执行20分钟,或者你循环执行N次,你的登录请求也只会执行一次,这样就能实现你有100个用户登录一次、循环执行20分钟业务的测试需求了。

要特别特别注意,

在一个线程组中如果存在多个【仅一次控制器】,那么只有第一个【仅一次控制器】生效

,其他的仅一次控制器仍然会每次循环时执行节点下的取样器。

设置界面如下,没什么特别的配置,用法也很简单,把你的取样器拖到这个节点下面就可以。

only.png



随机控制器

我个人觉得一个很鸡肋的控制器,它的作用是让节点下的元件随机执行,每个元件只执行一次。目前没有碰到过需要使用它的场景



随机顺序控制器

我个人觉得它和随机控制器一样,也是一个有点很鸡肋的控制器,它的作用是让节点下的所有元件随机执行。目前没有碰到过需要使用它的场景,注意它和随机控制器的区别:例如有10个子元件,随机控制器只会随机执行其中的1个,其他9个不执行;而随机顺序控制器会执行全部的10个,只是执行顺序随机。



录制控制器

录制控制器其实跟脚本的执行没关系,它是用来录制http请求的以生成测试脚本的,类似于Loadrunner里的record录制功能。



Runtime控制器

它的作用就是控制它下面子元件的执行时长。你添加一个Runtime控制器,然后在它的下面添加一个查询的Http取样器,设置10秒。此时运行的话,你会发现查询的http取样器运行10秒后就结束了。

runtime.png

在复杂的性能测试场景中,我们总会有这样的需求:整体场景执行20分钟,但是其中某些http请求只执行一定时间就结束。有时在组合场景负载时,为了排查特定并发场景我会使用该控制器。

如果Runtime(seconds)为0或者不填,则该控制器下的子元件不会执行。



简单控制器

我个人认为最废柴的一个控制器,但是存在即合理,我觉得他的最大的作用可能就是嵌套其他控

制器了,我们可以用它来定义一个”执行块“,按照执行块来对脚本进行控制。我这边很少用到它,界面如图:

jiandan.png

设置界面都如此简单,果然是一个”简单控制器“



吞吐量控制器

不管你对吞吐量是怎么定义或者怎么理解的,这个吞吐量控制器都不是控制吞吐量的,按照官方文档定义,他是用来控制它下面元件的执行次数的。是执行次数,不是tps,也不是qts,也不是网络吞吐量。是不是很蒙圈?

tuntuliang.png

Based on是控制器的控制模式,

  • Percent Executions是按照百分比控制;
  • Total Excetions 是按照吞吐量设置的值来控制
  • Per User 按照官方文档,是指是否按照虚拟用户数来计算执行次数。PerUser对Percent Executions没有任何影响。

    Percent Executions是最常用的选项



模块控制器

模块控制器可以在调用其他的测试片段。跟Include很像,但是它跟Include控制器不一样的地方在于,它提供了在运行时改变测试片段的能力,Include不行。当测试开始执行后,Include里所指向的测试元件就不可改变,模块控制器则可以。简单的说,模块控制器适用于手动控制测试执行过程,而Include则适合无人值守执行或者执行后不管

设置界面如下:

mokuai.png



Switch控制器

Switch控制器的作用类似于编程中的Switch,根据输入值匹配不同的分支。界面如图:

switch.png

其中Switch Value经常和公式、变量一起配合使用。可以为数字,也可以为字符,

目前知识点就先整理到这里,后续的文章会穿插着详细讲解这些控制器的用法,这里就是先从概念上梳理一遍,目前只要知道JMeter有哪些控制器,都是干什么用的就行,至于具体怎么用,我觉得到时结合脚本实例来分析效果会更好



版权声明:本文为wyp_810618原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。