本文重点介绍JMeter工具在测试中地位以及其中一些难以理解或者手册中含糊不清的感念，读者可以通过本文了解这些概念，然后再根据自己的需要查阅JMeter中各个组件的具体用法来完成测试工作。

　　1. 简介

　　JMeter是一个专门用于测试C/S应用的桌面测试软件（并不适合于B/S结构，因为它很难模拟用户在browser上的动作，如果需要测试B/S结构的应用，可以选择Selenium这样的工具），主要被用来完成功能测试，压力测试 ，性能测试等工作。

　　JMeter与其它测试软件相比的优势如下：

    它可以帮助测试者很方便地模拟出多用户同时访问服务器的环境（通过Thread Group），这样可以检测出很多平时在单线程环境下无法暴露出来的问题。
    应用范围很广，几乎所有你能想到的C/S应用它都能够提供了相应的支。JMeter中自己定制了一些特定应用的测试方案，例如对HTTP Server的测试、对数据库的测试、对Java程序的测试等。此外即使Jmeter没有提供当前应用的测试环境，用户也可以同昨BeanShell的方式自行定制。
    提供了丰富的逻辑控制器，可以允许测试人员很方便地写出一些相对复杂的测试逻辑。
    提供完善的变量机制以及配置机制，帮助测试人员减轻编写用例的负担，减少重复工作。
    提供了强大的监控组建，帮助测试人员很方便地得到测试结果统计信息。

　　JMeter的劣势：

    难以针对“正确性”进行测试。虽然JMeter提供了断言机制，但是通常我们的测试在模拟多用户操作，因此某个用户发出一个请求后得到的响应是不可预测的（例如同时对一个数据库表进行读写，虽然我们可以让每个模拟用户将写入的信息存储在某个公共区域，但仍然可能会有问题，因为数据库写入的时间和写入公共区域的时间并不能保证同步），因此如果想通过JMeter验证应用的正确性还是比较麻烦的。通常我们只是利用断言来检查一些较为简单而又重要的信息，例如返回码。
    没有很好的BeanShell测试机制。在JMeter中，BeanShell是非常重要的一部分，因为通常JMeter定制的测试方案多少与我们的应用有些出入，这时需要使用BeanShell来完成一些JMeter无法完成的工作。然而BeanShell也是需要保证正确性的，而JMeter并没有对BeanShell的测试提供很好的支持。
    通过以上的分析，可以发现JMeter更适合找出被测试系统在并发环境下存在的问题。

　　2. JMeter测试用例的基本结构

　　JMeter测试用例的基本结构是一个类似于Windows资源管理器的树形结构，这个树中的每一个节点都由一个元素来表示，因此一个完整的JMeter测试用例实际上是由一个个元素组成的，而测试的执行过程实际上是这些元素的执行过程。一般而言，JMeter会使用深度优先的方式遍历这些元素，而对于同一层的元素，JMeter会自上至下地执行。

　　在JMeter中有很多种元素，而每种元素在树型结构中都有特定的意义，为了方便理解，这里把这些元素从结构性质上分为三大类：

　　第一类是控制型元素，这类元素通常出现在树型结构的枝节点，它们被用来控制其下第一层元素（注意，不是其下所有元素）的执行，例如控制他们的先后顺序，或者执行哪个或者不执行哪个。通过这类元素我们可以很方便地动态控制测试用例的执行过程，这些元素类似于变成语言中的if-else、switch、while等逻辑控制语句。

　　第二类是动作型元素，这类元素是真正发起测试请求的元素，它们通常位于树型结构的底层，每一个动作元素代表一次请求-响应的过程，他们的执行顺序通常被控制型元素管理。

　　第三类是配置型元素，它们只能作为树型结构中的叶子节点，被用于对其作用范围内（作用范围的规则如下：如果该配置元素在控制元素下，则其作用范围为该控制元素下的所有子孙节点；如果该配置元素在动作元素下，则其作用范围仅为这一个动作元素）的所有动作型元素产生一定的影响。这些影响根据具体元素种类而不同，例如改变元素的参数、延迟请求时间、在请求前后加入一些动作、监听请求及其相应。此外，如果某个动作型元素被多个相同的配置型元素影响后，这些配置型元素的效果会进行Merge，Merge的规则依照元素的功能类型不同而不同（详见第3节）。

　　3. JMeter中的元素

