Load Testing with Apache JMeter 102

Author: Antonio Navas
Date: June 27th 2011

Load Testing with Apache JMeter Part 2: Creating Test Plans (Scripts) and Beyond

Creating the Test Plan (Scripts):

Now that you have had a tour of the basics of getting JMeter up and running and a tour of the components that make up a test case, it’s time to create a script, or from this point forward we will refer to it as a “test plan”. A test plan is a series of steps that JMeter executes during running time and will consist of one or more elements like:

• Thread Groups
• Logic Controllers
• Sample Generating Controllers
• Listeners
• Timers
• Assertions
• Configuration Elements
• User defined Variables or User Parameters
• Regular Expression Extractor

Create a Thread Group: The thread group is created by right-clicking on the Test Plan as shown in the picture below. Then select Add and then Threads (Users) and, finally, the Thread Group option.

After selecting the thread group option, a thread group element will be created under Test Plan element. The Thread Group will be used to define the number of users that will be simulated and the number of times the test plan will be repeated: loop x times with – or loop forever – using x VUs (Virtual Users) .

The Thread Group screen – and its elements – is shown below:

Create the HTTP Requests: In order to add the set of URLs that will be processed and the parameters they should pass to the application under test, we need to…

1. Add a HTTP Proxy Server: Right click on the WorkBench node. Then select Add => Non-Test Elements => HTTP Proxy Server as shown in the picture below.

After selecting the HTTP Proxy Server option, a HTTP Proxy Server group element will be created under WorkBench element. The HTTP Proxy will be used to record the steps performed in a browser while navigating the AUT.

The HTTP Proxy Server screen – and its elements – is shown below:

Add a Proxy Configuration to the Browser: Before we can record the steps performed in the browser, we will need to change the browser configuration settings. To do so follow the instructions found in the picture below.

Before we can start doing the recording, we need to go to JMeter. Click on the HTTP Proxy Server and click on Start to initiate the proxy server.

Recording the Test Script: At this point, you can navigate your AUT manually or run any automated script that simulates the steps to be recorded. As a way to easily verify my test cases using the GUI, I normally keep a Selenium working copy of each performance script. Once you have completed the navigation of the AUT, go back to HTTP Proxy Server and click on Stop to stop the recording. Then click on the small key located left to the HTTP Proxy Server to expand it and see the requests already recorded.

The picture above shows the different HTTP Requests that were recorded by the HTTP Proxy Server. The next step is to analyze them, identify which ones will be used for the testing and move them to the test case they belong to and delete the remaining ones.

Adding Controllers: Before we move them, we are going to add some controllers to mimic our test cases. In order to do so go to Edit => Add => Logic Controllers => Once Only Controllers. The picture below shows the controllers already created:

Next, we will rename these controllers as follow: Landing Page, Processing Page, Services Page, Place Order Page and Order Confirmation Page.  After that, we will move the samples we want to use to their respective test scenario and remove those we don’t want to use. In the next picture you can see the final result;

 
Click to Enlarge 

Test Plan Structure: Before continuing, let’s pay special attention to what we have done to this point. Our controllers have been named: Landing Page, Procession Page, Services Page, Place Order Page and Order Confirmation Page, and HTTP Request samplers have been moved under them, See picture below for details:

Adding Variables: From the second image above – HTTP Request showing HTTP parameters and variables – it’s clear that we also need to manage global and test script specific variables like host name and promotional elements that will be changing from one script to the next.  In order to add a global variable, those that won’t change during the test – right click on Thread Group and select Add => Config Element => User Defined variables. In the User Defined Variable screen click on “Add” to add a new variable. Then double click on the gray area located under name and enter host. Double click under value and enter the application URL. The end result is shown below:

For those variables that change during the test (for example from one thread group to the next), we will need to add a User Parameter element. Do so by right clicking on the thread group and then Add => Pre Processors => User Parameters.

Now we should go to each one of the samplers and replace the values with the variables just created:

• app/qa.com will be replaced with ${host}
• SpecialServices with ${promo}
• 20%Discount with ${optionalpromo1} and
• FreeShipping with ${optionalpromo2}

Capturing and Reusing the Session ID: In the AUT used for this demo there are two requests associated with the Landing Page. The first requests pass some identification parameters and, in the response, the system returns the session id that should be used in all the other requests. First step is to analyze the responses and identify where the session Id information is returned. In order to do so, we need to right click on the first Landing Page HTTP Request – that we have called Launch Landing Page – and select Add => Assertions => Response Assertion as shown in the picture below:

Once the Response Assertion is generated, we will define the pattern JMeter will be looking for during run time.

 
Click to Enlarge

From the picture above, JMeter will be looking for the name SID in the Text Response. The search can also be performed against the Response Code, Response Message, Response Header, etc. During running time, we will monitor in the Results View if the assertion is satisfied or not. If not, we will try other response elements until we are able to identify in which response element the SID is returned. 

In order to capture the session Id information, we need to add a regular expression extractor. Right click on Launch Landing Page and select Add => Post Processor => Regular Expression Extractor. Once we clearly identify where the session Id is returned, we need to verify how it is formatted. Then we need to create a regular expression that it’s capable to read such presentation pattern.

The session Id is returned in the text response as: “SID”:” 937793d4-3f0c-4cfa-8dbd-488cb09aeb13” Our regular expression looks for the first occurrence of SID:” and get the value embedded into the commas.

Create Results View: In order to see the HTML results for each request we make we need to add a View Results Three Listener. We do so by right-clicking on the Thread group node and select Add -> Listener-> View Results Tree.  We can also add other listeners like View Results in Table (right click on Thread Group and then Add => Listener => View Results in Table) and / or Graph Results (right click on Thread Group and then Add => Listener => Graph Results)

Finally, we’re ready to run our test. We do so by going to Run => Start. When prompted, we save the file and the test starts. And, as the test progress, we will see the requests and responses and their status.

See below the different result listeners as seen at the end of the testing:

View Results Tree (HTTP Requests in green passed, in red failed. HTTP Requests failing need to be fixed before continuing):

View Results in Table:

View Graph Results:

Applying a Load:

In order to apply some load to the test environment we need to change the numbers in the Thread Group. First, let's estimate the number of HTTP Request being processed in our Test case. There are a total of 17 request sent in the test case. In the figure below you will see we are running 50 threads (or 50 VUs) that will ramp up at 5 VU per second for 10 seconds. The test will run 12 times (12 iterations). Each test will submit 17 requests so 10200 requests will be processed (50 VUs x 17 request per iteration x 12 iterations)

In Summary:

The principle behind JMeter is very simple. All you need to build your test plan is the URL and the requests you want to simulate. You can add variables, counters, parameters, CSV files, loops, logs, etc.

Finally, there is an extensive documentation on the website: User manuals, wikis, docs, examples, etc. So enjoy your testing!!!