Apache JMeter is open-source software that was developed by Stefano Mazzocchi. JMeter was developed and designed to load test functional behavior and measure performance. On the other hand, JMeter can also be used to analyze and measure the performance of web applications, functional tests, and database server tests too.

A Test Plan can be viewed as a container for running tests. It defines what to test and how to go about it. A complete test plan consists of one or more elements such as thread groups, logic controllers, sample-generating controllers, listeners, timers, Assertions, and configuration elements. A test plan must have at least one thread group.

Thread Group elements are the beginning points of your test plan. As the name suggests, the thread group elements control the number of threads JMeter will use during the test. We can also control the following via the Thread Group

• Setting the number of threads
• Setting the ramp-up time
• Setting the number of test iterations

Action to be taken after a Sampler error − In case any error occurs during test execution, you may let the test either

• Continue to the next element in the test
• Stop Thread to stop the current Thread.
• Stop Test completely, in case you want to inspect the error before it continues running.

Number of Threads − Simulates the number of users or connections to your server application.

Ramp-Up Period - Defines how long it will take JMeter to get all threads running.

Loop Count − Defines the number of times to execute the test.

Scheduler checkbox − Once selected, the Scheduler Configuration section appears at the bottom of the control panel.

Scheduler Configuration − You can configure the start and end time of running the test.

Following is the execution order of the test plan elements −

1. Configuration elements
2. Pre-Processors
3. Timers
4. Sampler
5. Post-Processors unlessSampleResultisnull
6. Assertions unlessSampleResultisnull

The different types of assertions in JMeter include:

• Response Assertions
• Duration Assertions
• Size Assertions
• XML Assertions
• Beanshell Assertions
• MD5Hex Assertions
• HTML Assertions
• XPath Assertions
• XMLSchema Assertions
• BSF and JSR223 Assertions
• Compare Assertions
• SMIME Assertions

The most commonly used assertion is the Response Assertion, which checks whether a response text/body/code/message/header contains, matches, or equals a specified pattern.

The Pattern can be either be:

a “string” for “Equals” or “Substring” clauses
a “Perl5-style” Regular Expression for “Contains” or “Matches” clauses
Response Entities that can be checked include the following.

Text Response: This is for the response that can be displayed in a browser

Document (Text): This is for anything supported by Apache Tika (it assumes the presence of apache-tika.jar in /lib folder of a JMeter installation). This can include PDF, Office, audio, and video formats. Be careful, because this can be memory-intensive for high loads.

URL Sampled: This assertion is used against a requested URL to ensure it matches expectations. For example, you may want to check that the redirect URL doesn’t contain an error somewhere in the path.

Response Code: This checks to ensure the response code is expected. For 4xx and 5xx response codes, make sure you have checked the “Ignore Status” box (see below for a full explanation).

Response Message: This verifies that the response message appears as expected.

Response Headers: This is used against Response Headers to see if a specific HTTP header is present or absent.

Ignore Status: JMeter out-of-the-box considers all 4xx and 5xx responses as failures. If your test case is negative and, for example, a 404 error is expected, you’ll check this box to suppress JMeter’s built-in status code check and substitute it with your own status code assertion.

The Duration Assertion is very simple. Used alongside the Response Assertion, it covers 90 percent of use cases where assertions are required. The usage is very straightforward: It provides the maximum duration in milliseconds, and, if any request lasts longer than the value specified, the sample is marked as failed. When you get a Duration Assertion failure, the output appears like this:

Size Assertions check the response length to see if it’s equal/not equal/greater/less than the expected size in bytes. It can be applied to:

Full response (body and headers) Response headers Response body Response code Response message The easiest way to check the response size is through the “View Results Tree Listener”

The HTML Assertion checks that the response HTML syntax is a well-formed HTML/XHTML/XML document. So it’s handy if your Web application or site requires zero HTML validation errors. Most modern browsers render even invalid HTML pages, but search engine robots or third-party integrations may not be so tolerant.

In the GUI mode, there are two ways that failed assertions can be inspected:

• Assertion Results Listener: This reveals the label under which all the assertions were taken.
• View Results Tree Listener: This reveals all the assertions in the test plan.

Jmeter threads usually run one after another without any time delay. This can be unrealistic in nature because a normal user will take time gaps to read or think between performing every action. That time is called Think Time and it should be added to make the script more realistic and reliable. To perform such operations JMeter is providing 9 types of timers and the user can select the one which suits the scenario.

• Constant Timer
• Gaussian Random Timer
• Uniform Random Timer
• Constant Throughput Timer
• Synchronizing Timer
• JSR223 Timer
• BeanShell Timer
• BSF Timer
• Poisson Random Timer
• Every timer has its own usability.

This can be used to add some delay/think time between each request. The constant timer has the following components. The name that we have given is displayed on the tree and here thread delay is taken in milliseconds. For example, if we want to add 3 seconds think time then we have to enter 3000 as shown above.

This is a scripting-based timer in which we can develop the logic of how to implement a timer. The Bean shell timer has the following components.

JSR223 Timer is also a scripting-based timer similar to Bean shell timer. In JSR223 Timer we can create delays between the user requests using the JSR223 Scripting language. JSR223 Timer components are as follows.

Uniform Random can be used to add a random amount of think time between the user requests. The Uniform Random Timer has the following components. Name element is meant to give a name to the timer that is to be displayed in the tree. Random Maximum Delay as the name suggests we should enter the maximum delay or think time then it will give a random think time to user requests which are not above the given value. For example, if we don’t want the time time to exceed 10sec then we should enter the value to this is 10000. Constant Delay Offset is an additional value taken in milliseconds. Similarly, other timers are used according to the situation or the requirement of testplan.

JMeter, the most popular open source performance testing tool, can work with regular expressions, with the Regular Expression Extractor. Regular expressions are a tool used to extract a required part of the text by using advanced manipulations. Regular expressions are popular when testing web applications because they can be used to validate and to perform operations on a response from a web application.

In JMeter, the Regular Expression Extractor is useful for extracting information from the response. For example, when you request a page and then need to get a link from the page that was downloaded. Another use case is saving the extracted information to a variable, so it can be used later on in the performance test, for example when testing an application that uses token authentication, like CSRF/XSRF.

When configuring the regular expressions in JMeter, use the same syntax as Perl5. But there is one very important difference between JMeter and Perl regexps processing. In Perl you have to use the “//” delimiter to specify regexp. So, the regular expressions reg might appear like this: ~/regular_expression/. But you cannot use “//” for the same purpose in JMeter, otherwise the regular expression will be parsed literally, and not logically. So, if you are using grouping in a regular expression, use the “()” parentheses to separate one group from another.

Now I will shortly describe all of this element's fields.

“Apply to” radio button

You can choose whether the regular expression will be applied to the main sample results, to the sub-samples/embedded resources, or both.

• Main sample only: Only applies to the main sample
• Sub-samples only: Only applies to the sub-samples
• Main sample and sub-samples: Applies to both main sample and sub-samples
• JMeter Variable: The expression is applied to the filled in variable “Field to check” radio button

• Body - The body of the response. The content of your web-page, excluding headers, will be parsed with the regular expression.
• Body (unescaped) - The body of the response, with all HTML escape codes replaced. Note that HTML escapes are processed without regard to context, so some incorrect substitutions may be made.
• Headers - The headers of the response or the request
• URL – The URL of the request
• Response Code - e.g. 200
• Response Message - e.g. OK
• Name of Created Variable - The name of the variable where the parsing results will be saved in JMeter.