About

Documentation

Community

4.0 Elements of a Test Plan
4.1 ThreadGroup

Thread group elements are the beginning points of any test plan. All elements of a test plan must be under a thread group. As the name implies, the thread group element controls the number of threads JMeter will use to execute your test. The controls for a thread group allow you to:

  • Set the number of threads
  • Set the ramp-up period
  • Set the number of times to execute the test

Each thread will execute the test plan in its entirety and completely independent 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. 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.

By default, a thread group is configured to loop indefinitely through its elements. Alternatively, you can set the number of times the thread group will loop before ending. If the number is set at one, then JMeter will execute the test only once before stopping.


4.2 Controllers

JMeter has two types of Controllers: Generative and Logical.

Generative Controllers tell JMeter to send requests to a server. For example, add an HTTP Request Generative Controller if you want JMeter to send an HTTP request. You can also customize a request by adding one or more Configuration Elements to a Generative Controller. For more information, see Generative Controllers .

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 Generative Controllers. Also, one particular Logic Controller, the Modification Manager, lets you modify the results of a request. For more information, see Logical Controllers .


4.2.1 Generative Controllers

Generative Controllers tell JMeter to send requests to a server. JMeter currently has three such controllers: FTP Request, HTTP Request, and JDBC request. Each controller has several properties you can set. You can further customize a controller by adding one or more Configuration Elements to it. Also, note that JMeter sends requests in the order that you add them to the tree.

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 its own Defaults element (see below).

Remember to add a Listener to your Thread Group 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 Request controller. 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. 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.

JMeter's built-in generative controllers


4.2.2 Logic Controllers

Logic Controllers let you customize the logic that JMeter uses to decide when to send requests. Logic Controllers may have as child elements any of the following: Generative Controllers (requests), Configuration Elements, and other Logic Controllers. 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.

To understand the effect of Logic Controllers on a test plan, consider the following test tree:

  • Test Plan
    • Thread Group
      • Once Only Controller
      • Load Search Page (HTTP Generative Controller)
      • Interleave Controller
        • Search "A" (HTTP Generative Controller)
        • Search "B" (HTTP Generative Controller)
        • 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 .

After the login, the next Generative Controller 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 (ie - 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.

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 Generative Controllers 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.

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 Generative Controller 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 Generative Controller.

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.

Logic Controllers can be combined to achieve various results. See the list of built-in Logic Controllers .


4.3 Listeners

Listeners provide access to the information JMeter gathers about the test cases while JMeter runs. The simplest listener, the Graph Results listener plots the response times on a graph. Listeners usually provide a graphical view of the data that JMeter generates.

An exception to this is the File Reporter , which, as you might expect, logs the result data to a file.

Listeners can only be added to a Thread Group, and they only collect information specific to that Thread Group. If you have 3 Thread Groups and a listener attached to each one, those three listeners will show three different sets of data.

There are several interesting listeners that come with JMeter.


4.4 Timers

By default, a JMeter thread sends requests without pausing between each request. We recommend that you specify a delay by adding one of the three 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.

The timer will cause JMeter to delay a certain amount of time between each request that a thread makes. Remember, threads are independent of one another, and this applies to the timer delay as well.

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.


4.5 Assertions

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.

You can add an assertion to any Generative Controller. For example, you can add an assertion to a HTTP Request that checks for the text, "". 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.

To view the assertion results, add an Assertion Listener to the Thread Group.


4.6 Configuration Elements

A configuration element works closely with a Generative Controller. Although it does not send requests (except for HTTP Proxy Server ), it can add to or modify requests.

A configuration element is accessible from only inside the tree branch where you place the element. For example, if you place an HTTP Cookie Manager inside a Simple Logic Controller, the Cookie Manager will only be accessible to HTTP Request Controllers you place inside the Simple Logic Controller (see figure 1). The Cookie Manager is accessible to the HTTP requests "Web Page 1" and "Web Page 2", but not "Web Page 3".

Also, a configuration element inside a tree branch has higher precedence than the same element in a "parent" branch. For example, we defined two HTTP Request Defaults elements, "Web Defaults 1" and "Web Defaults 2". Since we placed "Web Defaults 1" inside a Loop Controller, only "Web Page 2" can access it. The other HTTP requests will use "Web Defaults 2", since we placed it in the Thread Group (the "parent" of all other branches).


Figure 1 - Test Plan Showing Accessability of Configuration Elements




Copyright © 1999-2001, Apache Software Foundation