03测试计划中的元素

来源:互联网 发布:飞秋2013正式版 mac版 编辑:程序博客网 时间:2024/06/10 08:24

03测试计划中的元素

Created Tuesday 23 May 2017

本章描述了一个测试计划中的不同部分,一个最小的测试将包含测试计划,一个线程组和一个或多个取样器。

测试计划

测试计划对象有一个复选框叫作“功能测试”。如果选中了,就会导致JMeter记录每个取样器从服务器返回的数据。如果你在你的测试监听器中选中一个文件,那么这些数据将会写到文件中。这非常有用,如果你想做一个简单的运行来验证你的JMeter配置正确,你的服务器返回了期望的结果。结果会是文件会快速增长巨大,并且JMeter的性能会受损。如果你做压力测试的话,这个选项应该要关闭。

如果你不记录数据到文件,这个选项可以不用。你也可以使用监听器的配置按钮决定什么字段保存。

线程组

线程组元素是任何测试计划的开始点。所有的控制器和取样器都必须在线程组下面。
其他元素,例如,监听器可以直接放到测试计划下面,在这种情况下,他们就会被应用到所有线程组。
就像名字所显示的,线程组元素控制做JMeter将会用于执行你的测试的线程的数量。

Each thread will execute the test plan in its entirety and completely independently of other test threads.
每个线程将会在它的内部中执行测试计划,完全独立于其他的测试线程。
Multiple threads are used to simulate concurrent connections to your server application.
多线程被用于模拟对你的服务器应用的并发连接。

The ramp-up period tells JMeter how long to take to “ramp-up” to the full number of threads chosen.
ramp-up period 告诉JMeter要多久才能加大到你选用的全部线程数。
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.
如果使用10个线程,加强期是100s,那么JMeter将会话费100s达到10个线程并运行。
Each thread will start 10 (100/10) seconds after the previous thread was begun.
每个线程将会前面的线程启动后10s是启动。
If there are 30 threads and a ramp-up period of 120 seconds, then each successive thread will be delayed by 4 seconds.
如果是30个线程,加强期是120s,那么每个连续的线程将会延迟4s。

Ramp-up needs to be long enough to avoid too large a work-load at the start of a test, and short enough that the last threads start running before the first ones finish (unless one wants that to happen).
加强期需要足够长以避免在测试启动的时候太大的压力,足够短以至于在第一个线程结束前后续的线程开始运行。

Start with Ramp-up = number of threads and adjust up or down as needed.
开始Ramp-up,按照需要来调整线程数上下。
By default, the thread group is configured to loop once through its elements.
默认地,线程组被配置自通过它的元素开始循环。

Thread Group also provides a scheduler.
线程组提供一个调度器。
Click the checkbox at the bottom of the Thread Group panel to enable/disable extra fields in which you can enter the duration of test, the startup delay, the start and end times of the run.
点击线程组面板中按钮的复选框,来启用或者关闭扩展你可以输入测试时长,启动延迟,运行的开始和技术时间的域。
You can configure Duration (seconds) and Startup Delay (seconds) to control the duration of each thread group and the after how much seconds it starts.
你可以配置时长和启动延迟来控制每个线程组的时长和多少秒后启动。
When the test is started, JMeter will wait Startup Delay (seconds) before starting the Threads of the Thread Group and run for the configured Duration (seconds) time. Note those 2 options override the Start time and End time.
当测试开始的时候,JMeter将会在线程组启动线程的前等待开始延迟并且运行这个配置延迟时间。主要这两个选项覆盖开始和结束时间。

Alternatively (although not recommended as not very flexible) you can use the two other fields Start time and End time.
另外你可以使用其他两个字段开始时间和结束时间。
When the test is started, JMeter will wait if necessary until the start-time has been reached.
当测试开始,如果需要就会等到开始时间到之前JMeter将会等待。
At the end of each cycle, JMeter checks if the end-time has been reached, and if so, the run is stopped, otherwise the test is allowed to continue until the iteration limit is reached.
在每个循环结束时,JMeter会检查结束时间是否到了,如果到了,运行就会停止,否则测试会允许继续知道结束时间到了。

控制器

