JMeter Tutorial

What is JMeter?

Apache JMeter is a Java-based desktop application, which can be used for load testing to measure the performance of a system or used for stress testing to see if a system is crashed gracefully. It can generate reports to help eliminate bottlenecks of the system or to see how it performs under heavy loads. Other than load testing, you also can use JMeter in functional testing.

JMeter provides a variety of test elements. They are quite handy and can save you time in writing your own Java programs for testing. Using JMeter is quite intuitive because it provides a nice GUI to create and run tests. You also can run JMeter tests in non-GUI mode. Tests can be run either locally or remotely. JMeter is designed using a plugin approach to provide flexibility in adding new features (test elements) as custom plugins.

Want to become an expert in JMeter? Then visit JMeter Training

JMeter Performance Testing

Performance testing is defined as a testing environment in which newly developed applications are tested on whether they are working according to the predefined plan or meeting the desired requirements. The proper functionality of a newly developed application is more essential for running it in the live environment. Performance testing saves time and cost by identifying the loopholes in an application or software. 

So to fix the bugs in advance we use performance testing. It evaluates the various elements of a newly developed application such as response time, resource usage, reliability, security, and scalability. The main goal of performance testing is to eliminate the bottlenecks of an application. 

Performance testing often called “Pref testing” which is a subset of performance engineering. It provides complete information to the stakeholders on various parameters of their core application that includes speed, stability, and scalability. 

Building A JMeter Test Plan

To use JMeter for testing, you can either load an existing test plan or create a new one. Basically, a test plan has a tree structure, which contains test elements describing how a test will run.

Starting JMeter

First, we need to start JMeter (JSE 6.0 or above is required). You can start JMeter from the command line by running jmeter.bat (for Windows) or JMeter.sh (for Unix/Linux) in
the bin directory.

To run JMeter in non-GUI mode, you can use the following command-line options:

-n non-GUI mode
-t the test plan file (with extension name jmx)
-l the result log file (with extension name jtl)
-j the log file

You can download JMeter from Jmeter's official website. The latest version is 2.9 at the time of writing.

Adding test elements

There are two panels on the screen of the JMeter GUI. The left panel is the test tree for a test plan and the right panel is the configuration panel for the selected element. A new test plan starts with two elements: Test Plan and WorkBench. The Test Plan is the root of a test tree. A WorkBench is a temporary place for storing test elements, not in use or non-test elements. The WorkBench is not saved with the test plan automatically. You can save it separately.

To add a new element to the test tree, you can either right-click on an element and choose Add from the popup menu or choose Edit -> Add from the menu bar on top:

 

Also, you can remove or disable/enable elements from the same menu. In this example, we choose to add a Thread Group to the test plan. A test plan contains at least one Thread Group. A test case is defined in a Thread Group. The Thread Group allows you to define the number of threads running for a test case, the number of times it is going to run, and optionally the start and stop times through a scheduler.

Next, we add a Java Request sampler under this Thread Group by choosing Add -> Sampler -> Java Request. The Java Request sampler allows you to put your own Java classes (or custom samplers) as long as they implement the JavaSamplerClient interface or extend the AbstractJavaSamplerClient class. There are two Java sample classes available in the JMeter. We are using the JavaTest class for demonstration purposes. The JavaTest does not access the network and is useful for testing the performance of the local machine.

Checkout JMeter Interview Questions

To show testing results, we add a Graph Results listener. The Graph Results listener plots testing results for all samples. It is good for showing the progress of testing visually. But, it does consume more resources. Usually, this is used in testing or debugging a test plan with a small load.

JMeter Test

The following is our first JMeter test plan:

 

Note: When you specify the number of thread groups/threads running in a test plan, you need to be careful about the capability of the machine running JMeter. The more load you put on the machine, the less accurate timing information you might get. Using non-GUI mode with results written to files can help. You even can consider running your test in multiple machines (remote testing) for a test with a heavy load

Running a test plan

Once you are done defining a test plan, you can run it. To run a test plan, you can do that through the Run menu or the toolbar. When a test plan is running, you can check the current status from the upper-right corner:

                                                                      

