学了元件作用域，我终于对JMeter开窍了

先看一下这个例子，测试计划“进入考场”下面有一个线程组，线程组下面有 3 个 HTTP 请求，分别是学生登录、考场 token和进入房间：

它们的处理逻辑是：

学生登录后，在响应中返回了登录后的 token，使用正则表达式提取器，提取登录 token

在登录以后，把登录 token 作为 header，去请求“考场token”这个接口，请求后的响应中，返回了考场 token，使用正则表达式提取，下图是“考场token”请求的 header，使用了 HTTP Header 管理器：

拿到考场 token 以后，把考场 token 作为 header，去请求“进入房间”接口，下图是“进入房间”请求的 header，Value定义的是 ${exam_token}，就是考场 token，这个 token 是从第 2 个请求“考场token”的响应中，使用正则表达式提取出来的：

回顾一下，首先登陆，登陆后获取token，然后再获取考场token，最后进入房间。这个例子的问题就在于，第 2 个请求和第 3 个请求，都设置了 header，这 2 个 HTTP Header Manager 能按我们想的去工作吗？

运行顺序与作用域
运行顺序
先了解一下 JMeter 元件的运行顺序。JMeter 根据 2 个维度来决定元件的运行顺序，第 1 个维度是从上往下，第 2 个维度是元件类型。

从上往下，指的是从根节点->父节点->子节点->叶子节点。

元件类型，分为 3 类：

线程组、逻辑控制器。
取样器。
配置元件、前置处理器、定时器、后置处理器、断言、监听器。
最后这六个元件类型，都是为取样器服务的。它们的运行顺序如下：

配置元件（如果存在）

前置处理器（如果存在）

定时器（如果存在）

取样器（如果存在）

后置处理器（如果存在且取样器的结果不为空）

断言（如果存在且取样器的结果不为空）

监听器（如果存在且取样器的结果不为空）

我总结一下加强理解。假设我们新建了 1 个线程，想用这个线程去发请求。

首先是初始化配置，比如参数化、设置 Header、Cookie 等，配置元件。

接着可能需要给线程加点参数，比如用户参数，会用到前置处理器。

然后在发送请求前可能会等待一段时间，添加定时器。

准备好以后，就可以发送请求了，也就是取样器。

如果取样器什么数据也没有返回，那么就可以直接退出了。

如果返回了数据，使用后置处理器，比如正则表达式提取器，提取想要的数据。

提取之后还有要做验证，断言一把。

测试运行的怎么样呢，用监听器看一看。

示例
再结合示例感受一下，请看以下测试计划，添加了 1 个 线程组，包含 3 个 取样器（HTTP Request 1 2 3）：

JMeter 会按以下步骤运行：

线程组（如果有多个线程组可以在测试计划设置是顺序执行还是同时执行）
简单控制器（父节点）
HTTP Cookie 管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求 1（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP Cookie 管理器（配置元件）
用户参数（前置处理器）
Synchronizing Timer（定时器）
HTTP 请求 2（取样器）
正则表达式提取器（后置处理器）
响应断言（断言）
HTTP 请求 3（取样器）
察看结果树（严格来讲是与第 6 步并行，也就是取样器之后）
作用域
第 9 ~ 14 步我用黑色斜体加粗了，因为从图中的位置来看，“HTTP 请求 2”，前后并没有元件，但是也被作用上了。

这是因为它们具有相同的作用域，在 JMeter 中，同一层级的元件具有相同的作用域。

示例中，添加了一个简单控制器，然后在下级添加了配置元件、前置处理器、定时器、后置处理器、断言，和 2 个取样器（HTTP Request 1 2 ）。

简单控制器是一个执行单元，本身没有内容，它的作用是把元件进行分组运行：

所以简单控制器下面的这些同级元件，作用域相同，既会作用于 HTTP Request 1，也会作用于 HTTP Request 2。

配置元件、前置处理器、定时器、后置处理器、断言、监听器，这六个元件类型，会作用到范围内的所有取样器。

层级
在 JMeter 中，上级的作用域包含下级的作用域。

但是下级是不能作用到上级的。

比如示例中的 HTTP Request 3，和简单控制器是平级，那么简单控制器下级的元件，是不会作用到 HTTP Request 3 的。

使用建议
再看看开头的例子：

有 3 个取样器，用户自定义变量和 CSV Data Set Config，都是配置元件，跟取样器同级，会同时作用到这 3 个取样器上面。

HTTP Header Manager 也是配置元件，不会作用到学生登录取样器，因为根据从上往下的维度，它们都位于学生登录取样器之后。

图中有 2 个 HTTP Header Manager，你可能会认为它们会分别执行，实际上它们会一起执行！

在同一执行单元中，如果相同类型的元件有多个，会被当做一个一起执行。

我把第 2 个 HTTP Header Manager 稍微改了一下，可以看得很明显：

考场token的请求，在目录树中是第 2 个，但是从结果来看，它的 header，被添加上了我在后面第 3 个请求设置的 header了。

这个结果显然不是想要的。

所以为了避免混乱，建议在使用 JMeter 添加元件的时候，一是根据先后顺序，从上往下合理的放置元件的顺序。二是对于配置元件、前置处理器、定时器、后置处理器、断言这六类元件，因为它们都是为取样器服务的，如果只想作用于单个取样器，最好是放在这个取样器的下级，以避免由于同一作用域相互作用，导致意想不到的结果。

这个例子把 HTTP Header Manager 分别放到各自的取样器下级，就能按设想运行起来了：

简要回顾
本文首先引入了我工作中碰到的问题，接着结合示例讲解了运行顺序、作用域和层级，搞懂了 JMeter 目录树是怎么运行的，最后回到开头的例子进行了结果分析，给出了在使用时的两条建议。