Chapter 3: Introduction to Elements of Jmeter Test Plan

Test Plan

A Test Plan defines and provides a layout of how and what to test: the web application as well as the client server application.

A test plan includes elements such as:

• Thread groups
• Logic controllers
• Sample-generating controllers
• Listeners
• Timers
• Assertions
• Configuration elements
• A test plan must have at least one thread group.

Figure 3.1: Test Plan

Here you can define static variables that allow you to extract repeated values throughout your tests, such as server names, port number, etc.

For example, if you are testing an application on server www.example-jmeter.net, then you can define a variable called "server" with the value of www.example-jmeter.net. This value will replace variable "${server}" found anywhere in the test plan.

Thread Group

A Thread Group is the starting point of a Test Plan, and it should contain all other JMeter elements.A thread group controls the threads that will be created by JMeter to simulate simultaneous users.

Figure 3.2: Thread Group

Number of Threads
It simulates the number of user(s) or connection(s) to your server application.

Ramp-Up Period
It defines how long it will take JMeter to get all threads running.
For example, if there are 10 threads and a ramp-up period of 60 seconds, then each successive thread will be delayed by 6 seconds.

Loop Count
It defines the number of times to execute the test. By default, the test is executed once but you can adjust as needed. Clicking the Forever checkbox causes the test to run repeatedly until stopped manually.

Scheduler checkbox
Once selected, the Scheduler Configuration section will appear at the bottom of the control panel.

Scheduler Configuration
Here you can set the start and end time of running the test. Once you start the test, it will not execute any elements until the start time is reached. After each execution cycle, unless the end-time is reached, in which case the run is stopped, the iteration will continue until the loop count limit. The startup delay field allows JMeter sometime before a thread is started and the duration field lets you define the duration of the whole test. The former overrides start-time, while the latter overrides end-time.

Controllers

JMeter has two types of Controllers

1. Samplers
2. Logic Controllers

Samplers

These allow JMeter to send specific types of requests to a server.

Figure 3.3: Samplers

Access Log Sampler: Designed to read access logs and generate HTTP requests.

Bean shell Sampler: Allows the user to write a Sampler using the Bean Shell scripting language.

BSF Sampler: Allows you to write a sampler using a BSF scripting language. See the Apache Bean Scripting Framework website for details of the languages supported.

FTP Request: Lets you send an FTP "retrieve file" or "upload file" request to an FTP server. When downloading a file, it can be stored on disk (Local File) or in the Response Data, or Both.

HTTP Request: Lets you send an HTTP/HTTPS request to a web server. It also lets you control whether or not JMeter parses HTML files for images and other embedded resources and sends HTTP/HTTPS requests to retrieve them.

JDBC Request: Lets you send an SQL query to a database.

Java Request: Lets you control a Java class that implements the JavaSamplerClient interface.

JMS Point-to-Point: This sampler sends and optionally receives JMS Messages through point-to-point connections (queues). This is different from pub/sub messages and is generally used for handling transactions.

JMS Publisher: Publishes messages to a given pub/sub topic. For those not familiar with JMS, it is the J2EE specification for messaging.

JMS Subscriber: Subscribes to messages in a given pub/sub topic. For those not familiar with JMS, it is the J2EE specification for messaging.

JSR223 Sampler: The JSR223 Sampler allows JSR223 script code to be used to perform a sample.

Junit Request: The current implementation supports standard JUnit convention and extensions. It also includes extensions like onetime Setup and onetime Tear down.

LDAP Extended Request: Can send all 8 different LDAP requests to an LDAP server. It is an extended version of the LDAP sampler, therefore it is harder to configure, but can be used to make a test much more closely resembling a real LDAP session.

LDAP Request: Lets you send one of four LDAP requests (Add, Modify, Delete, and Search) to an LDAP server.

Mail Reader Sampler: The Mail Reader Sampler can read (and optionally delete) mail messages using POP3(S) or IMAP(S) protocols.