　　从功能上讲，JMeter的元素分为八大类以及两个特殊元素。这里从使用场合上对这些元素进行叙述，至于具体每个元素什么功能则需要查看JMeter的帮助（具体方法是点击未知的元素，然后选择Help菜单下的Help选项）。

    Test Plan元素：控制型元素。只能存在于树型结构的根节点。它代表了整个测试方案，测试人员可以在这里设置一些全局性的内容，例如全局变量（注意全局变量是Thread Local的，详见第4节）、ClassPath配置（如果希望在Jmeter中调用自己的Java类需要在这里设置了）等。
    Thread Group元素：控制型元素。只能存在于Test Plan元素之下。它代表了一组行为相似的用户，通常我们把一类用户的动作放在同一个Thread Group下，这样可以模拟多这这样的用户了。在这里可以配置模拟用户的个数（线程的个数）、循环次数、执行时间等。
    Logic Controller：控制型元素。可以存在于Thread Group下任何位子。它用来完成控制其下元素的执行，JMeter提供了很多Logic Controller类型的元素，方便我们在测试中实现基本的逻辑。
    Config Element: 配置型元素。这些元素被用来改变其作用范围内所有动作元素的配置，利用该类元素可以减少很多测试用例编写中的重复工作，例如可以让一个HTTP Request Defaults元素来配置所有用例中HTTP请求的主机地址以及端口号，这样无须在每个动作元素中都做这样的配置了。当Merge发生时，如果某个域只有一个Config Element元素有值，则使用该值；如果某个域有多个Config Element元素有值，则使用离动作元素近的Config Element元素的值（在动作元素节点下的配置元素近）。
    Timer: 配置型元素。如果希望控制请求发出的频率，则应该使用Timer延迟这些请求。当Merge发生时，所有Timer的时间会相加。
    Pre Processor: 配置型元素。用于根据一定条件修改所有被影响的动作元素。当Merge发生时，这些Pre Processor将被依次执行，离动作元素远的先执行。
    Post Processor: 同Pre Processor，只是发生在动作元素之后，用于从响应中提取需要的信息。
    Assertions: 配置型元素。用于对其影响范围内的动作元素的结果进行断言，例如可以断言一些HTTP请求的返回码，如果不通过则系统会记录本次错误。Merge发生时，所有的Assertion都会被判断。
    Listener: 配置型元素。用于监听其影响范围内所有动作元素，测试结果数据主要由该类元素产生，因此他们非常有用。Merge发生时，所有的Listener监控动作都会被执行。
    Sampler: 动作型元素。代表一次请求-响应的过程，他们是测试用例中动作的发起者，是测试用例的主要元素。JMeter根据不同的应用预制了很多种动作元素，如果用户觉得仍然不够用甚至可以用BeanShell Sampler写自己的动作。

　　4. JMeter中的变量

　　有的时候我们希望发送成千上万个随机的请求，或者希望本次请求的内容依赖于前几次的请求，那么需要使用JMeter中的变量（注意，是Variable不是Property），这样可以用变量来配置每一个请求，这样可以让同一个Sampler每次都能发出不同的请求。

　　使用变量时，首先必须注意的是，JMeter中的变量是线程独立（Thread Local）的，也是说虽然我们定义了n个变量，但是在每个线程中都有这n个变量的镜像，他们之间相互独立，互不干扰。

　　当我们希使用变量的时候，首先需要创建所需的变量。在JMeter中创建变量的方式很多，一种途径是通过Test Plan定义全局变量（用于所有的Thread Group，它也是线程独立的），也可以通过Config Element中的User Defined Element来定义不同线程组的局部变量（注意，User Defined Element中定义的变量是用于整个线程组的，无论将这个元素放在哪里都会被应用于整个线程组，这是一个比较特殊的配置型元素），此外当我们在应用中对某个没有创建的变量赋值（后面会讲到赋值）时也会创建该变量。实际上JMeter的源码中是使用Map来实现变量的，因此这些性质也不难理解。

　　当我们希望在某个地方引用一个变量的时候，可以通过${变量名}的语法来获取变量的值。注意，如果这个变量没有被定义，则这个式子会被当作普通的字符串。

　　修改某个变量值的方法有很多，可以通过BeanShell来修改，也可以通过JMeter中一些特定的元素来修改（例如CSV Date Config Element），还可以使用JMeter函数来定义修改某个变量（具体如何做，见后面的小节）。