The green square icon indicates a test plan is running. The yellow triangle icon with a number is the error/fatal counter. By default, the JMeter log file jmeter.log is located under the bin directory (or using -j option to specify it). To see the logging screen from the GUI, you can toggle it on and off by clicking on the yellow triangle icon or choosing the Options menu -> Log Viewer. 5/5 indicates that the total number of threads is five and five threads are running.

To clear results in the whole test plan, you can choose Clear All from the Run menu. Or, you can choose Clear to clear results in a selected element.

You can stop or shut down a running test through the Run menu or the toolbar. The difference between stop and shutdown is that threads stop immediately for stop and threads stop gracefully at the end of current work for the shutdown. For the non-GUI mode, you can use shutdown.cmd (or shutdown.sh) or stop test.cmd (or stop test.sh).

Saving a test plan

To save a test plan, you can do that through the File menu or the toolbar. A test plan is saved with the extension name JMX. You can save a partial test plan by using Save Selection As from the File menu or the popup menu.

[Also Read: JMeter vs LoadRunner]

Debugging a test plan

Enabling debug logging can be helpful in creating a test plan. Most test elements support debug logging. To enable debug logging on a test element, select a test element and choose the Help menu -> Enable debug. You can disable it by choosing Disable to debug. To view debug logging, open jmeter.log under the bin directory or enable Log Viewer before you run it.

Remote testing

You can use JMeter to do remote (or distributed) testing. Using remote testing can save you trouble in copying the test plan to each machine and also allow you to simulate a larger load with more users. In remote testing, one JMeter client is used as the master to control other JMeter instances (serving as slaves) running as remote servers. Data will be collected by the client. You can start a JMeter server by running JMeter-server.bat (for Windows) or JMeter-server (for Unix/Linux).

All JMeter instances should use the same version of JMeter. In the JMeter client, you add remote servers into the property remote_hosts in the jmeter.properties. Then, you can start the JMeter client and load the test plan. To start remote servers, select the Run menu -> Remote Start or Remote Start All. If you are using a non-GUI client, you can run:

Test Plan Elements

A JMeter test plan is constructed by test elements as a tree structure (there are few nontest elements you can add in the WorkBench). JMeter provides a rich set of test elements. Those are what make JMeter such a powerful tool. Most of the test elements are processed in the order they appear in the test tree. Basically, you use samplers to test against a server and use logic controllers to control the flow of a test run and use listeners to gather or view testing results from the server.

Types of Jmeter Test Plan Elements

Samplers

There are two types of controllers. Samplers are one of them. Samplers generate requests (or samples) and perform actual testing jobs in JMeter. Mostly, samplers are used to send requests to a server and wait for responses.

JMeter has samplers that support the following protocols: HTTP (the HTTP Request sampler), FTP (the FTP Request sampler), TCP (the TCP sampler), SMTP (the SMTP sampler), POP3 (the Mail Reader sampler), and IMAP (the Mail Reader sampler). You even can execute commands on the local machine (the OS Process sampler) or send an SQL query to a database (the JDBC Request sampler). To use your own Java classes, you can use the Java Request sampler or JUnit Request sampler (for JUnit test classes). To use a scripting language, you can use the JSR223 sampler (scripting for the Java platform) or BSF sampler (Apache Bean Scripting Framework).

There is a special sampler called Test Action Sampler. It does not send any requests to the server. Instead, it can pause or stop a target thread or all threads. The Test Action sampler is used with a conditional controller.

[Related Article: JMeter Correlation]

Logic Controllers

Logic controllers are controllers too. Logical controllers can break up the flow of execution and allow you to control the order that samples are processed.

For looping, you can use the Loop Controller, While Controller or ForEach Controller. For decision-making, you can use If Controller. For executing a group of elements, you can use the Simple Controller or Random Order Controller. The difference is that the Simple Controller executes elements inside it in order and the Random Order Controller executes them in random order. To execute one of the elements per iteration, you can use the Interleave Controller (alternating among elements for each iteration) or Random Controller (picking one in random for each iteration). You also can use the Once Only Controller to tell JMeter to process elements inside it only once per thread.