OS Process Sampler: The OS Process Sampler is a sampler that can be used to execute commands on the local machine.

SOAP/XML-RPC Request: Lets you send a SOAP request to a Web Service. It can also be used to send XML-RP Cover HTTP.

TCP Sampler: Opens a TCP/IP connection to the specified server. It then sends the text, and waits for a response.

Test Action: This sampler is intended for use in a conditional controller. Rather than generate a sample, the test element either pauses or stops the selected target.

Web Service(SOAP) Request: Uses Apache SOAP driver to serialize the message and set the header with the correct SOAP action.

Logic Controllers

These allow you to customize the logic that JMeter uses to decide when to send requests.

Figure 3.4: Logic Controllers

ForEach Controller: When you add samplers (or controllers) to a ForEach Controller, every sample Sampler(or controller) is executed one or more times, where during every loop the variable has a new value.

IF Controller: Allows the user to control whether the test elements below it (its children) are run or not.    

Include Controller: Designed to use an external .jmx file.

Interleave Controller: Lets JMeter to alternate among the controllers for each loop iteration.

Loop Controller: Lets JMeter to loop through its child controllers a certain number of times, in addition to the loop value you specified for the Thread Group.

Module Controller: Provides a mechanism for substituting Test Plan fragments into the current Test Plan at run time.

Once Only Controller: It tells JMeter to process the controller(s) inside it only once, and pass over any requests under it during further iterations through the Test Plan.

Random Controller: Acts similarly to the Interleave Controller, except that instead of going in order through its sub-controllers and samplers, it picks one randomly at each pass.

Random Order Controller: Much like a Simple Controller, it will execute each child element at most once, but the order of execution of the nodes will be random.

Recording Controller: Simply a place-holder indicating where the proxy server should record samples to. It has no effect during a test run. But during recording using the HTTP Proxy Server, all recorded samples will by default be saved under the Record Controller.

Runtime Controller: Controls the time for which its children are allowed to run.

Simple Controller: Lets you organize your Samplers and other Logic Controllers. This controller provides no functionality beyond that of a storage device.

Switch Controller: Acts like the Interleave Controller in that it runs one of the subordinate elements on each iteration but rather than run them in sequence, the controller runs the element number defined by the switch value. If the switch value is out of range, it will run the zeroth element, which therefore acts as default.

Throughput Controller: Allows the user to control how often it is executed.

Transaction Controller: Used to group Samplers by generating an additional sample, which totals the nested samplers.

While Controller: Runs its children until the condition is "false”.

Listeners

Listeners let you view the results of the Samplers in the form of tables, graphs, trees or simple text in some log files.Listeners provide means to view, save, and read saved test results.All Listeners that save data into the same file shows the same data differently.

Figure 3.5: Listeners

Aggregate Graph: Similar to the Aggregate Report, the difference is the aggregate graph provides an easy way to generate bar graphs and save the graph as a PNG file.

Aggregate Report: The aggregate report creates a table row for each differently named request in your test. For each request, it totals the response information and provides request count, Min, Max,Average, Error %, Throughput (request/second), and KB/second throughput.

Assertion Results: This visualizer shows the Label of each sample taken. It also reports failures of any Assertions that are part of the Test Plan.

Bean shell Listener: The Bean Shell Listener allows the use of Bean Shell for processing samples for saving, etc. The Bean Shell jar file is not included with JMeter; it needs to be separately downloaded.

BSF Listener: The BSF Listener allows BSF script code to be applied to sample results.

Comparison Assertion Visualizer: The Comparison Assertion Visualizer shows the results of any Compare Assertion elements.

Distribution Graph (alpha): This will display a bar for every unique response time.

Generate Summary Results: This test element can be placed anywhere in the test plan. Both running and differential totals are shown. Output is generated every n seconds (default 3 minutes) on the appropriate time boundary, so that multiple test runs on the same time will be synchronized.

