转 JMeter基础之--元件的作用域与执行顺序

　　前面有介绍过jmeter的元件类别，对于新手来说，jmeter的元件是还是不少的，如果我们按照每一个元件的每一个参数的含义去学习，无疑会降低学习性能测试的热情，就算我们熟悉了所有元件以及元件上的参数了，我们也不知道如何将其组合成我们想要描述的性能测试。另一方面，我们点击每个节点上的元件都会出现类似或相同的菜单，他们的层级关系是什么样的。究竟这个元件放在哪个层级的哪个位置才达到我们意愿。

　　如何更快速的入门jmeter，个人建议通过录制脚本的方式，快速的了解一个性能测试应该包括的元件以及它们的层级关系。

　　关于录制方式，请参考《JMeter基础之—录制脚本》

　　如下，我通过badboy工具录制的一个脚本（脚本过程：登录126邮箱，给自己发一封邮件，祝自己圣诞快乐！），并可以方便的将脚本导出为jmx格式，这也是jmeter脚本的格式，所以可以被jmeter识别并导入。

　　脚本导入到jmeter后，我添加了两个监听器（查看结果树），因为我添加监听器的位置不同，他们的作用域也是不一样的。前一个只能监听到www.126.com页面的请求，后一个侧对所有的http请求进行监听。

元件的作用域

---

　　先来讨论一下元件有作用域。《Jmeter基础之---jmeter基础概念》一章中，我们介绍了8类可被执行的元件（测试计划与线程组不属于元件），这些元件中，取样器是典型的不与其它元件发生交互作用的元件，逻辑控制器只对其子节点的取样器有效，而其它元件（config elements 、timers 、post-processors、assertions、listeners、）需要与取样器（sampler）等元件交互。

配置元件（config elements ）

　　元件会影响其作用范围内的所有元件。

前置处理程序（Per-processors）

　　元件在其作用范围内的每一个sampler元件之前执行。

定时器（timers ）

　　元件对其作用范围内的每一个sampler 有效

后置处理程序（Post-processors）

　　元件在其作用范围内的每一个sampler元件之后执行。

断言（Assertions）

　　元件对其作用范围内的每一个sampler 元件执行后的结果执行校验。

监听器（Listeners）

　　元件收集其作用范围的每一个sampler元件的信息并呈现。

在jmeter中，元件的作用域是靠测试计划的的树型结构中元件的父子关系来确定的，作用域的原则是：

• 取样器（sampler）元件不和其它元件相互作用，因此不存在作用域的问题。
• 逻辑控制器（Logic Controller）元件只对其子节点中的取样器 和 逻辑控制器作用。
• 除取样器 和逻辑控制器 元件外，其他6类元件，如果是某个sampler的子节点，则该元件公对其父子节点起作用。
• 除取样器和逻辑控制器元件外的其他6类元件，如果其父节点不是sampler ，则其作用域是该元件父节点下的其他所有后代节点（包括子节点，子节点的子节点等）。

讲了这些，你可能迷糊了，到底是肿么个情况呀！？通过两个栗子（例子）来理解一下他们的作用域。

A（注：下图只是为了说明作用域，无法正常运行）

取样器（HTTP请求1 、FTP请求2 、TCP取样器3） 逻辑控制器（循环控制器） 监听器（图形结果1、聚合报告2）

*  HTTP请求1 、FTP请求2 、TCP取样器3 元件没有作用域的概念。

*  循环控制器 元件作用域名是其子节点FTP请求2 、TCP取样器3 。

*  图形结果1 元件的作用域是是FTP请求2 、TCP取样器3。

*  聚合报告2 元作的作用域是HTTP请求1 、FTP请求2 、TCP取样器3

B （注：下图只是为了说明作用域，无法正常运行）

这个例子稍微复杂一些，包含的元件较多。先来分分类。

　　取样器（HTTP请求 、FTP请求 、TCP取样器、 JDBC Request ）逻辑控制器（循环控制器、随即控制器）定时器（固定定时器、Uniform Random Timer ）断言（响应断言、XML断言）监听器（图形结果、聚合报告）

根据作用域原则，这些元件的作用域分别为：

*  HTTP请求 、FTP请求 、TCP取样器、 JDBC Request  元件没有作用域名概念

*  循环控制器 的作用域为 FTP请求 、TCP取样器和 随即控制器

*  固定定时器作用于 HTTP请求 ， Uniform Random Timer 作用于所有取样器

*  响应断言作用于JDBC Request  ， XML断言作用于FTP请求 、TCP取样和JDBC Request 。

*  图形结果作用于FTP请求 、TCP取样和JDBC Request ，聚合报告作用于作用于所有取样器。

其实，通过上面的分析，并没有你想象的那么复杂，我们从各个元件的层次结构就可以判断每个元件的作用域。

　　Jmeter 中的逻辑控制器（Config Elements）在其作用范围内的行为与其他元件相比稍有不同。逻辑控制器元件分两大类：默认配置（HTTP默认请求、FTP默认请求等）和 管理（HTTP 头管理、HTTP cookie 管理等）。

　　其中默认配置（Configuration Defaults）元件中设置的值可以在作用域内叠加，例如，在一个测试计划中添加两个HTTP 默认请求，其中第一个默认设置 Server name or IP 为www.google.com ，第二个默认设置Path 为/page-not-exist ， 则在这两个元件作用域内的所有HTTP 默认请求，其默认的Server name or IP 和Path 均为Server name or IP 和 /page-not-exist 。（你有一个故事，我有一个笑话，我们一交换，两个人都分别拥有了一个故事加一个笑话。）

　　管理（Manager）类逻辑控制器元件的效果则不能进行叠加。如果两个或两个以上相同的管理类元件作用域有重叠。则在重叠作用域内的取样器元件只会随即受到其中一个的作用，这样会导致取样器行为的不确定性。因此，在使用管理类逻辑控制器时，一定要注意保证相同的管理类元件的作用域不发生重叠。

元件的执行顺序

---

了解了元件有作用域之后，来看看元件的执行顺序，元件执行顺序的规则很简单，在同一作用域名范围内，测试计划中的元件按照如下顺序执行。

（1）配置元件（config elements ）

（2）前置处理程序（Per-processors）

（3）定时器（timers ）

（4）取样器（Sampler）

（5）后置处理程序（Post-processors） （除非Sampler 得到的返回结果为空）。

（6）断言（Assertions）（除非Sampler 得到的返回结果为空）。

（7）监听器（Listeners）（除非Sampler 得到的返回结果为空）。

关于执行顺序，有两点需要注意：

*  前置处理器、后置处理器和断言等元件公能对 取样器作用，因此，如果在它们的作用域内没有任何取样器，则不会被执行。

*  如果在同一作用域范围内有多个同一类型的元件，则这些元件按照它们在测试计划中的上下顺序一次执行。