文章已迁移到CSDN:博客地址:https://blog.csdn.net/xiaomacaicai/category_11196823.html
文章欢迎转载，还请注明出处https://www.jianshu.com/nb/50563030，十分感谢
通过阅读以下内容，你可以：

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

循环控制器

循环控制器和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有哪些控制器，都是干什么用的就行，至于具体怎么用，我觉得到时结合脚本实例来分析效果会更好