JMeter comes with a built-in test script recorder, also referred to as a proxy server (http://en.wikipedia.org/wiki/Proxy_server), to aid you in recording test plans. The test script recorder, once configured, watches your actions as you perform operations on a website, creates test sample objects for them, and eventually stores them in your test plan, which is a JMX file. In addition, JMeter gives you the option to create test plans manually, but this is mostly impractical for recording nontrivial testing scenarios. You will save a whole lot of time using the proxy recorder, as you will be seeing in a bit.
So without further ado, in this article by Bayo Erinle, author of Performance Testing with JMeter - Second Edition, let's record our first test! For this, we will record the browsing of JMeter's own official website as a user will normally do. For the proxy server to be able to watch your actions, it will need to be configured. This entails two steps:
Setting up the HTTP(S) Test Script Recorder within JMeter.
Setting the browser to use the proxy.
(For more resources related to this topic, see here.)
Configuring the JMeter HTTP(S) Test Script Recorder
The first step is to configure the proxy server in JMeter. To do this, we perform the following steps:
Start JMeter.
Add a thread group, as follows:
Right-click on Test Plan and navigate to Add | Threads (User) | Thread Group.
Add the HTTP(S) Test Script Recorder element, as follows:
Right-click on WorkBench and navigate to Add | Non-Test Elements | HTTP(S) Test Script Recorder.
Change the port to 7000 (1) (under Global Settings).
You can use a different port, if you choose to. What is important is to choose a port that is not currently used by an existing process on the machine. The default is 8080.
Under the Test plan content section, choose the option Test Plan > Thread Group (2) from the Target Controller drop-down.
This allows the recorded actions to be targeted to the thread group we created in step 2.
Under the Test plan content section, choose the option Put each group in a new transaction controller (3) from the Grouping drop-down.
This allows you to group a series of requests constituting a page load. We will see more on this topic later.
Click on Add suggested Excludes (under URL Patterns to Exclude).
This instructs the proxy server to bypass recording requests of a series of elements that are not relevant to test execution. These include JavaScript files, stylesheets, and images. Thankfully, JMeter provides a handy button that excludes the often excluded elements.
Click on the Start button at the bottom of the HTTP(S) Test Script Recorder component.
Accept the Root CA certificate by clicking on the OK button.
With these settings, the proxy server will start on port 7000, and monitor all requests going through that port and record them to a test plan using the default recording controller. For details, refer to the following screenshot:
Configuring the JMeter HTTP(S) Test Script Recorder
In older versions of JMeter (before version 2.10), the now HTTP(S) Test Script Recorder was referred to as HTTP Proxy Server.
While we have configured the HTTP(S) Test Script Recorder manually, the newer versions of JMeter (version 2.10 and later) come with prebundled templates that make commonly performed tasks, such as this, a lot easier. Using the bundled recorder template, we can set up the script recorder with just a few button clicks. To do this, click on the Templates…(1) button right next to the New file button on the toolbar. Then select Select Template as Recording (2). Change the port to your desired port (for example, 7000) and click on the Create (3) button. Refer to the following screenshot:
Configuring the JMeter HTTP(S) Test Script Recorder through the template Recorder
Setting up your browser to use the proxy server
There are several ways to set up the browser of your choice to use the proxy server. We'll go over two of the most common ways, starting with my personal favorite, which is using a browser extension.
Using a browser extension
Google Chrome and Firefox have vibrant browser plugin ecosystems that allow you to extend the capabilities of your browser with each plugin that you choose. For setting up a proxy, I really like FoxyProxy (http://getfoxyproxy.org/). It is a neat add-on to the browser that allows you to set up various proxy settings and toggle between them on the fly without having to mess around with setting systems on the machine. It really makes the work hassle free. Thankfully, FoxyProxy has a plugin for Internet Explorer, Chrome, and Firefox. If you are using any of these, you are lucky! Go ahead and grab it!
Changing the machine system settings
For those who would rather configure the proxy natively on their operating system, we have provided the following steps for Windows and Mac OS.
On Windows OS, perform the following steps for configuring a proxy:
Click on Start, then click on Control Panel.
Click on Network and Internet.
Click on Internet Options.
In the Internet Options dialog box, click on the Connections tab.
Click on the Local Area Network (LAN) Settings button.
To enable the use of a proxy server, select the checkbox for Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections), as shown in the following screenshot.
In the proxy Address box, enter localhost in the IP address.
In the Port number text box, enter 7000 (to match the port you set up for your JMeter proxy earlier).
If you want to bypass the proxy server for local IP addresses, select the Bypass proxy server for local addresses checkbox.
Click on OK to complete the proxy configuration process.
Manually setting proxy on Windows 7
On Mac OS, perform the following steps to configure a proxy:
Go to System Preference.
Click on Network.
Click on the Advanced… button.
Go to the Proxies tab.
Select the Web Proxy (HTTP) checkbox.
Under Web Proxy Server, enter localhost.
For port, enter 7000 (to match the port you set up for your JMeter proxy earlier).
Do the same for Secure Web Proxy (HTTPS).
Click on OK.
Manually setting proxy on Mac OS
For all other systems, please consult the related operating system documentation.
Now that is all out of the way and the connections have been made, let's get to recording using the following steps:
Point your browser to http://jmeter.apache.org/.
Click on the Changes link under About.
Click on the User Manual link under Documentation.
Stop the HTTP(S) Test Script Recorder by clicking on the Stop button, so that it doesn't record any more activities.
If you have done everything correctly, your actions will be recorded under the test plan. Refer to the following screenshot for details.
Congratulations! You have just recorded your first test plan. Admittedly, we have just scrapped the surface of recording test plans, but we are off to a good start.
Recording your first scenario
Running your first recorded scenario
We can go right ahead and replay or run our recorded scenario now, but before that let's add a listener or two to give us feedback on the results of the execution. There is no limit to the amount of listeners we can attach to a test plan, but we will often use only one or two.
For our test plan, let's add three listeners for illustrative purposes. Let's add a Graph Results listener, a View Results Tree listener, and an Aggregate Report listener. Each listener gathers a different kind of metric that can help analyze performance test results as follows:
Right-click on Test Plan and navigate to Add | Listener | View Results Tree.
Right-click on Test Plan and navigate to Add | Listener | Aggregate Report.
Right-click on Test Plan and navigate to Add | Listener | Graph Results.
Just as we can see more interesting data, let's change some settings at the thread group level, as follows:
Click on Thread Group.
Under Thread Properties set the values as follows:
Number of Threads (users): 10
Ramp-Up Period (in seconds): 15
Loop Count: 30
This will set our test plan up to run for ten users, with all users starting their test within 15 seconds, and have each user perform the recorded scenario 30 times. Before we can proceed with test execution, save the test plan by clicking on the save icon.
Once saved, click on the start icon (the green play icon on the menu) and watch the test run. As the test runs, you can click on the Graph Results listener (or any of the other two) and watch results gathering in real time. This is one of the many features of JMeter.
From the Aggregate Report listener, we can deduce that there were 600 requests made to both the changes link and user manual links, respectively. Also, we can see that most users (90% Line) got very good responses below 200 milliseconds for both. In addition, we see what the throughput is per second for the various links and see that there were no errors during our test run.
Results as seen through this Aggregate Report listener
Looking at the View Results Tree listener, we can see exactly the changes link requests that failed and the reasons for their failure. This can be valuable information to developers or system engineers in diagnosing the root cause of the errors.
Results as seen via the View Results Tree Listener
The Graph Results listener also gives a pictorial representation of what is seen in the View Tree listener in the preceding screenshot. If you click on it as the test goes on, you will see the graph get drawn in real time as the requests come in. The graph is a bit self-explanatory with lines representing the average, median, deviation, and throughput. The Average, Median, and Deviation all show average, median, and deviation of the number of samplers per minute, respectively, while the Throughput shows the average rate of network packets delivered over the network for our test run in bits per minute. Please consult a website, for example, Wikipedia for further detailed explanation on the precise meanings of these terms. The graph is also interactive and you can go ahead and uncheck/check any of the irrelevant/relevant data. For example, we mostly care about the average and throughput. Let's uncheck Data, Median, and Deviation and you will see that only the data plots for Average and Throughput remain. Refer to the following screenshot for details.
With our little recorded scenario, you saw some major components that constitute a JMeter test plan. Let's record another scenario, this time using another application that will allow us to enter form values.
Excilys Bank case study
We'll borrow a website created by the wonderful folks at Excilys, a company focused on delivering skills and services in IT (http://www.excilys.com/). It's a light banking web application created for illustrative purposes. Let's start a new test plan, set up the test script recorder like we did previously, and start recording.
Results as seen through this Graph Results Listener
Let's start with the following steps:
Point your browser to http://excilysbank.aws.af.cm/public/login.html.
Enter the username and password in the login form, as follows:
Username: user1
Password: password1
Click on the PERSONNAL CHECKING link.
Click on the Transfers tab.
Click on My Accounts.
Click on the Joint Checking link.
Click on the Transfers tab.
Click on the Cards tab.
Click on the Operations tab.
Click on the Log out button.
Stop the proxy server by clicking on the Stop button.
This concludes our recorded scenario. At this point, we can add listeners for gathering results of our execution and then replay the recorded scenario as we did earlier. If we do, we will be in for a surprise (that is, if we don't use the bundled recorder template). We will have several failed requests after login, since we have not included the component to manage sessions and cookies needed to successfully replay this scenario. Thankfully, JMeter has such a component and it is called HTTP Cookie Manager. This seemingly simple, yet powerful component helps maintain an active session through HTTP cookies, once our client has established a connection with the server after login. It ensures that a cookie is stored upon successful authentication and passed around for subsequent requests, hence allowing those to go through. Each JMeter thread (that is, user) has its own cookie storage area. That is vital since you won't want a user gaining access to the site under another user's identity. This becomes more apparent when we test for websites requiring authentication and authorization (like the one we just recorded) for multiple users. Let's add this to our test plan by right-clicking on Test Plan and navigating to Add | Config Element | HTTP Cookie Manager.
Once added, we can now successfully run our test plan. At this point, we can simulate more load by increasing the number of threads at the thread group level. Let's go ahead and do that. If executed, the test plan will now pass, but this is not realistic. We have just emulated one user, repeating five times essentially. All threads will use the credentials of user1, meaning that all threads log in to the system as user1. That is not what we want. To make the test realistic, what we want is each thread authenticating as a different user of the application. In reality, your bank creates a unique user for you, and only you or your spouse will be privileged to see your account details. Your neighbor down the street, if he used the same bank, won't get access to your account (at least we hope not!). So with that in mind, let's tweak the test to accommodate such a scenario.
Parameterizing the script
We begin by adding a CSV Data Set Config component (Test Plan | Add | Config Element | CSV Data Set Config) to our test plan. Since it is expensive to generate unique random values at runtime due to high CPU and memory consumption, it is advisable to define that upfront. The CSV Data Set Config component is used to read lines from a file and split them into variables that can then be used to feed input into the test plan. JMeter gives you a choice for the placement of this component within the test plan. You would normally add the component at the HTTP request level of the request that needs values fed from it. In our case, this will be the login HTTP request, where the username and password are entered. Another is to add it at the thread group level, that is, as a direct child of the thread group. If a particular dataset is applied to only a thread group, it makes sense to add it at this level. The third place where this component can be placed is at the Test Plan root level. If a dataset applies to all running threads, then it makes sense to add it at the root level. In our opinion, this also makes your test plans more readable and maintainable, as it is easier to see what is going on when inspecting or troubleshooting a test plan since this component can easily be seen at the root level rather than being deeply nested at other levels. So for our scenario, let's add this at the Test Plan root level.
You can always move the components around using drag and drop even after adding them to the test plan.
CSV Data Set Config
Once added, the Filename entry is all that is needed if you have included headers in the input file. For example, if the input file is defined as follows:
user, password, account_id
user1, password1, 1
If the Variable Names field is left blank, then JMeter will use the first line of the input file as the variable names for the parameters. In cases where headers are not included, the variable names can be entered here. The other interesting setting here is Sharing mode. By default, this defaults to All threads, meaning all running threads will use the same set of data. So in cases where you have two threads running, Thread1 will use the first line as input data, while Thread2 will use the second line. If the number of running threads exceeds the input data then entries will be reused from the top of the file, provided that Recycle on EOF is set to True (the default). The other options for sharing modes include Current thread group and Current thread. Use the former for cases where the dataset is specific for a certain thread group and the latter for cases where the dataset is specific to each thread. The other properties of the component are self-explanatory and additional information can be found in JMeter's online user guide.
Now that the component is added, we need to parameterize the login HTTP request with the variable names defined in our file (or the csvconfig component) so that the values can be dynamically bound during test execution. We do this by changing the value of the username to ${user} and password to ${password}, respectively, on the HTTP login request.
The values between the ${} match the headers defined in the input file or the values specified in the Variable Names entry of the CSV Data Set Config component.
Binding parameter values for HTTP requests
We can now run our test plan and it should work as earlier, only this time the values are dynamically bound through the configuration we have set up. So far, we have run for a single user. Let's increase the thread group properties and run for ten users, with a ramp-up of 30 seconds, for one iteration. Now let's rerun our test. Examining the test results, we notice some requests failed with a status code of 403 (http://en.wikipedia.org/wiki/HTTP_403), which is an access denied error. This is because we are trying to access an account that does not seem to be the logged-in user. In our sample, all users made a request for account number 4, which only one user (user1) is allowed to see. You can trace this by adding a View Tree listener to the test plan and returning the test.
If you closely examine some of the HTTP requests in the Request tab of the View Results Treelistener, you'll notice requests as follows:
/private/bank/account/ACC1/operations.html
/private/bank/account/ACC1/year/2013/month/1/page/0/operations.json
…
Observant readers would have noticed that our input data file also contains an account_id column. We can leverage this column so that we can parameterize all requests containing account numbers to pick the right accounts for each logged-in user. To do this, consider the following line of code:
/private/bank/account/ACC1/operations.html
Change this to the following line of code:
/private/bank/account/ACC${account_id}/operations.html
Now, consider the following line of code:
/private/bank/account/ACC1/year/2013/month/1/page/0/operations.json
Change this to the following line of code:
/private/bank/account/ACC${account_id}/year/2013/month/1/page/0/operations.json
Make similar changes to the rest of the code. Go ahead and do this for all such requests. Once completed, we can now rerun our test plan and, this time, things are logically correct and will work fine. You can also verify that if all works as expected after the test execution by examining the View Results Tree listener, clicking on some account requests URL, and changing the response display from text to HTML, you should see an account other than ACCT1.
Summary
We have covered quite a lot in this article. You learned how to configure JMeter and our browsers to help record test plans. In addition, you learned about some built-in components that can help us feed data into our test plan and/or extract data from server responses.
Resources for Article:
Further resources on this subject:
Execution of Test Plans [article]
Performance Testing Fundamentals [article]
Data Acquisition and Mapping [article]
Read more
United States
Great Britain
India
Germany
France
Canada
Russia
Spain
Brazil
Australia
Singapore
Canary Islands
Hungary
Ukraine
Luxembourg
Estonia
Lithuania
South Korea
Turkey
Switzerland
Colombia
Taiwan
Chile
Norway
Ecuador
Indonesia
New Zealand
Cyprus
Denmark
Finland
Poland
Malta
Czechia
Austria
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Netherlands
Bulgaria
Latvia
South Africa
Malaysia
Japan
Slovakia
Philippines
Mexico
Thailand