JMeter has two types of Controllers: Samplers and Logical Controllers. These drive the processing of a test.
JMeter有两种类型的控制器:取样器和逻辑控制器,他们会驱动测试过程。
Samplers tell JMeter to send requests to a server. For example, add an HTTP Request Sampler if you want JMeter to send an HTTP request. You can also customize a request by adding one or more Configuration Elements to a Sampler. For more information, see Samplers.
取样器会发送请求到服务器。例如,如果你想JMeter发送一个HTTP请求,你可以添加一个HTTP Request Sampler,你可以通过配置一个或多个配置元素到取样器来配置一个请求。
Logical Controllers let you customize the logic that JMeter uses to decide when to send requests. For example, you can add an Interleave Logic Controller to alternate between two HTTP Request Samplers.
逻辑控制器在发送请求的时候配置JMeter使用到的逻辑。例如,你可以使用Interleve Logic Controller来在两个HTTP Request Sampler交替使用。

取样器

Samplers tell JMeter to send requests to a server and wait for a response. They are processed in the order they appear in the tree.
取样器告诉JMeter发送请求到服务器并等待响应。它们按照树里出现的顺序执行。
Controllers can be used to modify the number of repetitions of a sampler.
控制器能够被用于修改取样器中的重复的数字。

Each sampler has several properties you can set. You can further customize a sampler by adding one or more Configuration Elements to the Test Plan.
每个取样器你可以设置多个属性。你可以通过一个或多个配置元素到测试计划来进一步配置取样器。

If you are going to send multiple requests of the same type (for example, HTTP Request) to the same server, consider using a Defaults Configuration Element.
如果将要发送多个相同类型的请求到服务器,可以考虑使用默认配置元素。
Each controller has one or more Defaults elements (see below).
每个控制器有一个或多个默认元素

Remember to add a Listener to your test plan to view and/or store the results of your requests to disk.
记住记住添加监听其到你的测试计划中,去查看或者保存你请求的结果到磁盘。

If you are interested in having JMeter perform basic validation on the response of your request, add an Assertion to the sampler.
如果你对请求的响应使用一些基本验证感兴趣,可以添加断言到取样器。
For example, in stress testing a web application, the server may return a successful “HTTP Response” code, but the page may have errors on it or may be missing sections.
例如,在web的压力测试中,服务也许返回成功的HTTP响应,但是页面也许有错误,或者丢失了段落。
You could add assertions to check for certain HTML tags, common error strings, and so on. JMeter lets you create these assertions using regular expressions.
你可以添加断言来检查HTML的标记,通用的错误字符串等等。JMeter让你通过正则表达式创建断言。

逻辑控制器

