本文非原创，转载自网络，尊重作者版权
综述：
在客户端程序上，与LR相比，jmeter只有一个主程序，脚本设计、场景设计、运行监视、报告结果均在一起完成，没有独立的调试器，所以脚本实际上跟场景是一体的；
在概念上，jmeter的测试计划可以对应LR的测试场景，而线程组可以对LR的测试脚本，与LR不同的是，jmeter的线程组既可以设置各自的并发用户数，也可以设置各自的运行时间；jmeter使用各种取样器作为请求的发生器，比如我们会经常用到的“HTTP请求”取样器，可以对应到LR的请求函数“web_url”（get）“web_submit_data”（post）；使用逻辑控制器来实现“if”“swith”“for each”“while”来实现逻辑语法；定时器可以实现think time；报表中的Throughput对应LR中的TPS，KB/sec对应LR中的Throughput，这一点可能容易混淆。
在结构上，jmeter使用各种元件组成脚本，代码为树形结构（.jmx脚本为xml格式）。
在功能上，jmeter没有独立的调试器，必须运行来进行脚本的调试；没有目标场景，但从用户手册的说明上来看，应该可以通过元件组合实现目标场景；只有针对响应时间的统计图形展现，没有针对事务数的统计图形展现；资源监视模块只针对tomcat（5以上），解析tomcat的status返回的xml来实现，没有Linux资源监控。
脚本功能：
利用代理服务器截取协议包方式，脚本形式为xml，解析执行，没有单独的调试器。代理服务器可以生成“HTTP请求”取样器脚本以及定时器。
Jmeter脚本由各种jmeter元件组成。这些元件有：取样器、配置元件、定时器、逻辑控制器、前置处理器、后置处理器、断言、报告。
取样器：生成压力的元件，如产生http请求、ftp请求等
配置元件：与脚本中的配置有关，如用户变量、cookies设置、http头设置等
定时器：产生延时（think time）
逻辑控制器：对代码做逻辑控制，如if条件判断、for循环等
前置处理器：取样器操作前的处理，如用户参数、URL rewrite等
后置处理器：取样器操作后的处理，如提取响应信息（关联数据）等
断言：即检查点，支持正则
报告：结果展现，如响应数据、服务器监控数据等
参数化文件：两种读取方式——CSV Data Set Config元件和函数：
CSV Data Set Config元件提供比较丰富的参数设置：编码方式、分隔符、循环使用、共享模式；这里有一个注意点：“Allow quote data”选项选为“true”的时候对全角字符的处理出现乱码。利用设置共享模式可以实现在LR中的“Sequential”和“Unique”，对应选项为：“Sequential”用“Current thread”；“Unique”用“Current thread group”（当前的线程组内）或“All treads”（所有的线程组中）。
“StringFromFile”和“CSVRead”函数也可以实现读取参数化文件，“StringFromFile”的方式类似于“Unique”，而“CSVRead”很特别，是每个线程只读取一行作为参数，无论循环多少次，各个线程依次读取。
其它参数化，函数实现：
1. 使用线程名作为参数：“threadNum”函数，返回格式为“线程组名称+空格+线程组编号+横线+线程编号”；
2. 使用机器名作为参数：“machineName”函数；
3. 使用时间作为参数：“time”函数；
4. 使用随机数作为参数：“Random”函数
检查点：jmeter提供的断言种类很丰富，支持正则表达式的多种匹配规则。
压力产生的元件是取样器，其中最常用的是“HTTP请求”。利用逻辑控制器元件可以实现条件判断、循环等算法。
另外jmeter提供了后置处理器元件建立关联，常用的是“正则表达式提取器”元件，提取响应返回的数据产生关联数据，进行后续处理或用于后面的请求。
场景设置：
没有目标场景
线程组可理解为LR Controller中的单个脚本，多个线程组就是多个脚本，可以通过禁用/启用操作来控制执行的线程组。
可以设置逐步增加压力，也可以设置一次性加压。
设置集合点：通过“Synchronizing Timer”这个定时器，可以设置多少个并发用户集合到一起。
监控资源：使用“监视器结果”来监控，但目前只支持tomcat（5以上）；原理：该功能是通过解析tomcat的管理status返回的xml实现的；监控得到的结果是负载、内存、线程。
可以通过逻辑控制器，以及不同的配置原件来模拟不同的业务场景