Graph Results: Generates a simple graph that plots all sample times. Along the bottom of the graph, the current sample (black), the current average of all samples (blue), the current standard deviation (red),and the current throughput rate (green) are displayed in milliseconds.

JSR223 Listener: The JSR223 Listener allows JSR223 script code to be applied to sample results.

Mailer Visualizer: The mailer visualizer can be set up to send email if a test run receives too many failed responses from the server.

Monitor Results: Visualizer for displaying server status. It is designed for Tomcat 5, but any servlet container can port the status servlet and use this monitor.

Save Response to a File: For each sample in its scope, it will create a file of the response Data.

Simple Data Writer: This listener can record results to a file but not to the UI. It is meant to provide an efficient means of recording data by eliminating GUI overhead.

Spline Visualizer: Provides a view of all sample times from the start of the test till the end, regardless of how many samples have been taken.

Summary Report: This report creates a table row for each differently named request in your test. This is similar to the Aggregate Report, except that it uses less memory.

View Results in Table: This visualizer creates a row for every sample result. Like the View Results Tree, it uses a lot of memory.

View Results Tree: This shows a tree of all sample responses, allowing you to view the response for any sample.

Timers

It causes JMeter to pause for a certain amount of time between two successive requests that a Thread Group makes.

Figure 3.6: Timers

Bean shell Timer: The Bean Shell Timer can be used to generate a delay.

BSF Timer: The BSF Timer can be used to generate a delay using a BSF scripting language.

Constant Throughput Timer:  Allows for variable pauses, calculated to keep the total throughput(in terms of samples per minute) as close as possible to a give figure.

Constant Timer: Allows each thread to pause for the same amount of time between requests.

Gaussian Random Timer: Pauses each thread request for a random amount of time, with most of time intervals occurring near a particular value.

JSR223 Timer: This Timer can be used to generate a delay using a JSR223 scripting language.

Poisson Random Timer: This timer pauses each thread request for a random amount of time, with most of the time intervals occurring near a particular value. The total delay is the sum of the Poisson distributed value, and the offset value.

Synchronizing Timer: Blocks threads until X number of threads have been blocked, and then releases them all at once. It can thus create large instant loads at various points of the Test Plan.

Uniform Random Timer: Pauses each thread request for a random amount of time, with
each time interval having the same probability of occurring. The total delay is the sum of the random value and the offset value.

Assertions

Assertions allow you to include some validation test on the response of your request made using a Sampler. They are inserted as a child component of a Sampler.

Figure 3.7: Assertions

Bean shell Assertion: Allows the user to perform assertion checking using a
Bean Shell script.

BSF Assertion: The BSF Assertion allows BSF script code to be used to check the status of the previous sample.

Compare Assertion: The Compare Assertion can be used to compare sample results within its scope. Either the contents or the elapsed time can be compared, and the contents can be filtered before comparison.

Duration Assertion: This tests that each response was received within a given amount of time. Any response that takes longer than the given number is marked as a failed response.

HTML Assertion: Allows the user to check the HTML syntax of the response data using JTidy.

JSR223 Assertion: The JSR223 Assertion allows JSR223 script code to be used to check the status of the previous sample.

MD5Hex Assertion: Allows the user to check the MD5 hash of the response data.

Response Assertion: Lets you add pattern strings to be compared against various fields of the response. The pattern strings are Perl5-style Regular Expressions.

Size Assertion: This tests that each response contains the right number of bytes init. You can specify that the size be equal to, greater than, less than, or not equal to a given number of bytes.

SMIME Assertion: The SMIME Assertion can be used to evaluate the sample results from the Mail Reader Sampler. This assertion verifies if the body of a mime message is signed or not.

XML Assertion: This tests that the response data consists of a formally correct XML document. It does not validate the XML based on a DTD or schema or do any further validation.

XML Schema Assertion: The XML Schema Assertion allows the user to validate a response against an XML Schema.

XPath Assertion: The XPath Assertion tests a document for well-formedness and has the option of validating against a DTD, or putting the document through JTidy and testing for an XPath.

Configuration Elements