To structure your tests better, you can break them into fragments (or modules). To include a Test Fragment (created through the Test Fragment element), you can use the Include Controller to include it through an external JMX file. Or, you can use the Module Controller to include test fragments located in any Thread Group or in the WorkBench. You can include any fragment under a logic controller even it is disabled.

Both samplers and logic controllers are processed in the order they are defined in the test tree.

Listeners

Listeners gather information from tests. They provide means to allow you to view results from GUI mode and optionally to save results to a file in XML or CSV format. You can configure items to be saved in a file by clicking on the Configure button in the listener.

To view detailed results, you can use the Graph Results, View Results in Table or View Results Tree listener. To view aggregate data, you can use the Aggregate Report, Aggregate Graph, or Summary Report. If you only simply want to save results to a file without viewing it from GUI, you can use the Simple Data Writer. Similarly, if you want to save responses to a file, you can use the Save Responses as a file listener.

Listeners can be added anywhere in the test tree. But, they only gather data from elements inside the same tree branch (at or below the same level). To avoid confusion, a good practice is to put listeners at the end of the tree branch they are used for gathering data.

Configuration Elements

Configuration elements are used to set up configurations used by samplers. Configuration elements are only accessible by elements inside the same tree branch (including descendant branches). They are processed at the start of the tree branch in which they are defined no matter where they are located. One exception is the User Defined Variables. It is processed at the start of a test run no matter where it is located.

For the HTTP Request sampler, you can use the HTTP Authorization Manager, HTTP Cache Manager, HTTP Cookie Manager, HTTP Request Defaults, or HTTP Header Manager to work with it. For the JDBC Request sampler, you can use the JDBC Connection Configuration. If you need to use a counter, you can use the Counter configuration element.

To define user-defined variables, you can use the User Defined Variables (or define them in the Test Plan). User-defined variables can be referenced as ${variable_name}. Variables are local to each thread. To share values between threads or thread groups, you can use JMeter properties since they are global. Properties are defined in the JMeter. properties. Or, you can use additional files to define properties: user. properties and system. properties. Properties can be referenced as ${__P(property_name)} or ${__P(property_name,default_value)}. Both variables and properties are case-sensitive. You can debug variables and properties by using the Debug Sampler. You can see the values from the Response data tab in the View Results Tree.

Looking for Best Jmeter Online Training Platform in Hyderabad? To Enroll a Free Demo Click Here.

Assertions

Assertions work with samplers to check the responses from the server. The scope of an assertion is only at the current branch in which it is defined. It cannot be accessed by descendant branches unless it is specified. Assertions are processed after every sampler in the same scope. If you want an assertion only applies to a sampler, you can make it as a child of the sampler.

You can use the Response Assertion to check responses. The pattern matching is Perl5 style regular expressions. To assert that each response was received within a certain amount of time, you can use the Duration Assertion. To assert the size of each response, you can use the Size Assertion. To view assertion results, you can use the Assertion Results listener.

Timers

Timers work with samplers to cause a delay between each request. Timers are processed before every sampler in the same scope.

The Constant Timer is used to pause the same amount of time between each request. If you need a random amount of time, you can use the Gaussian Random Timer, Uniform Random Timer or Poisson Random Timer.

Pre-processors

Pre-processors are executed before samplers at the same level. You can add a preprocessor as the child of a sampler to make it pre-process information before feeding it into the sampler. Usually, they are used to modify settings before samplers run. Preprocessors are executed right before timers and after configuration elements.

To process HTML responses, you can use the HTML Link Parser or HTML URL Rewriting Modifier.

Post-processors

Post-processors are executed right after samplers at the same level. Usually, they are used to process responses. Post-processors are executed before assertions and listeners.

To extract values from a response and assign the result to a variable for later use, you can use the Regular Expression Extractor.

Testing A Web Application

Now, we will learn how to create a JMeter test plan to test a web application. To make HTTP (or HTTPS) requests, you can use the HTTP Request sampler. The HTTP Request sampler is not a browser. But, it can do most of the jobs a browser can do except something like rendering pages or running scripts. Optionally, it even allows you to retrieve embedded resources from web pages. For common settings (e.g., server name or IP) shared among the HTTP Request samplers, you can define them in the HTTP Request Defaults.

