1、Jmeter体系结构
元件：代表Jmeter工具菜单中的一个子菜单（功能），比如HTTP请求、事务控制器、响应断言等，就是一个元件。多个类似功能组件的容器（类似于类）
元件的作用域：
元件执行顺序：
组件：一组元件的集合（一个或多个），比如逻辑控制器中有事务控制器，仅一次控制器、循环控制器等，这些都是元件，但他们被归类到逻辑控制器中，逻辑控制器就是组件。实现独立的某个功能（类似于方法）
X1~X5：负载模拟的一个过程，使用这些组件来完成负载的模拟
Y1：包含的是负载模拟部分，负责模拟用户请求。
Y2：结果验证部分，负责验证结果正确性。
Z：负责结果的手机，实践上只有一个组成部分——监听器，监听器不仅可以放在线程组之内，也可以放在线程组之外。
JMeter基本原理是建立一个线程池，多线程运行取样器产生大量负载，在运行过程中通过断言来验证结果的正确性，通过监听器来记录测试结果。如果取样器中有参数化的需求,可以通过X2中的配置元件或者前置处理器来完成。如果有关联需求，可以通过后置处理器来完成。如果我们想要设置运行场景，比如模拟多少用户，运行多长时间，就设置线程组。如果我们想要模拟并发场景，可以利用定时器来设置；如果我们想要控制业务的执行逻辑，比如登录只运行一次，我们可以用控制器来完成。
2、X1【取样器】
取样器：用来模拟用户操作，向服务器(被测试系统)发出Http请求、WebService(SOAP/XML-RPCRequest)请求或者Java请求等。我们可以把Http请求元件看成是一个没有界面的浏览器，它可以发送Http请求，接收服务器的响应数据。
取样器的访问路径:【测试计划】一【线程组】一【Sampler】
3、X1【断言】
断言：用来验证结果是否正确，用过LoadRunner的读者应该会知道检查点这个功能，可以帮助我们来判断请求是否成功返回且是否符合要求，在JMeter中我们不叫检查点，我们叫断言。说白了就是用一个预设的结果(值、表达式、时间长短等条件)与实际结果匹配，匹配到则成功，反之失败。
JMeter2.11版本的断言元件有13个，比如响应断言、XML断言、BeanShell断言；较常用的是响应断言；对于复杂的断言还可以通过 BeanShell脚本来完成(BeanShell是类Java的脚本语言，实际上BeanShell是一个小巧的Java源码解释器，可以直接调用Java程序，具体有关BeanShell的内容请到官网http://www.beanshell.org/了解)。
[断言的访问路径是：【测试计划】-【断言】。
4、X1【监听器】
JMeter的测试结果需要添加监听器来收集，JMeter结果收集程序的设计模式就是监听器模式。
JMeter的监听器有两个任务。(1)添加结果监听，并且可以保存测试结果到文件，这些结果数据可以供再次分析使用。(2)展示结果，JMeter可以以表格及图形的形式展现结果，方便测试人员分析测试结果。我们在开发测试脚本时，不可避免需要调试，监听器也提供了辅助(比如察看结果树，我们可以在其中看到请求与响应的数据)。
JMeter监听器共有19个元件，访问路径是：【测试计划】-【监听器】。
【取样器】、【断言】、【监听器】组合在一起就可以帮我们完成发送请求、验证结果及记录结果三项工作。
5、X2【前置处理器】
在测试脚本开发过程中，我们在请求发送前可能会做一些环境或者参数的准备工作，那么我们可以在前置处理器中来完成这些工作。比如，我们在对数据库进行操作前需要先建立一个数据库连接，那么前置处理器就可以完成这个功能。前置处理器访问路径：【测试计划】-【前置处理器】。
6、X2【配置元件】
性能测试中为了模拟大量用户操作我们往往需要做参数化，Jmeter的参数化可以通过配置元件来完成，比如CSVData SetConfig,它可以帮助我们从文件中读取测试数据。另外JMeter也提供了众多的函数(通过函数助手可以查看到)来帮我们生成动态数据。当然配置元件的作用不仅于此，它还可以用来记录服务器的返回数据，比如HttpCacheManager，自动记录服务器返回的Cache信息。简而言之它为取样器提供预备数据，然后由取样器发出请求。取样器访问路径：【测试计划】-【配置元件】。
7、X2【后置处理器】
后置处理器一般放在取样器之后，用来处理服务器的返回结果，比如一个Web应用程序，我们登录后会返回一个SessionID，这个SessionID在登录之后的业务操作过程中会作为验证条件，验证用户是否合法登录了。我们利用取样器模拟这个请求时就需要带上这个属性，那么如何获取呢? 首先我们要知道这个SessionID从哪里来?它是由服务器返回的。接着我们要获取它，用什么工具获取呢?JMeter帮我们提供了元件，比如正则表达式提取器，它支持正则表达式的方式来提取数据。
后置处理器就是专门用来对响应数据做处理的元件，JMeter的关联就是通过后置处理器来完成的。
访问路径：【测试计划】-【后置处理器】。
【前置处理器】、【配置元件】、【后置处理器】都是为取样器提供数据支持的，取样器关注的是业务逻辑。
8、X3【控制器】
我们在收邮件时，只需要登录一次邮箱即可以查看多封邮件。如果这个场景我们要在JMeter中实现，我们需要控制登录的次数，如何实现呢？JMeter逻辑控制器（后续说到控制器时默认为逻辑控制器）中的仅一次控制器即可以完成。当然了，控制器不只有这一个，还有很多其他的控制器来完成我们的各种需求。打游戏有攻略，各种招式完全超乎设计人员想象；控制器用法也有攻略，组合在一起也能够完成各种奇葩需求。
控制器的访问路径：【测试计划】-【线程组】-【逻辑控制器】。
9、X4【定时器】
为了足够真实的模拟用户负载，我们有时会需要模拟这些请求在同一时刻发送，就好像把大家集合在一条起跑线上，然后一声令响，同时起跑。那么我们此时需要一个集合的功能，JMeter中可以通过定时器来完成这个需求。当然了，定时器可不只有这一个功能，定时器种类有很多，每一种代表了不同的功能，基本能够满足我们的所有幻想。
访问路径：【测试计划】-【线程组】-【定时器】。
10、X5【线程组】
性能测试需要模拟大量用户负载的情况，线程组就是用来完成这个工作的，在此元件中我们可以设置运行的线程数(就是模拟多少用户，一线程一用户)。线程组的设置十分简单，除了设置线程数以外，还可以设置运行时长，定时运行等。另外第三方插件(JMeter Plugin)的扩展也让JMeter的场景设计更加丰富。
访问路径：【测试计划】-【Threads(Users)】。
11、Jmeter测试计划要素
JMeter中一个脚本即是一个测试计划，也是一个管理单元。JMeter的请求模拟与并发数(设置线程数，一个线程代表一个虚拟用户)设置都在脚本文件中一起设置。不像LoadRunner把脚本与虚拟用户设置分开。测试计划要素如下。
（1）要素一：脚本中测试计划只能有一个
Jmeter测试计划类似LoadRunner Controller中的测试场景，同一时刻场景故然只能有一个，JMeter脚本在GUI中显示时是树型结构，测试计划是根节点，根节点当然只能有一个。
（2）要素二：测试计划中至少要有一个线程组
JMeter负载是通过线程组驱动的，所以计划中至少要出现一个线程组，也许你只运行一个线程。JMeter测试计划支持多个线程组。我们可以在计划下面建立多个线程组，类似LoadRunner中的Group方式的场景(没接触过LoadRunner的读者可以自行忽略有关LoadRunner的说法)，把不相关联的业务分布在不同的线程组(LoadRunner中的不同Group)。所以我们可以把JMeter计划理解成LoadRunner中的Group方式场景。
（3）要素三：至少要有一个取样器
测试的目的就是要模拟用户请求，没有取样脚本就毫无意义，没有意义就不用谈论对错了。
（4）要素四：至少要有一个监听器
测试结果用来衡量系统性能，我们需要从结果中分析系统性能。
其他元件都是为这些要素服务的，到底当前元件下能够添加哪些种类的元件呢？用户不用担心，JMeter做了严格控制。【添加】菜单后列出的组件列表即是我们可以在线程组下添加的组件种类，组件节点下列出了可以添加的元件。
12、【小结】
第一，利用取样器模拟用户请求；如果需要做一些数据及环境的准备，那么就使用配置管理器;如果需要对响应的数据做处理，使用后置处理器。
第二，控制运行；使用线程组来设置运行场景，利用逻辑控制器来控制业务(实际就是控制取样器)。
第三，收集结果，利用断言来验证测试结果，利用监听器来收集显示测试结果。同时JMeter也支持远程运行，弥补单台机器负载不够的情况。远程运行时远程负载机要运行Agent(jmeter-server.bat来启动)。
