Version 1

    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 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 “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 results from two listeners defined in it. The following screenshot is from the View Results Tree:

    On the results tree, it 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 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 comparing with a browser. JMeter also can handle different types of documents (e.g., PDF, MS Office). You can view text in the document by choosing Document. Since the View Results Tree records requests and responses from all visited pages, it is good for checking the behavior of a web application or to debug 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 a 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 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 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 into previous example. Each thread will randomly select one of the four pages in previous example as the starting page and crawl through the web site. 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, you can check HTTP://JMETER.APACHE.ORG/USERMANUAL/REGULAR_EXPRESSIONS.HTML.

    To continue crawling through the web site, 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 desired runtime in the Runtime field.

    The following is the revised version:


    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 web sites that require user authentication, you need to add additional steps to sign in the web site automatically in the test plan before it can do anything.

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

    It is using 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 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 web site 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 login page to initialize 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.


    What if you need to stop testing in case of connection problem such as connection refused by the server? In such 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 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 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 exception (e.g., HttpHostConnectException) in the response. Parentheses ( and ) indicates a group in the regular expression. It is used to get a portion of 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, default value “NO_EXCEPTION” is returned. The value is assign 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 matched string is highlighted if there is any. Click on the Find next button for next matched string.

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


    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 view source in a browser. You can use the Recording Controller to record test samples. You are doing 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 an 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 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 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 web site. 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 upating a form. You can see query parameters for the form fields from the Parameters tab:


    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, 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 “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 HTTPS://DOCS.GOOGLE.COM/DOCUMENT/D/1EG0YOCSYYBNATIVKLTCAIEE5IOF5U4LUOL8-LL0TIKU/EDIT?PLI=1. 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:

    This is a test.

    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 values of AccountProfile. All the remaining numeric fields are used to reconstruct the method call and parameters based on fields in the string table.


    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 to a test plan. To include JUnit test classes, there are two options:
    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 Classname 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.

    In 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 setupClass method) and @AfterClass (the tearDownClass 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 which 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 setupTest(JavaSamplerContext context): does initialization for this test. It is only called once per thread.

    void teardownTest(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 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. For a long, you can use the getLongParameter(String name) or getLongParameter(String name, long defaultValue) method.

    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.