Other samplers will inherit values defined in the HTTP Request Defaults. For example, you can use the “Server Name or IP” field in the HTTP Request Defaults to specify the server to be tested. Then, you can leave that field blank in other HTTP Request samplers. The scope of the HTTP Request Defaults is within the current branch (and its descendants). Normally, a web application needs cookie support. We can use the HTTP Cookie Manager just in case cookie support might be needed by the application.

In the following example, four pages will be visited by each thread in random order. We use the Random Order Controller to simulate this behavior. The JMeter test plan is shown below:

 

After finished running this test plan, you can check the results from two listeners defined in it. The following screenshot is from the View Results Tree:

 

The results tree contains a list of pages being visited. For a failed request, the color is red if there is any. You can select a page to view the request and the response. If the response data is in HTML, you can view the rendered page by choosing HTML from the drop-down menu at the bottom of the tree. The rendered page only gives you some idea about a page. It is not going to be good compared with a browser. JMeter also can handle different types of documents (e.g., PDF, MS Office).

You can view the text in the document by choosing Document. Since the View Results in Tree records requests and responses from all visited pages, it is good for checking the behavior of a web application or debugging a web application. Also, you can use it to test your JMeter test plan. But, it is not a good idea to use it during load testing since it is going to consume lots of resources.

Another listener in this test plan is the Summary Report. The Summary Report gives you a table view of the results. It gives you a summary report arranged by pages (as table rows). Average, Min, and Max are elapsed times in milliseconds.

In the previous example, there are four pages that will be visited (in random order) during the test. Now, we want to include more pages in the test. Adding pages manually is kind of painful. We can use the HTML Link Parser to do that for us. The HTML Link Parser is a pre-processor that can extract links from the previous HTML response. Being followed by an HTTP Request sampler and included in a loop can make the whole thing behave like a web crawler. We will add this process to the previous example.

Each thread will randomly select one of the four pages in the previous example as the starting page and crawl through the website. In the HTML Request sampler, the Path field uses the regular expression (?i).*.html to match any HTML page. (?i) indicates that it is case-insensitive. For detailed information about using regular expressions in JMeter.

To continue crawling through the website, we add the HTTP Request sampler inside the While Controller and set the Condition field as true. To limit how long the While Controller can run, the While Controller is added as a child of the Runtime Controller. You can define the desired runtime in the Runtime field.

The following is the revised version

 

Testing With Authentication

Some web applications require user authentication to access certain pages. Form-based authentication is a popular method to secure resources for web applications. To do testing on websites that require user authentication, you need to add additional steps to sign in to the website automatically in the test plan before it can do anything.

First, you need to visit a page to get cookies from the website. Usually, it is a session ID for session tracking. The next step is to go through security checking by providing a username and password. To find the link for form action and query parameters required to submit to the server for authentication, you can use the “View source” function at the login page from a browser. The following is a sample HTTP Request sampler for authentication:

 

It is using the HTTP POST method. The form action is j_security_check. The path is /aediserver/j_security_check. The context root for the web application aediserver is included. The form field for username is j_username and the form field for the password is j_password. Both username and password are defined in the User Defined Variables.

Similarly, you can find form action to sign out the website from “View source”. This depends on how it is implemented.

The following is a simple example showing how to add authentication in a test plan. It includes the following steps: visiting the login page to initialize the connection to the server, sign in and then sign out.

 

In this example, we only store one set of user account information for authentication. If you want to simulate the scenario that different users sign in at the same time, you can use the User Parameters pre-processor to store multiple user accounts. For example, to have one user account per thread for four threads in a test, you can define four sets of parameters for username and password:

 

If the number of threads is more than the number of sets, they will be reused.

Checkout JMeter Performance Testing

Using Regular Expressions

What if you need to stop testing in case of connection problems such as connection refused by the server? In such a case, there is no reason to continue testing. The following is a fragment that replaces Login Page node in the previous example:

 

We add the Regular Expression Extractor post-processor to parse the response from the server while connecting to the login page. If there is any connection problem, an exception will be thrown in the response code. You can check the Sample result tab in the View Results Tree to see what will return when it failed. Inside the Regular Expression Extractor, field values are set as follows:

Reference Name: Exception

Regular Expression: .([a-zA-Z0-9]*Exception)
Template: $1$
Match No.: 1
Default Value: NO_EXCEPTION

We use a regular expression to search for any text related to an exception (e.g., HttpHostConnectException) in the response. Parentheses ( and ) indicate a group in the regular expression. It is used to get a portion of the matched string. In this case, it is used to remove a dot before the exception class name. $1$ in the Template field indicates group 1 and 1 in the Match No. field indicates the first match. If there is no match, the default value “NO_EXCEPTION” is returned. The value is assigned to a variable named Exception.

In the If Controller, the Condition field is set as

“${Exception}” != “NO_EXCEPTION”

The variable needs to be double-quoted. In the Test Action, the action is “Stop Now”.

One tricky part about using regular expressions against responses is how to verify the results. One easy way to validate regular expressions is through the View Results Tree. You can find a Search field at the bottom of the Response data tab. Type in a regular expression and make Regular exp. checkbox checked. Click on the Find button. You can see that matched string is highlighted if there is any. Click on the Find next button for the next matched string.

Click on the Find button. You can see that matched string is highlighted if there is any. Click on the Find next button for the next matched string

Using HTTP Proxy Server

In the case that there are too many form fields. To put them in manually is time-consuming. Or, you are not able to see form field names from the view source in a browser. You can use the Recording Controller to record test samples. You are doing a recording through the HTTP Proxy Server. All recorded samples will be saved under the Recording Controller. You can use them in a test plan. The following are basic steps to do recording using the HTTP Proxy Server:

Step 1: First, you add a Thread Group.

Step 2: Next, you add the Recording Controller. The Recording Controller is a logic controller. Optionally, you can add HTTP Request Defaults under the Recording Controller. That will leave those fields in the recorded elements blank if they are specified in the HTTP Request Defaults.

Step 3: Now, we can add the HTTP Proxy Server under the WorkBench. The HTTP Proxy server is a non-test element. You specify a port number for the proxy server (e.g., 8088). If you do not want URLs embedded in the page being recorded, you can set Grouping as “Store 1st sampler of each group only”.

To include or exclude certain resources, you can use “URL Patterns to Include” or “URL Patterns to Exclude”. All will be recorded if nothing is specified. Usually, you can exclude image files or simply click on the “Add suggested Excludes” button to use suggested patterns. You can add the View Results Tree listener if you want to see the responses.

Step 4: We need to change the browser you will be using to set up proxy server information. For Internet Explorer 9, choose the Tools menu -> Internet Options -> Connections. Click on LAN settings at the bottom to bring up a dialog. In the dialog, make the checkbox for the Proxy server checked and type in the port number of the proxy server. Make sure local addresses are not bypassed. Click on the OK button to update it. For Firefox, choose the Tools menu -> Options -> Network -> Settings -> Manual proxy configurations.

Step 5: You switch back to JMeter. Click on the Start button at the bottom of the HTTP Proxy Server to start it.

Step 6: Now, you can open the link to the server from the browser and browse around as usual. Every step you make is recorded. Stop the proxy server when you are done with the recording. Also, remember to change back your browser settings.

The following is a test plan with recorded elements by using Grouping as “Store 1st sampler of each group only” and also “Capture HTTP Headers” checkbox is unchecked. The elements below the HTTP Request Defaults are recorded elements. One way to verify your settings is to connect to a website. You should not be able to connect to it unless the proxy server is started.

 

Before you can run it, at least you need to add an HTTP Cookie Manager since cookie support is needed. Of course, a better way is to create a new test plan and copy elements from the recording test plan. You are allowed to do copy and paste between JMeter instances.

The following is an HTTP Request that contains query parameters for updating a form. You can see query parameters for the form fields from the Parameters tab:

Testing A Web Application Using GWT

A challenge to test web applications using Ajax technologies is that there is no need to request new HTML pages from the server. The interaction between the client (Ajax code running in the browser) and the server is through a remote procedure call (RPC). Certainly, the view source from the browser is not going to help. Using the Recording Controller certainly is very helpful for web applications using technologies related to Ajax. The following example is the recording of a web application using GWT:

 