Configuration Elements allow you to create defaults and variables to be used by Samplers. They are used to add or modify requests made by Samplers.

Figure 3.8: Configuration Elements

Counter: Allows the user to create a counter that can be referenced any where in the Thread Group.

CSV Data Set Config: Used to read lines from a file, and split them into variables. Easier to use than the __CSVRead() and _StringFromFile() functions, the file is only opened once, and each thread will use a different line from the file. Lines are read as the threads need them.

FTP Request Defaults: This element lets you set default values that your FTP Request controllers use.

HTTP Authorization Manager: Lets you specify one or more user logins for web pages that are restricted using server authentication.

HTTP Cache Manager: The HTTP Cache Manager is used to add caching functionality to HTTP requests within its scope.

HTTP Header Manager: Lets you add or override HTTP request headers.

HTTP Request Defaults: Lets you set default values that your HTTP Request controllers use.

Java Request Defaults: Lets you set default values for Java testing. See the Java Request.

JDBC Connection Configuration: Creates a database connection pool (used by JDBC RequestSampler) with JDBC Connection settings.

key store Configuration: The key store Config Element lets you configure how Key store will be loaded and which keys it will use. This component is typically used in HTTPS scenarios where you don't want to take into account key store initialization into account in response time.

LDAP Extended Request Defaults: Lets you set default values for extended LDAP testing.

LDAP Request Defaults: Lets you set default values for LDAP testing. See the LDAP Request.

Login Config Element: Lets you add or override username and password settings in Samplers that use username and password as part of their setup.

Random Variable: The Random Variable Config Element is used to generate random numeric strings and store them in variable for use later.

Simple Config Element: Lets you add or override arbitrary values in Samplers. You can choose the name of the value and the value itself.

TCP Sampler Config: Provides default data for the TCP Sampler.

User Defined Variables: Lets you define variables for use in other Test elements, just as in the Test Plan. The variables in User Defined Variables components will take precedence over those defined closer to the tree root—including those defined in the Test Plan.

Pre-Processor Elements

Pre-processors allow you to modify the Samplers in their scope. They are often used to modify the settings of a Sample Request just before it runs, or to update variables that are not extracted from response text.

Figure 3.9: Pre-Processor

Bean Shell Pre-Processor: Allows arbitrary code to be applied before taking a sample.

BSF Pre-Processor: The BSF Preprocessor allows BSF script code to be applied before taking a sample.

HTML Link Parser: Parses HTML response from the server and extracts links and forms.

HTTP URL Rewriting Modifier: This modifier works similarly to the HTML Link Parser, but is especially useful for web applications that use URL Re-writing to store session IDs instead of cookies.

JDBC Pre-Processor: The JDBC Preprocessor enables you to run some SQL statement just before a sample runs.

JSR223 Pre-Processor: The JSR223 Preprocessor allows JSR223 script code to be applied before taking a sample.

User Parameters: Allows the user to specify values for User Variables specific to individual threads, which can be accessed in any test component in the same thread group, using the function syntax: ${variable}.

Post-Processor Elements

Post-processors execute after a request has been made from a Sampler. A good way is to place them as a child of a Sampler, to ensure that it runs only after a particular Sampler, not to Sampler afterwards.

Figure 3.10: Post-Processor

Bean shell Post-Processor: Allows arbitrary code to be applied after taking a sample.

BSF Post-Processor: The BSF Postprocessor allows BSF script code to be applied after taking a sample.

JDBC Post-Processor: The JDBC Postprocessor enables you to run some SQL statement just after a sample has run.

JSR223 Post-Processor: The JSR223 Postprocessor allows JSR223 script code to be applied after taking a sample.

Regular Expression Extractor: Allows the user to extract values from a server response using a Perl-type regular expression.

Result status action Handler: Allows the user to stop the thread or the whole test if the relevant sampler failed.

XPath Extractor: This test element allows the user to extract value(s) from structured response - XML or (X)HTML - using XPath query language.