jmeter用户手册(编辑修改稿)

jmeter用户手册(编辑修改稿)内容摘要：

新的格式重新保存它。 配置树中的元件 任何在测试树（ Test Tree）中的元件（ element）将在 JMeter右手的帧中显示控制器。 这些控制器允许你配置某种测试元件的行为。 对于每个元件可配置的内容决定于元件的类型。 测试树本身可以通过拖拽组件来操作。 执行测试计划 要运行测试计划，从 “运行 ”菜单中选择 “开始 ”。 要停止你的测试计划，从同一个菜单中选择 “停止 ”。 JMeter不会自动给出测试计划当前 是否正在运行。 如果JMeter正在运行着，某些监听器可以使这变得显而易见，但可靠的方法是检查“运行 ”菜单。 如果 “开始 ”是禁用的，并且 “停止 ”是启用的， JMeter正在运行你的测试计划（或者，至少， JMeter是这么认为的）。 Scoping Rules The JMeter test tree contains elements that are both hierarchical and ordered. Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, PostProcesors, PreProcessors, Assertions, Timers), and some are primarily ordered (controllers, samplers). When you create your test plan, you will create an ordered list of sample request (via Samplers) that represent a set of steps to be executed. These requests are often anized within controllers that are also ordered. Given the following test tree: Example test tree The order of requests will be, One, Two, Three, Four. Some controllers affect the order of their subelements, and you can read about these specific controllers in the ponent reference. Other elements are hierarchical. An Assertion, for instance, is hierarchical in the test tree. If its parent is a request, then it is applied to that request. If its parent is a Controller, then it affects all requests that are descendants of that Controller. In the following test tree: Hierarchy example Assertion 1 is applied only to Request One, while Assertion 2 is applied to Requests Two and Three. Another example, this time using Timers: plex example In this example, the requests are named to reflect the order in which they will be executed. Timer 1 will apply to Requests Two, Three, and Four (notice how order is irrelevant for hierarchical elements). Assertion 1 will apply only to Request Three. Timer 2 will affect all the requests. Hopefully these examples make it clear how configuration (hierarchical) elements are applied. If you imagine each Request being passed up the tree branches, to its parent, then to its parent39。 s parent, etc, and each time collecting all the configuration elements of that parent, then you will see how it works. 测试计划中的元件 测试计划对象有几个新的叫做 “功能测试 ”的 选择框。 如果选中， JMeter 将会记录从每个服务器的每个样本返回的数据。 如果你在监听器中选择一个文件，那么这些返回的数据会被写入这个文件。 如果你在测试是否 JMeter被正确配置和服务器是否返回期望的结果，这是很有用的。 结果是记录返回数据的文件将会变得巨大，接着 JMeter的性能会降低。 如果你在做压力测试，这个选项应该是关闭的（它默认是关闭的）。 如果你没有向文件中记录数据，那么这个选项不会造成任何区别。 线程组 线程组元件是任何一个测试计划的开始点。 在一个测试计划中的所有元件必须在某个线程组下。 顾名思义，线程组元件控制 JMeter执行你的测试计划时候使用的线程数。 对线程组的控制允许你：  设置线程数  设置 rampup period  设置测试要执行的次数 每个线程都会完全独立的运行测试计划，互补干扰。 多线程用于模拟对服务器的并发访问。 rampup period 指示 JMeter用于达到全部选择的线程的时间。 如果选择了10个线程，并且 rampup period是 100妙，那么 JMeter将使用 1 00秒钟使 10个线程启动并运行。 每个线程将在前一个线程启动后 10（ 100/10）秒后启动。 如 果有 30个线程并且 rampup period是 120秒，那么相继的线程将间隔 4秒。 缺省情况下，线程组被配置为不确定的循环执行它下面的元件。 另外，你可以设置线程组在结束前循环的次数。 如果次数设置为 1，那么 JMeter在停止前只执行测试计划一次。 版引入了一个测试运行 调度器 . 点击线程组面板的下方的复选框来显示两个额外的字段，可以输入运行开始和结束时间。 当测试开始时，如果设置了调度器， JMeter将等待直到到了开始时间。 在每个周期结束， JMeter将会检查是否到达结束时间，如果是这样的话，停 止运行，否则测试继续运行 知道达到了重复限制。 控制器 JMeter有两种类型的控制器：取样器和逻辑控制器。 取样器指示 JMeter向一个服务器发送请求。 例如，如果你想让 JMeter发送HTTP请求，那么添加一个 HTTP请求取样器你可以向一个取样中添加一个或多个配置元件来定制请求。 查看 取样器 获得更多信息。 逻辑控制 器允许你定制 JMeter何时发送请求。 例如，你可以添加交替（ Interleave） 逻辑控制器来在两个 HTTP请求取样器之间轮流。 同样地，每个逻辑控制器，修 改管理器（ Modification Manager），允许你修改请求的结果。 查看 逻辑控制器 获得更多信息。 取样器 取样器指示 JMeter向一个服务器发送请求。 JMeter目前有如下取样器：  FTP 请求  HTTP 请求  JDBC 请求  Java 对象请求  LDAP 请求  SOAP/XMLRPC 请求  Web服务 (SOAP) 请求 (Alpha Code) 每个取样器有几个可以设置的属性。 你可以向取样器添加一个或多个配置元件来更进一步的控制取样器。 除此之外， JMeter以你向树中添加取样器的顺序发送请求。 如果你想向一个服务器发送同种类型的多个请求（例如， HTTP请求）。 考虑使用 缺省配置元件（ Defaults Configuration Element）。 每个控制器有一个或 多个缺省元件（见下文）。 记得向线程组添加一个监听器来查看和 /或存储请求结果到磁盘。 如果想让 JMeter在请求的回复上做基本的验证，添加一个 断言 到请求控制器。 例如，在对 Web应用做压力测试时，服务器会返回一个成功的 “HTTP回复 ”代码，但页面可能会 有错误或缺少内容。 你可以添加断言来检查某些特定的 HTML标签，一般的错误字符串，等等。 JMeter允许你使用正则表达式创建这些断言。 JMeter自带的例子 逻辑控制器 逻辑控制器允许你定制 JMeter何时发送请求。 逻辑控制器可能包含如下子元件：取样器（请求），配置元件，和其他的逻辑控制器。 逻辑控制器能够更改它 的子元件中的请求的顺序。 他们可以自己修改请求，使 JMeter重复请求，等等。 要理解逻辑控制器对测试计划的影响，假设如下的测试树：  Test Plan o Thread Group  Once Only Controller  Login Request (an )  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) The first thing about this test is that the login request will be executed only the first time through. Subsequent iterations will skip it. This is due to the effects of the . After the login, the next Sampler loads the search page (imagine a web application where the user logs in, and then goes to a search page to do a search). This is just a simple request, not filtered through any Logic Controller. After loading the search page, we want to do a search. Actually, we want to do two different searches. However, we want to reload the search page itself between each search. We could do this by having 4 simple HTTP request elements (load search, search A, load search, search B). Instead, we use the which passes on one child request each time through the test. It keeps the ordering (ie it doesn39。 t pass one on at random, but remembers its place) of its child elements. Interleaving 2 child requests may be overkill, but there could easily have been 8, or 20 child requests. Note the that belongs to the Interleave Controller. Imagine that Search A and Search B share the same PATH info (an HTTP request specification includes domain, port, method, protocol, path, and arguments, plus other optional items). This makes sense both are search requests, hitting the same backend search engine (a servlet or cgiscript, let39。 s say). Rather than configure both HTTP Sample。