3 测试计划的组成：
测试计划至少要包含测试计划，一个线程组和一个或多个实例
3.0 测试计划
在创建测试计划时，可以在勾选复选框functional testing（用于记录返回数据）。
若勾选了该选项，则jMeter会记录服务器和各实例返回的数据。若你对实例的监听对象选择了指定文件，那么数据会写入该文件内。这个很有用，可以用来运行检查你的jMeter配置是否正确，你的服务器是否返回了指定的结果。当然，返回数据存在文件里面，肯定会让文件变的很大。这时，你可在配置中选择对监听对象指定写入文件的字段。若你是不想要记录返回的数据，那么该选项对于你来说就是没用的。
当你要做压力测试时，就不要勾选该选项了。
3.1 线程组
所有的测试计划，都是从线程组开始的。所有的控制器和实例都是基于线程的，所以控制器和实例必须放在线程中。其他的部分也可以直接放在测试计划中，便于应用于所有的线程组中，例如，监听对象。正如线程组这个名字一样，它可以控制JMeter执行你的脚本所需要的线程数量，你还可以控制上升时间段和执行测试的次数。
每个线程都是独立的，多线程在这里用来模拟多个同时连接到服务器的请求。
上升时间：在上升时间内，假如是120s，那在120s内，我有30个线程，则每个线程开启的时间将会延迟4s。所以要把握好上升时间，不要过长也不要过短，除非你是故意设置的。120s内30个线程会完全执行完。
在线程组中设置了一个 scheduler 的复选框，你可以选择上升时间段中开始的时间，和线程与线程之间的延迟时间。
3.2 控制器
jMeter有两种控制器：实例和逻辑控制器，用于驱动测试进行。
3.2.1 实例
用于告诉jMeter，发送请求给服务器并等待响应。例如，你想要发送一个http请求，你需要增加一个http请求实例。你也可以通过增加一个或多个配置元素，来自定义实例。这些请求都是按照他们在树种出现的顺序来处理的。
jMeter的实例包含了
每一个实例都包含很多属性，这些属性你是可以自行设置的。你也可以在测试计划中通过添加配置元素里面，自定义一个实例。
如果你想发送多个相同类型的请求到同一个服务器，你可以考虑使用一个默认的配置元素。每一个控制器都有一个或更多的默认元素。
记得添加一个监听器到你的测试计划中，用于观察或存储写到硬盘的请求结果。
如果你想让jMeter在性能测试中对你请求的结果进行一个确认，可以在实例中使用断言。例如，在web应用的压力测试中，服务器返回一个成功的http请求代码，但是页面中的相应部分却是空白的，这样你可以通过断言去检查页面中特定的html标签，错误的字符串等等。jMeter可以使用正则表达式来断言。
3.2.2 逻辑控制器
可以让你自定义jMeter什么时候发送请求的逻辑。例如，你可以使用一个逻辑控制器，交替控制http请求的实例。逻辑控制器可以改变来自子元素的请求顺序。也可以修改请求本身，重复请求等。
为了理解一个测试计划中的逻辑控制器，我们下面的测试树。
关于这个测试的第一件事是，登录请求只用请求一次，子迭代器将会跳过它，这是 once only controller 这个控制器的作用。登录之后，下一个实例将加载搜索页面（这个再web应用中很常见，例如，用户登录后，跳转到搜索页面进行搜索）这只是一个简单的请求，并不会通过任何逻辑方面的控制器过滤。
在加载完搜索页面后，我们想进行搜索。实际上，我们想要做两种不同的搜索。然而，我们想要让每个搜索页面自动的进行重新加载。我们可以这样做创建4个简单的http请求元素（加载搜索，搜索“A”，加载搜索，搜索“B”）。实际上，我们是使用的内存交错控制器，它是每次通过传递一个子请求来实现的。它维持各个子请求的顺序（不会随机的传递一个子请求，而会记录他的顺序）。交错控制两个子请求有点大材小用了，最好是用于控制8或20个子请求。
注意，Http Request Default 是属于交错控制器类型的。想象一下，搜索“A”和搜索“B”共享同一个路径信息（一个http请求格式包括域名，端口号，方法，协议，路径和查询参数等其他可选项）。这是很有意思的，两个搜索请求都是访问的相同的后端搜索引擎（servlet 或者 cgi-script）。我们并不会配置两个相同的http实例（这两个http请求的路径字段是一样的），我们会提取出这个相同的信息配置成一个单独的配置元素。当交错控制器切换搜索页面的时候，它将会自动的从http默认请求配置元素中去填充这个空白值。因此，我们要让PATH字段对这一类请求为空，然后从配置元素中去填充这个信息。虽然这个例子不是很好，但是它很好的展示了这个特性。
在这个大的测试树中的下一个元素是另一个http默认请求，这个是是加在线程组中的。这个线程组有一个内置的逻辑控制器，它就是用的这个配置元素。http默认请求 可以填充任何由这个配置的空白字段。在web测试中，这一点非常好用，它可以让所有的http实例元素中的域名字段留空，并将那些域名信息放进http默认请求元素中，加入到线程组。通过这样做，你只用修改一个字段就可以在不同的服务器上测试你的应用程序，否则你就只有去依次修改每一个实例。
最后一个元素是http cookie manager，一个cookie manager 应该加入到所有web测试当中，否则jMeter将会忽略这些cookie。通过在线程组增加cookie，我们可以在所有的http请求中共享相同的cookie。
逻辑控制器可以和其他的元素结合来实现各种效果，可参考 内置逻辑控制器。
3.2.3 测试片段
测试是一种特殊类型的控制器，它存在于测试计划树中，与线程组同级。但是它和线程组最大的区别是它不会执行，除非该测试片段被一个模块控制器（module Controller）或一个包含控制器（include_Controller）指定了要运行。
这个元素完全就是为了能在测试计划中进行代码重用。
3.3 监听器
监听器可以在jMeter运行测试用例时获取数据信息。图标结果监听器（Graph Results）可以在图表中绘制相应时间。查看结果树（View Results Tree）监听器能显示实力请求和响应的各种详细信息，并呈现基本的HTML和XML格式得响应。其他的监听者提供了总结信息。
除此之外，监听者可以让数据写入一个文件中，为之后的使用做准备。jMeter中的每个监听者都有一个字段去表示这个监听者指定写入数据的文件。通过配置按钮去选择哪个字段用来存储，是否适应CSV或XML格式。
注意：所有的监听者都保存相同的数据，不同的是它们呈现数据的方式不同。
监听者可以在测试的任何位置去加入，直接在测试计划中去加入监听也可以。它们只会从同级或下级的元素中收集数据。
jMeter中有很多监听者，可参考官方文档
3.4 定时器
默认情况下，一个jMeter线程会不停歇的执行在队列中的实例。所以，推荐在线程组中增加一个定时器去明确的延时。如果你不加延时，jMeter会将你的服务器淹没的 - . -|||，因为它会在很短时间向服务器做许多请求。
一个定时器会让在每个实例在它自己的作用域中延迟一定的时间。
如果你选择在线程组中增加一个或多个定时器，jMeter将会计算每个定时器设置的时间之和，并在执行每个实例前等待这段时间。定时器可以增加在实例和控制器的下一个层级中，去限制这些实例。
为了在一个测试计划中的一个位置去暂停，你可以使用Test Action实例。
3.5 断言
断言允许你断定测试过程中从服务器返回的响应。使用一个断言，你可以简单判断你的应用程序是否返回了你期望的结果。
例如，你可以判断一个查询的响应是否包含某些特殊的字符串。你可以写一个Perl-style的正则表达式，并且用它去判断响应中是否包含或匹配含这个正则表达式所表达的文本内容。
你可以增加一个断言到任何实例中。例如，你可以增加一个断言到http请求中，去检查文本</html>标签.然后，jMeter将会去检查响应中是否有这个文本内容，如果没有，jMeter将会把这个请求标记为失败请求。
注意：断言是应用在所有实例的各自作用域中的。为了限制单个的实例，可以增加断言为实例的一个孩子。
为了观察断言的结果，增加一个断言监听器到一个线程组中。失败的断言将会出现在在Tree View和Table listener中，并且在总的报告中显示百分比。
3.6 配置元素
配置元素和实例之间联系很大。虽然它不会发送请求（除了，http/https test recorder），它可以增加请求次数或修改请求。
一个配置元素是只能写在测试树的一个分支里面。例如，下图中
配置元素HTTP cookie manager只能作用于web page1 和 web page2 ,不能作用于web page3 , 即它的同级，下一级和同级的下一级。
位于分支中的配置元素优先级高于位于它的父级配置元素。例如我们定义了两个HTTP请求默认元素，web default 1和web default 2 。因为我们将web default 1放在了一个 Loop Controller中，所以web defaults 1里对web page2的配置高于web defaults 2.
注意：用户定义变量配置元素是不一样的。不管它放置在哪个位置，都会被优先处理。建议这种元素最好放在线程组的开头。
3.7 预处理元素
它是在实例请求发生之前执行的一些动作。例如说，一个预处理元素加在一个实例元素上，那么在这个实例运行之前会先执行这个预处理程序。预处理元素通常用于改变实例执行的一些设置或者更新一些变量（不是从响应中抽出来的）。详情可参考作用域
3.8 后处理元素
参考预处理元素，不过它是在实例元素运行之后执行。它多用于处理响应数据。
3.9 执行顺序
请注意，定时器，断言，预处理和后处理器的执行必须要应用在一个实例中。控制器和实例的执行顺序是按照他们出现在测试树中的顺序执行的。其它的一些测试元素的处理顺序是根据他们在它们各自的作用域以及测试元素的类型（相同类型下，处理顺序按照它们在树中出现的顺序处理）。
例如：
3.10 作用域规则
jMeter测试树包含的元素既是分层次的又是有顺序的。在测试树中的一些元素是非常严格分层的（监听对象，配置元素，后处理元素，预处理元素，断言，定时器），一些元素也是按照基本顺序来执行的（控制器和实例）。当你创建一个测试计划时，你将通过创建一些实例来创建一个有序的实例请求列表，来呈现一个执行步骤的集合。这些请求通常都是用控制器来组织的，并且这些请求也是有顺序的。如下是两个例子：
配置元素：header manager，cookie manager 和 authorization manager 不同于 默认的配置元素（configuration default elements) 。一般的默认配置元素会和实例的值的集合合并。然而，上述三类管理配置元素不会合并。如果一个实例的作用域内有多个这种管理配置元素，那么只会有一个管理元素会被使用，但是当前是没办法知道使用的是哪一个。
3.11 属性和变量
jMeter的属性在jMeter.properties中定义。这些属性是全局有效的，通常情况下，我们只会定义一些默认的属性来用。例如，属性remote_hosts定义了jmeter将要远程运行的服务器是哪一个。属性可以在测试计划中指定，但是不能在特殊线程值中使用，参考functions-read a property。
jMeter的变量对每一个线程都是局部有效。这个变量值可能可能一样也可能不同。如果一个变量值由一个线程来更新，那么只有这个变量的thread copy改变。例如说后处理程序将会根据实例线程读取到的变量来设置正则表达式提取器的变量值，再应用到随后的相同线程里。更多详细的请参考原文。
注意，测试计划和用户定义变量（UDV）配置元素定义的值在整个测试计划开始时是有效的。如果相同的变量由多个UDV元素定义，那么只有最后一个有效。一旦一个线程开始，每个线程的相关变量将会初始化。其他元素例如User Parameters Pre-Processor 或者 Regular Expression Extractor Post-Processor可能被用来重定义这个相同的变量，或者创建一个新的变量。这些重定义的变量只对当前的线程有效。
setProperty函数被用来定义一个jMeter的属性。这些属性是对测试计划全局有效的，所以在必要时 能够用来在线程之间传递信息。
变量和属性都是大小写敏感的。
3.12 使用变量参数化测试
使用变量当参数。当你决定怎样构建测试计划时，可以写下什么是线程运行不变量，什么是线程运行之间要变化的。变量名的命名约定，比如用C_或K_作为前缀，或者用大写来区分变量和测试期间需要改变的变量。 还要考虑哪些变量是对线程局部有效的 - 例如计数器或使用正则表达式后处理器提取的值。
例如：
关于servlet的文章： http://blog.csdn.net/honghailiang888/article/details/50585475
原文：http://jmeter.apache.org/usermanual/test_plan.html