Logic Controllers let you customize the logic that JMeter uses to decide when to send requests. Logic Controllers can change the order of requests coming from their child elements. They can modify the requests themselves, cause JMeter to repeat requests, etc.
逻辑控制器让你配置JMeter什么时候发送请求的逻辑。逻辑控制器可以改变它的子元素的请求顺序。他们可以修改这些请求,来重复执行请求。

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)
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 Once Only Controller.
测试中第一个东西是登录请求,只会在第一次的时候执行。后续的遍历会跳过。这是因为Once Only Controller的影响。

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 re-load 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 Interleave Controller which passes on one child request each time through the test. It keeps the ordering (i.e. it doesn’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.
加载页面后,我们想要搜索。真实的是我们想要两个不同的搜索。然而我们想要在不同的搜索重新加载搜索页面。我们能够通过四个HTTP请求元素来实现。不这样做,我们使用Interleaver控制器,它将会在测试每次使用一个子请求。它能够保持它的子元素的顺序。

Note the HTTP Request Defaults 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 back-end search engine (a servlet or cgi-script, let’s say). Rather than configure both HTTP Samplers with the same information in their PATH field, we can abstract that information out to a single Configuration Element. When the Interleave Controller “passes on” requests from “Search A” or “Search B”, it will fill in the blanks with values from the HTTP default request Configuration Element. So, we leave the PATH field blank for those requests, and put that information into the Configuration Element. In this case, this is a minor benefit at best, but it demonstrates the feature.
注意HTTP Request Defaults属于Integeleave控制器。想象搜索A和搜索B共享相同的PATH嘻嘻你。这些让两个请求都能感觉到,访问相同的后端搜索引擎。而不是在HTTP取样器中配置相同PATH信息,我们将抽象信息到一个HTTP默认请求配置元素。所以,我们让这些请求的PATH为空,并把这些信息放到配置元素中。在这个例子中,这充其量只有一点好处,职位了演示特性。

The next element in the tree is another HTTP default request, this time added to the Thread Group itself. The Thread Group has a built-in Logic Controller, and thus, it uses this Configuration Element exactly as described above. It fills in the blanks of any Request that passes through. It is extremely useful in web testing to leave the DOMAIN field blank in all your HTTP Sampler elements, and instead, put that information into an HTTP default request element, added to the Thread Group. By doing so, you can test your application on a different server simply by changing one field in your Test Plan. Otherwise, you’d have to edit each and every Sampler.
树中的下一个元素是另一个HTTP默认请求,这次添加到线程组中。这个线程组中有一个构建逻辑控制器,因此,它用于这些配置元素准确来描述以上。它会在使用到请求的空白处。在web测试中在HTTP取样器元素中留下DOMAIN字段空白十分的游泳,我们把这些信息放到添加到线程组HTTP默认请求元素中。这样做,你能够通过改变你测试计划的字段在不同服务器上测试你的应用。而不用,你要去编辑每个取样器。

The last element is a HTTP Cookie Manager. A Cookie Manager should be added to all web tests - otherwise JMeter will ignore cookies. By adding it at the Thread Group level, we ensure that all HTTP requests will share the same cookies.
最后一个元素是HTTP Cookie Manager。一个Cookie Manager应该添加到所有web测试中,否则JMeter将会忽略cookies。通过在线程组级别添加,我们能确认所有HTTP请求将会共享相同的cookies。

测试片段

测试片段是一个特殊类型的控制器,存在测试计划树中和线程组元素同一级。它和线程组显著区别与它不会执行除非通过模块控制器或者包含控制器关联。这个元素纯粹为了在测试计划中复用代码。

监听器

Listeners provide access to the information JMeter gathers about the test cases while JMeter runs.
监听器提供信息的入口,这些信息是在JMeter在运行中由测试用例推断出来的。
The Graph Results listener plots the response times on a graph.
图结果监听器将响应时间绘制在一个图上。
The “View Results Tree” Listener shows details of sampler requests and responses, and can display basic HTML and XML representations of the response.
查看结果树监听器显示取样器请求和响应的详细,并且能够展示表示响应基本的HTML和XML
Other listeners provide summary or aggregation information.
其他监听器提供概要和聚合信息

Additionally, listeners can direct the data to a file for later use.
另外,监听器能够直接将数据保存到文件中用于以后使用。
Every listener in JMeter provides a field to indicate the file to store data to.
在JMeter中的每个监听器都提供一个字段去指明数据要存储的文件。
There is also a Configuration button which can be used to choose which fields to save, and whether to use CSV or XML format.
这里也有一个配置按钮,用于选择那些字段用来保存,和是否使用CSV或XML格式。
Note that all Listeners save the same data; the only difference is in the way the data is presented on the screen.
注意这些监听器会保存这些相同的数据,唯一的不同这些数据在屏幕上表示的方式。

Listeners can be added anywhere in the test, including directly under the test plan. They will collect data only from elements at or below their level.
监听器可以用在测试的任何地方,包括直接在测试计划下面。它们会收集同级或者下级的元素的数据。

计时器

By default, a JMeter thread executes samplers in sequence without pausing.
默认地,JMeter线程按照序列执行取样器而不会暂停。
We recommend that you specify a delay by adding one of the available timers to your Thread Group.
我们推荐你通过添加一个可用的计时器到线程组来指定一个延时。
If you do not add a delay, JMeter could overwhelm your server by making too many requests in a very short amount of time.
如果你不指定一个延时,JMeter就会因为在段时间里太多请求淹没你的服务器。

A timer will cause JMeter to delay a certain amount of time before each sampler which is in its scope.
计时器会在对它作用范围的每个取样器执行一个确定的时间。

If you choose to add more than one timer to a Thread Group, JMeter takes the sum of the timers and pauses for that amount of time before executing the samplers to which the timers apply.
如果你选择添加多个计时器到一个线程组,JMeter会计算计时器的总时间,并在执行计时器应用的取样器前停止这些时间。
Timers can be added as children of samplers or controllers in order to restrict the samplers to which they are applied.
计时器能够作为取样器和控制器的子元素,能够限制他们应用的取样器。

To provide a pause at a single place in a test plan, one can use the Test Action Sampler.
为在测试计划中的某个地方提供暂停的功能,可以使用Test Action取样器。

断言

Assertions allow you to assert facts about responses received from the server being tested.
断言用于去判断来自被测试的服务响应的实情。
Using an assertion, you can essentially “test” that your application is returning the results you expect it to.
通过使用断言,你可以基本上测试你的应用是否返回了你期望的结果。
For instance, you can assert that the response to a query will contain some particular text.
例如,你可以断言查询响应是否包含了一些特定的文本。
The text you specify can be a Perl-style regular expression, and you can indicate that the response is to contain the text, or that it should match the whole response.
这个你指定的文本可以是Perl风格正则表达式,你可以指出响应是包含文本,还是要匹配全部的响应。
You can add an assertion to any Sampler. For example, you can add an assertion to a HTTP Request that checks for the text, “”.
你可以给任意取样器加一个断言。例如,你可以在一个HTTP请求添加一个断言来检查””文本
JMeter will then check that the text is present in the HTTP response. If JMeter cannot find the text, then it will mark this as a failed request.
JMeter将会检查HTTP响应中是否存在这个文本。如果JMeter找不到文本,那么它将会辨识这是一个失败的请求。
Note that assertions apply to all samplers which are in their scope. To restrict an assertion to a single sampler, add the assertion as a child of the sampler.
注意断言会在他们的作用域中应用到所有的取样器。可以通过将断言设置为取样器的子元素来限制仅对当个取样器有用。
To view assertion results, add an Assertion Listener to the Thread Group.
可以通过给线程组添加断言监听器来查看断言结果。
Failed Assertions will also show up in the Tree View and Table Listeners, and will count towards the error %age for example in the Aggregate and Summary reports.
失败的断言会出现在树视图和监听器表格中,并且将会在聚合和统计报表中作为错误率来统计出来。

配置元素

取样器和配置元素密切合作,虽然它不会发送请求,但是它可以添加和修改请求。只有你放置元素的树分支内才可访问配置元素。
例如,如果你放置一个HTTP Cookie Manager放在一个Simple Logic Controller中,只有放置在Simple Logic Controller中的HTTP Request Controller才能访问Cookie Manager(看图1)。
用户定义变量配置元素不一样。它会在测试开始的执行,不管放在任何地方。为了简单,建议把这个元素放置到线程组开始的地方。

前置元素

前置元素会在取样器请求生成之前执行一些动作。如果一个前置元素附上一个取样器,那么它仅仅会在这个取样器元素运行前执行。前置元素通常用于来修改在取样器运行之前修改取样器的设置,或者更新那些来自于响应文本的变量。通过作用域规则查看前置元素执行更多细节。

后置元素

后置元素会在取样器请求执行之后执行一些动作。如果一个后置元素附上一个取样器,那么它仅仅会在这个取样器元素运行后执行。后置元素通常用于来处理响应数据,从中抽取数据。通过作用域规则查看后置元素执行更多细节。

执行顺序

  1. 配置元素
  2. 前置元素
  3. 计时器
  4. 取样器
  5. 后置元素(除了取样器结果为空)
  6. 断言(除了取样器结果为空)
  7. 监听器(除了取样器结果为空)

Please note that Timers, Assertions, Pre- and Post-Processors are only processed if there is a sampler to which they apply.
请注意这些定时器,断言,前置元素和后置元素仅仅会在他们的应用的取样器上进行处理。
Logic Controllers and Samplers are processed in the order in which they appear in the tree.
逻辑控制器和取样器会按照他们在测试树中出现的顺序进行处理。
Other test elements are processed according to the scope in which they are found, and the type of test element.
其他测试元素会根据他们的作用域和类型来进行处理。
[Within a type, elements are processed in the order in which they appear in the tree].
如果是同一个类型,元素就会按照他们出现在树中的顺序来进行处理。

作用域规则

The JMeter test tree contains elements that are both hierarchical and ordered.
JMeter测试树包含层次和顺序的元素。
Some elements in the test trees are strictly hierarchical (Listeners, Config Elements, Post-Processors, Pre-Processors, 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 organized within controllers that are also ordered.
这些请求通常会由规则的控制器来组织。

Some controllers affect the order of their subelements, and you can read about these specific controllers in the component 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.
如果它的父元素是一个请求,那么它仅应用与这个请求。如果是控制器,那么它将影响这个控制器派生的所有的请求。

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 parent’s parent, etc., and each time collecting all the configuration elements of that parent, then you will see how it works.
如果你想象每个请求通过树的分支走到它的父元素,然后到它的父元素的父元素,依次类推。每次都收集这些父元素的所有配置,你将会明白。

属性和变量

JMeter properties are defined in jmeter.properties (see Getting Started - Configuring JMeter for more details).
JMeter的属性在jmeter.properties文件中定义的。
Properties are global to jmeter, and are mostly used to define some of the defaults JMeter uses.
属性对于jmeter是全局的,大部分用于定义JMeter使用的默认属性
For example the property remote_hosts defines the servers that JMeter will try to run remotely.
例如远程主机属性定义了JMeter将会远程运行的服务器
Properties can be referenced in test plans - see Functions - read a property - but cannot be used for thread-specific values.
属性能够关联到测试计划-看一下函数-读一个属性-但是不能用于线程指定值
JMeter variables are local to each thread. The values may be the same for each thread, or they may be different.
JMeter的变量位于没一个线程中,对于每个线程变量的值可能相同,也可能不同。
If a variable is updated by a thread, only the thread copy of the variable is changed.
如果一个线程修改了变量,那么只有这个线程的变量的备份变化了。
For example the Regular Expression Extractor Post-Processor will set its variables according to the sample that its thread has read, and these can be used later by the same thread.
例如正则表达式后置处理器会依据线程使用从取样器读取到的来设置变量,然后在该线程中这边变量可以被使用。
Note that the values defined by the Test Plan and the User Defined Variables configuration element are made available to the whole test plan at startup.
注意在测试计划和用户定义变量配置元素中定义的值会在启动的时候应用到这个测试计划中。
If the same variable is defined by multiple UDV elements, then the last one takes effect.
如果多个用户定义变量元素定义了同一个变量,那么最后一个生效。
Once a thread has started, the initial set of variables is copied to each thread.
当一个线程启动,变量的初始值会被复制到每个线程。
Other elements such as the User Parameters Pre-Processor or Regular Expression Extractor Post-Processor may be used to redefine the same variables (or create new ones). These redefinitions only apply to the current thread.
其他元素例如用户参数前置元素或者正则表达式抽取后置处理器可以被用于重新定义相同的变量(或者创建一个新的)。这些重新定义只使用于当前线程。
The setProperty function can be used to define a JMeter property. These are global to the test plan, so can be used to pass information between threads - should that be needed.
设置属性函数用于定义JMeter属性。这先对于测试计划是全局配置,所以在需要的情况可以用于不同线程间传递信息。

使用变量去参数化测试

Variables don’t have to vary - they can be defined once, and if left alone, will not change value.
变量不是必须变化的,他们可以在定义后就不管,它也不会改变值。
So you can use them as short-hand for expressions that appear frequently in a test plan.
所以你可以用他们作为一个关键字来表达那些频繁的出现在一个测试计划中的值。
Or for items which are constant during a run, but which may vary between runs.
如果作为项目中在运行期间的常数,但是在不同的运行中会变化。
For example, the name of a host, or the number of threads in a thread group.
例如,主机的名字,线程组中的线程数。
When deciding how to structure a Test Plan, make a note of which items are constant for the run, but which may change between runs.
在我们决定怎样去构成一个测试计划的时候,要注意哪些是运行中的参数,那些在运行中会改变。
Decide on some variable names for these - perhaps use a naming convention such as prefixing them with C_ or K_ or using uppercase only to distinguish them from variables that need to change during the test.
如何决定这边变量的命名,业务我们可以使用到命名惯例,例如在前面使用C_或者K_或者大写来区分与其他变量,这些会在测试的时候改变。
Also consider which items need to be local to a thread - for example counters or values extracted with the Regular Expression Post-Processor.
也要考虑这些会被置于线程之中-例如计数器或者正则表达式后置处理器的抽取的变量。
You may wish to use a different naming convention for these.
你也许希望在这里使用到不同命名习惯。