创建测试计划
一个最小的测试包含测试计划(test plan)、线程组(thread group)、一个或多个样例(sampler)。
测试计划
测试计划对象里有个复选框叫“Functional Testing”.如果勾选了，jmeter会记录每个sample从server端返回的结果。如果在test listeners中选择了文件，数据会保存到文件里。如果你正在做一个小例子来确保jmeter是配置正确的，或者说确保server端返回了期待的结果，这种情况下非常有用。不过，勾选的结果就是文件会很快变得很大，jmeter也会遭受性能问题。如果你在做压力测试，这个选项应该关闭（默认就是关闭的）。
线程组
线程组是任何测试计划的起点。所有的controller和sampler必须在一个线程组下。另外一些元素，比如listener，也许会直接放在test plan之下，这种情况listener会应用到所有的线程组。见名知意，线程组元素控制了jmeter的线程数量，jmeter用线程组来执行测试。控制线程组可以让你做：
- 设置线程数量
- 设置启动周期（ramp-up period）
- 设置执行测试的次数
每个线程都会完全独立于其它线程执行测试计划。多线程用来模拟并发连接服务端应用。
ramp-up period告诉jmeter，消耗多长时间跑起来全部线程。如果用10个线程，ramp-up period是100秒，那么jmeter将会消耗100秒来让10个线程起来和运行。每个线程会在上一个线程起来之后10秒（100/10）后启动。如果是30个线程，ramp-up period是120秒，那么每个成功的线程将会被延迟4秒。
The ramp-up period tells JMeter how long to take to “ramp-up” to the full number of threads chosen. If 10 threads are used, and the ramp-up period is 100 seconds, then JMeter will take 100 seconds to get all 10 threads up and running. Each thread will start 10 (100/10) seconds after the previous thread was begun. If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
ramp-up需要足够长的时间来避免测试开头过大的负载，也得足够短，来让最后一个线程在第一个线程结束之前开始运行。
默认的，线程组会被配置成循环执行一次它的所有元素。
线程组也提供了一个scheduler（调度器）。勾选在Thread Group面板最底下的复选框来启用/禁用其它项，这些项包括测试执行时间、启动延迟、启动和停止的次数。你也可以配置持续时间（duration）、启动延迟时间（startup delay）来控制每个线程组的持续时间和多长时间后再启动。当测试启动了，jmeter会等待startup delay，然后再启动线程组并运行配置的Duration时间。注意这两个选项覆盖start time和end time。
另外，尽管不推荐这样做，因为不灵活，你可以使用其它两个项start time和end time。当test启动了，如果有必要jmeter会一直等待直到start-time到点了。在每个循环的结尾，jmeter check是否end-time到期了。如果到期了，运行就会被停止，否则test会被允许继续执行直到达到迭代次数。
控制器
jmeter有两种类型的控制器：sampler和logical controller。控制器驱动测试进程。
sampler告诉jmeter发送请求给server。比如，增加一个http request sampler如果你想jmeter发送一个http request，你也可以定制一个请求通过增加一个或多个配置元素到sampler。
逻辑控制器让你定制逻辑，来让jmeter使用以决定什么时候发送请求。比如，你可以增加一个插入逻辑控制器来交替执行两个http request sampler。
样例
样例告诉jmeter去发送请求给server并等待响应。他们按照在tree中出现的顺序执行。控制器可以用来修改样例的重复次数。
JMeter样例包括：
- FTP 请求
- Http 请求
- JDBC 请求
- java 对象请求
- JMS请求
- Junit Test请求
- LDAP请求
- Mail请求
- OS Process请求
- TCP 请求
每个样例有好几个属性，你可以设置他们。通过增加一个或多个配置元素，可以进一步定制样例。
如果你打算发送多个同样类型的请求（比如，http 请求），考虑使用一个默认的配置元素。每个控制器有一个或多个默认元素。
记得要，增加监听器以来查看或存储请求结果。
如果你对响应执行基本校验感情去，把样例增加一个断言。比如，在web应用的压力测中，服务器可能返回一个成功的Http response code，但是这个页面可能有错误或者缺失了一些内容。又可以增加断言去check某些html标签、通用错误字符串等等。JMeter允许你是用正则表达式创建这些断言。
逻辑控制器
逻辑控制器允许你定制逻辑，也就是说，你可以用它来控制什么时候发送请求。逻辑控制器可以更改来自子元素的请求顺序。他们自己修改请求本身，以使JMeter重复请求。
为了理解逻辑控制器在test plan中的作用，考虑下边的test tree:
- Test Plan
- Thread Group
- Once Only Controller
- Login Request(an Http request)
- Load search page(Http sampler)
- interleave controller
- Search “A”(Http sampler)
- Search “B”(Http sampler)
- http default request(Configuration Element)
- Http default request(Configuration Element)
- Cookie Manager(Configuration Element)
第一件要考虑的事就是login request只能被执行一次。后续的迭代都会跳过他。这是因为Once Only Controller的作用。
登陆后，下一个Sampler加载Search Page。这是一个简单的请求，不会被任何Logic Controller过滤。
加载完search page后，我们想去搜索。实际上，我们想去两个不同的搜索。然而，我们想去再一次加载search page，在两个搜索之间。这样做的话，包含4个简单的http 请求元素（load search、search A、load search、search B）。然而，我们使用Interleave Controller（每经过这个测试传入它）。他保持着子元素的顺序（他不会随机传入，相反会记住位置）。插入两个子请求也许能客服，但是如果是8/20个自请求将会很简单。
注意，http request default属于Interleave Controller。设想search A和 searchB分享了相同的路径信息（domain、port、method、protocol、path、参数）。这就清晰了：两个都是搜索请求，集中了相同的后端搜索引擎。不是用相同的信息配置两个http sampler，而是抽象相同的信息到configuration element。当interleave controller传入来自search A或者search B请求，它会用http default request的值来填充空白。所以，我们将Path留白，将信息填入Configuration Element。在这个例子中，充其量有一点点好处，但是它举例了这个特性。
下一个元素是另外一个Http default request，这次增加到Thread Group。Thread Group还有个内置的Logic Controller，并且，它使用Configuration Element就像上边描述的。它填充传入请求的空白域。尤其在web测试中将domain留空有用，将信息放入http default request element。这样做，你可以测试在不同server上的应用仅仅修改一个field。否则，你必须编辑每个sampler的domain。
最后一个元素是Http Cookie Manager。一个Cookie Manager应该被添加到所有web test中，否则JMeter会和忽略cookie。通过在Thread Group中增加它，我们确保所有HTTP 请求会分享相同cookie。
Logic Controller可以被联合起来完成不同的结果。
原文出处
