引子

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

它们的处理逻辑是：

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

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

   
   
   

3. 拿到考场 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. 配置元件（如果存在）

2. 前置处理器（如果存在）

3. 定时器（如果存在）

4. 取样器（如果存在）

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

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

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

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

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

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

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

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

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

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

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

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

示例

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

JMeter 会按以下步骤运行：

1. 线程组（如果有多个线程组可以在测试计划设置是顺序执行还是同时执行）
2. 简单控制器（父节点）
3. HTTP Cookie 管理器（配置元件）
4. 用户参数（前置处理器）
5. Synchronizing Timer（定时器）
6. HTTP 请求 1（取样器）
7. 正则表达式提取器（后置处理器）
8. 响应断言（断言）
9. HTTP Cookie 管理器（配置元件）
10. 用户参数（前置处理器）
11. Synchronizing Timer（定时器）
12. HTTP 请求 2（取样器）
13. 正则表达式提取器（后置处理器）
14. 响应断言（断言）
15. HTTP 请求 3（取样器）
16. 察看结果树（严格来讲是与第 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 目录树是怎么运行的，最后回到开头的例子进行了结果分析，给出了在使用时的两条建议。