To run it, you need to add an HTTP Cookie Manager. For each GWT RPC service call, which is AediServerService in this case, you need to add an HTTP Header Manager as a child with the header:

Content-Type: text/x-gwt-rpc; charset=utf-8

Or, you can make the “Capture HTTP Headers” checkbox in the HTTP Proxy Server checked. Then, an HTTP Header Manager will be added to every sampler automatically.

Comparing with the previous example, you are not able to see query parameters for the form fields from the Parameters tab. Instead, you can see the GWT RPC request (a serialized stream in plain text) from the Post Body tab. The following is the GWT RPC HTTP Request from one of the service calls:

As shown in the post body, the GWT RPC request is a sequence of fields using the vertical bar as the delimiter. For detailed information about the GWT RPC wire protocol, you can check

Here, we are only interested in some of the fields. The third field, which is 9, indicates there are nine strings in the string table as shown below:

com.aeditechnology.web.gwtclient.rpc.datamodel.AccountProfile/818247301

This is a test.
1
Test
test1

The third field is the interface name of the GWT RPC service. The fourth field is the name of the method to be called. The fifth field is the type of the first parameter in the method. The remaining fields are the values of AccountProfile. All the remaining numeric fields are used to reconstruct the method call and parameters based on fields in the string table.

Adding JAVA Classes

JMeter allows you to add Java classes in the test plan through the following samplers:

JUnit Request

The JUnit Request sampler allows you to include JUnit test classes in a test plan. To include JUnit test classes, there are two options:

Option1: Pack classes to a JAR file and place it in the lib/JUnit directory

Option 2: Add the directory of JUnit classes to the user.classpath property in the user. properties under the bin directory

Now, in the JUnit Request sampler, you should be able to see those test classes from the class name drop-down. If JUnit test classes are using JUnit 4 annotations, you need to make “Search for JUnit 4 annotations” checked in order to see them. You can select a test method from the Test Method dropdown. One JUnit Request sampler is for one test method.

The following example, it contains test methods of the PurchaseManagerTest from the EasyMock, JUnit, and PowerMock Topic. You need to include methods annotated with @BeforeClass (the setup class method) and @AfterClass (the tear-down class method) in the test plan. They will not be called automatically.

Java Request

Comparing with the JUnit Request sampler, the Java Request sampler has less restriction since it allows you to add any Java classes only if they implement the JavaSamplerClient interface or extend the AbstractJavaSamplerClient class. Developers are encouraged to extend the AbstractJavaSamplerClient class. There are five methods in the AbstractJavaSamplerClient class:

• Logger getLogger(): gets a Logger that can be used to log messages.
• Arguments getDefaultParameters(): defines a list of parameters provided by this test and also what will be displayed in the GUI. Parameters are represented by the Arguments class. Parameters are added through the addArgument(Argument arg) or addArgument(String name, String value) method.
• void setup test(JavaSamplerContext context): does initialization for this test. It is only called once per thread.
• void teardown test(JavaSamplerContext context): does cleanup for this test. It is only called once per thread.
• SampleResult runTest(JavaSamplerContext context): defines actual operations in a test. This is an abstract method that you need to override. This method is called per iteration.

The JavaSamplerContext class is used to get the values of parameters. You can get the value of a parameter through the getParameter(String name) or getParameter(String name, String defaultValue) method for a String. For an integer, you can use the getIntParameter(String name) or getIntParameter(String name, int defaultValue) method.

Explore JMeter Sample Resumes! Download & Edit, Get Noticed by Top Employers!

The SampleResult class is used to contain returned results. To calculate elapsed time, you can use the sampleStart() method to start recording and the sampleEnd() method to end recording. To set this test as successful, you can use the setSuccessful(boolean success) method.

For detailed information, you can check the JMeter API documentation in the docs/API directory.

To compile it, you need to include ApacheJMeter_core.jar and ApacheJMeter_java.jar under the lib/ext directory in the classpath. To deploy it, you can pack it in a JAR file and put it under the lib/ext directory.