In this chapter, we will cover the following recipes:
Executing a test script
Recording a script via HTTP(S) Test Script Recorder
Recording scripts via the Chrome browser extension
Converting HTTP web archives (HAR) to JMeter test plans
Viewing and analyzing test results
Feeding data into a script
Using timers
Managing HTTP user sessions
Testing Single Page Applications (SPAs)
Testing AJAX-centric applications
In this chapter, you will learn the fundamentals and intermediate skills that will help you work better with JMeter. Tasks such as executing or recording scripts are routine and you can be almost certain that you will need to perform them, sometimes on a daily basis. Also, we will learn how to view and analyze the results of test executions, feed data into test scripts, and make test scripts mimic user behavior with the aid of timers. In later recipes, we dive into dealing with handling authentication, authorization, and testing today's new breed of applications with JMeter.
Sometimes, the test scripts to execute have already been recorded and handed over to you to run. In this recipe, we will show you just how to go about executing a script that was prerecorded.
To execute a test script, perform the following steps:
Open the command line prompt.
Change to the directory of your JMeter install. We'll refer to this as
JMETER_HOME.Note
Refer to Appendix for JMeter installation instructions.
Change
JMETER_HOMEto thebindirectory.To launch the JMeter GUI on Windows, type in
jmeter.bat. Alternatively, for Unix/Mac OS, type in./jmeter.Navigate to File | Open.
Navigate to the script you want to execute. For example,
ch1/getting_started.jmxprovided with the sample code.Press the green start icon at the top.
View the results from one of the added listeners. If you are using
getting_started.jmxfrom step 6, click on the View Results Tree listener as shown in the following screenshot:
Executing a test script
Test scripts are a series of prerecorded requests issued against an application. They are captured interactions of a user's actions with the application. These include visiting a URL, navigating around several pages, logging in, and so on. JMeter, like most test tools, has the ability to record and replay back test scripts. JMeter test scripts are stored in the XML (extendable markup language) format with the .jmx extension. Curious users can open the test script in a text editor of their choice (for example, Sublime Text, Notepad, and so on) and view exactly what it is doing, though, it is much more clear to understand what a script does by looking at it in JMeter's GUI.
After executing the test, results are reported through any configured listeners. A script can have one or several listeners attached to it (see recipes in Chapter 7, Building, Debugging, and Analyzing the Results of Test Plans).
Scripts can also be executed in what JMeter refers to as non-GUI mode, which is completely on the command line without launching the JMeter GUI. To do this, instead of executing jmeter.bat or JMeter, like we did in step 4, we'll use certain JMeter command-line arguments to specify the test script and the resulting output file, which we can then go back and view with the JMeter GUI after the tests are executed.
On Unix/Mac OS, type in the following command:
./jmeter -n -t [path to test script] -l [path to results files]
On Windows, type in the following command:
jmeter.bat -n -t [path to test script] -l [path to results files]
Here is an example of running code in non-GUI mode: This is how we executed the google_simulation.jmx test script in our bundled sampled in non-GUI mode. As you can see, we supplied parameters –n and –t and the absolute path to where our script is located (/Users/berinle/workspace/jmeter-cookbook/ch1/google_simulation.jmx) followed by the path to the results file (/Users/berinle/workspace/jmeter-cookbook/ch1/google_simulation_result.csv).
./jmeter -n -t /Users/berinle/workspace/jmeter-cookbook/ch1/google_simulation.jmx -l /Users/berinle/workspace/jmeter-cookbook/ch1/google_simulation_result.csv
Created the tree successfully using /Users/berinle/workspace/jmeter-cookbook/ch1/google_simulation.jmx.
Starting the test @ Tue Feb 25 05:07:45 EST 2014 (1393322865378)
Waiting for possible shutdown message on port 4445.
Tidying up ... @ Tue Feb 25 05:08:46 EST 2014 (1393322926156)
... end of run
Tip
Downloading the example code
You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
To view the results after the test has been executed, open up the JMeter GUI, create a new test plan, and add a listener to it by navigating to Test plan | Add | Listener | Aggregate Report. Click on the Browse… button to navigate to the location of the results file and open it. This is demonstrated in the following screenshot:
Viewing the results of a test run
There are several reasons why you might want to execute a test in non-GUI mode. Some of the reasons include:
Running on a Unix machine with no GUI layer (that is, the JMeter GUI does not even open up)
Running a distributed test
Performance reasons of the JMeter GUI, which can sometimes be resource intensive; running in non-GUI mode alleviates this issue
Recording scripts is where you will spend most of your time. It is often the first step to develop test plans for applications. Though you can develop test plans manually by building them from within the JMeter GUI, or generating them via some domain-specific language (DSL), recording scripts by JMeter's HTTP(S) Test Script Recorder is one of the available options you have when building your test plans.
In this recipe, we cover how to record test scripts with HTTP(S) Test Script Recorder. Perform the following steps:
Start JMeter. Perform the following steps:
Open the command-line prompt
Change to the directory of your JMeter install (
JMETER_HOME)Change to the
bindirectoryExecute the following command:
For Windows, type the following command:
jmeter.batFor Mac OS/Unix, type the following command:
./jmeter
Once the GUI is opened, click on the Templates… button (the icon that appears immediately to the right of the new test plan icon) on the toolbar.
In the drop-down menu of the Select Template box, choose Recording and click on the Create button.
Click on the HTTP(S) Test Script Recorder element (under WorkBench) and change Port (under Global Settings) from
8888to7000.You can use a different port if you want to. What is important to choose is a port that is not currently used by an existing process on the machine. The default is
8888.
Leave the rest of the components with the default set values.
The template does an excellent job and is configured with sensible defaults. The defaults provide the following:
Target the recorded actions to Recording Controller added by the template.
Group a series of requests that constitute a page load. We will see more on this topic later.
Instruct the script recorder to bypass recording requests of a series of elements that are not relevant to test execution. These include JavaScript files, style sheets, and images.
Add the often-used components, including user-defined variables, HTTP Request Defaults, and HTTP Cookie Manager, to the test plan.
Add Thread Group and Recording Controller to the test plan.
Add a View Results Tree listener to view results of the test plan.
Click on the Start button at the bottom of the HTTP(S) Test Script Recorder component.
With these settings, the test script recorder server will start on the port 7000, monitor all requests going through that port, and record them to a test plan using the default recording controller. For details, see the following screenshot:
HTTP(S) Test Script Recorder configuration
These steps instruct JMeter to act as an HTTP proxy and listen for incoming and outgoing requests from your browser to the Internet on the assigned port, in our case 7000.
We now need to configure the browser to use the proxy server we just configured and redirect requests to the assigned port. There are several ways to do that, but we will focus here on the two most common ways.
Modern browsers have a vibrant and active plugin ecosystem that allows you to extend the capabilities of your browser with an added plugin. FoxyProxy is one such plugin (http://getfoxyproxy.org/). It is a neat add-on for a browser that allows you to set up various proxy settings and toggle between them on the fly, without having to mess around with system settings on the machine. It really makes the work hassle free. Thankfully, FoxyProxy has a plugin for all major browsers including Google Chrome, Firefox, and Internet Explorer. If you are using any of those, you are lucky; head over and grab it!
The other common way to configure the browser is to change the system settings. The following are the details on how to configure Windows and Mac OS.
On Windows OS, perform the following steps to configure a proxy:
Navigate to Start | Control Panel | Network and Internet | Internet Options.
In the Internet Options dialog box, click on the Connections tab.
Click on the LAN Settings button.
To enable the use of a proxy server, check the Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections) box as shown in the following screenshot.
In the proxy Address box, enter
localhostin 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 the local IP addresses, select the Bypass proxy server for local addresses checkbox.
Click on OK to complete the proxy configuration process. This is shown in the following screenshot:
Manually setting a proxy on Windows 7
On Mac OS, perform the following steps to configure a proxy:
Navigate to System Preference | Network | Advanced….
Go to the Proxies tab.
Check Web Proxy (HTTP).
Under Web Proxy Server, enter
localhost.For port, enter
7000(to match the port you set up for your JMeter HTTP proxy earlier).Do the same for Secure Web Proxy (HTTPS).
Click on OK, as shown in the following screenshot:
Manually setting a proxy on Mac OS
For all other systems, consult the related operating system documentation.
With both JMeter's HTTP(S) Test Script Recorder and browser configured to use it, we are now ready to record a test. Perform the following steps:
Point your browser to a website of your choice.
Navigate to a few links.
Notice that all user actions are being captured under the Thread Group component in the JMeter GUI.
Stop the recording by stopping HTTP(S) Test Script Recorder.
The HTTP(S) Test Script Recorder server is set up to listen to requests on a particular port and then set the browser or system to redirect all requests to the assigned port. This allows us to capture the user actions as they interact with web applications, allowing us to replay their actions like we did in the Executing a test script recipe.
The Recording scripts via the Chrome browser extension recipe in Chapter 8, Beyond the Basics
The Writing Test scripts through Ruby DSL recipe
The Converting HTTP web archives (HAR) to JMeter test plan recipe
Recording test scripts is one you will be doing quite often. There are many alternatives to how we can record test scripts in JMeter.
In this recipe, we show you how to record test scripts with just a browser add-on installed on the Google Chrome browser. Perform the following steps:
Install the Google Chrome browser if it's not already installed on your machine.
Note
You can download it from https://www.google.com/intl/en/chrome/browser/.
Open the Chrome Web Store.
Search for
blazemeteron the web store.Install the BlazeMeter browser extension by clicking on the Free button.
Click on the newly added BlazeMeter extension button in the top-right corner of your browser toolbar.
Press the Record button.
Point your browser to a website of your choice.
Navigate through the website as you will normally do as a user.
After the previous step, stop the recording and click on the export to jmx button (.jmx). This will download a copy of your script to your local machine.
Add View Results in Tree Listener to the test plan (Test plan | Add | Listener | View Results in Tree Listener).
Run the exported test script with JMeter.
View the results.
Tip
Exporting your recorded test plan requires a free account with BlazeMeter for you to be logged in.
Installing the BlazeMeter Chrome extension
The BlazeMeter Chrome extension should look similar to what is shown in the preceding screenshot. Using this extension, additional properties can be configured in the Advance section of the extension. The following is a screenshot of the extension:
Using the BlazeMeter Chrome extension
The browser extension captures the user interaction with the website in the JSON format as long as the recorder is on.
When the recording is stopped, no further user actions are captured. After the export button has been clicked on the JSON format is then converted to the XML format, which JMeter understands and can work with. The downloaded recorded script can then be edited and run within JMeter like any other script.
The extension allows you to selectively capture requests by providing you with the ability to pause recording in between the user interactions. It also allows you to filter out unwanted traffic you might not be interested in capturing in your test scripts through the include filter pattern text area.
Furthermore, the Advance menu option allows you to gain more control over which requests are captured in your script, allowing you to capture only the top-level requests (default), disable browser cache (default), disable recording cookies (default), and edit the setting before proceeding to run.
Finally, as BlazeMeter (one of the many providers offering distributed testing in the Cloud) provides this extension, it offers additional features including the following:
Another alternative to recording test scripts in JMeter is converting the existing HTTP web archives directly into JMeter test scripts.
This recipe shows you how to generate a test script from captured HTTP web requests in your browser. Perform the following steps:
Install and launch the Google Chrome browser (if you don't already have it).
Open Developer Tools by navigating to Tools | Developer Tools.
Opening Chrome Developer Tools
Click on the Network tab.
Once you have finished browsing, open the developer tool window, right-click and select Copy All as HAR.
Point your browser to https://flood.io/har2jmx.
Copy the contents of the clipboard to the input box.
Click on the Convert button.
Launch the JMeter GUI.
Open and examine the downloaded test script.
Add View Results in Tree Listener to the test plan (Test plan | Add | Listener | View Results in Tree Listener).
Save and run the exported test script.
View the results.
Make sure that the Preserve log checkbox in the Network tab is checked to ensure all the user actions are captured, as illustrated in the following screenshot:
Preserve log checkbox in the Network tab
As shown in the following screenshot, while on the Network tab, right-click to see the Copy All as HAR option:
Copy All as HAR
With the help of built-in browser tools and plugins, a browser is able to capture all interactions between a user and a web application into the JSON (JavaScript Object Notation) format known as the web archive (HAR). This resulting JSON object includes all the information about each request including HTTP headers, methods, query strings, and so on. Given the JSON object or a file with its content, the HAR to JMX converter can then read, parse, and construct JMeter elements for each user request, similar to what a JMeter HTTP proxy would have done.
For command-line fans who do not wish to go through the Flood IO's website to do a conversion, there's a command-line tool that can be used to achieve the HAR TO JMX conversion. Har2jmeter located at http://seitenbau.github.io/har2JMeter/ is a utility written in the Groovy language. It's still in its infancy, so you might encounter a few quirks here and there. While testing it, one thing we found out is that it currently didn't play well with secure connections (HTTPS). Also, it didn't group requests into logical controllers. We mention it here just to make you aware that it exists and such bugs will probably be fixed in the near future.
Tip
For Firefox, the firebug plugin allows you the same capability to capture requests as HAR. Visit http://www.ehow.com/how_8789702_create-har-files-using-firebug.html to see how this can be accomplished.
When it comes to viewing your test results, JMeter comes with a vast number of components to aid this regard. Each component gives a different perspective into how to visualize your test results. Deciding which to use depends mostly on what kind of data you are interested in for a test run. Also, JMeter doesn't place a limit on how many of these listeners you can use on a test script, so it's not uncommon to see scripts with several results listeners.
In this recipe, we will cover three of the most popular built-in viewing components you will most likely need for your scripts. This is by no means an exhaustive list, so be sure to explore other viewing components. Perform the following steps:
Launch JMeter.
Open a previously recorded test script.
Add a View Results Tree listener by navigating to Test plan | Add | Listener | View Results Tree.
Add a Aggregate Report listener by navigating to Test plan | Add | Listener | Aggregate Report.
Add View Results in table by navigating to Test plan | Add | Listener | View Results In Table.
Examine the results on each of the added results listeners. The entire process is shown in the following screenshot:
Adding the View Results Tree listener
The View Results Tree component is shown in the following screenshot:
More often than not, we will need to provide varying input datasets to our scripts to simulate realistic user interaction with an application. Most applications, for instance, need to be authenticated against to view certain restrictive areas of the application. The way to accomplish this is by supplying an input datafile to the test script. The file is normally in the form of comma-separated values (CSV).
This recipe shows you how to feed data into your script to handle such scenarios. Perform the following steps:
Download the book code samples from http://www.packtpub.com/jmeter-cookbook/book.
Note
Alternatively, you can clone the sample from the GitHub repository at http://github.com/jmeter-cookbook/bundled-code.
Extract the contents of the ZIP file.
Launch JMeter.
Open the
ch1_feed_me_data.jmxscript from thescripts/ch1directory.Add CSV Data Set Config to the test plan by navigating to Test Plan | Add | Config Element | CSV Data Set Config. Let's configure it:
In the Filename box, enter
input.txt.Leave the rest of the entries blank.
Save and run the test. The execution of the script is shown in the following screenshot:
Assuming you haven't changed the default sharing mode of the added CSV dataset configuration, with each iteration run of our test plan, a line of the input.txt file is consumed. The consumed values are then turned into JMeter variables named after the first line of our input datafile, which are user and pass in our case. The values are then used further down the execution chain to fill in the username and password to access our application. In this particular test plan, as we have more threads than the amount of input data, the input data is recycled once the end of the file is reached.
In our example, we have just provided the name of the file to read the input feed from. If you examine the CSV dataset configuration element closely, you will notice that it has other properties that can be filled in. These include the following:
Variable Names: Provide the comma-separated names of the variables. As we left this blank, the first line of our input script will be treated as the variable name.
Delimeter: Change to this option if you want to use a different delimiter other than a comma. For instance, you can use tab spaces (
\t) or the colon symbol (:) instead of commas.Allow Quoted Data: Set to True, if you would like to allow quoted data. For example,
'hello'as opposed tohello.Recycle on EOF: In cases where you have more threads than the input data, this attribute specifies whether to allow the input data to be recycled. In such a case, the input feed will start from the beginning of the file once the data feed has run out.
Stop thread on EOF: This option determines whether to kill the thread has been reached.
Sharing mode: The default option is
All meaning all threads; even those in a different thread group get to share the same data. The other options are Current thread group and Current thread, which specify that only the threads within a particular thread group and only a particular thread can retrieve data from the file, respectively.
By default, when test scripts are recorded in JMeter, they contain no pauses between page requests. This is sometimes known as the think time in test scripts. In reality though, most users will frequently pause for a duration of time on every page before moving on to another page in the application. In JMeter, the ways to achieve these pauses are through timers. JMeter comes with a wealth of timers to achieve this purpose.
In this recipe, we will show you how to mimic realistic user behaviors using the JMeter timers.
Launch JMeter.
Open the
ch1_add_timers.jmxtest script located in thescripts/ch1directory.Add Gaussian Random Timer by navigating to Test plan | Add | Gaussian Random Timer.
Change Deviation (in milliseconds) from
100to1000.Change Constant Delay Offset (in milliseconds) from
300to500.Save and execute the test script.
With our configuration, each thread will pause for a duration of 0.5 to 1.5 seconds after each request before proceeding to the next request. This is because we applied the timer at the root level of the test plan. If we wanted to have pauses after each logical page rendering, we will add a timer at the transaction controller level. This option is mostly what you will go with as a single rendered web page often consists of multiple requests.
There are many more timers that come bundled with JMeter even through additional plugins that serve different purposes. There are timers that simulate constant delay, constant throughput, random delay, and so much more. Depending on your use case and what you are trying to simulate, you will choose one or several of these.
Most websites have a means of authenticating users, thereby enabling them to gain access to protected data or content that only pertains to them. Also, it is very common for websites to give users different roles based on what the user will be doing. For instance, a user called Joe could be given admin privileges while Susan is only given user privileges. Whatever the case, JMeter has a way to maintain HTTP user sessions for your test scripts.
In this recipe, we will detail how to accomplish this with JMeter. Perform the following steps:
Launch JMeter.
Open the
add_cookie_manager.jmxtest script.Run the test plan.
Notice the failed requests, even though the log in request succeeded:
The Request immediately option following the log in request is indicative of this. The Request tab shows no cookies were sent with the request. Refer to the following code:
GET http://evening-citadel-2263.herokuapp.com/ [no cookies] Request Headers: Connection: keep-alive Host: evening-citadel-2263.herokuapp.com User-Agent: Apache-HttpClient/4.2.6 (java 1.5)Furthermore, our response assertions fail, as subsequent requests were not associated with the existing user, but were treated as new requests.
Clear the results (Mac OS: Command + Shift + E and Windows: Ctrl + Shift + E).
Add HTTP Cookie Manager to the test plan by navigating to Test plan | Add | Config Element | HTTP Cookie Manager.
Save and run the test plan.
Observe the results in the View Results in Tree listener and notice how all the requests now succeed:
If you observe the request immediately following the log in request, you will notice that the cookie information is correctly sent with the request, thanks to the added HTTP Cookie Manager. You should see something similar to this:
GET http://evening-citadel-2263.herokuapp.com/ Cookie Data: connect.sid=s%3AWN5ITZxWEKyzmmAB5sct7PjA.6UAJ36%2F9%2BWFQPjdzA%2B7%2B1NL4%2Bf0HzC %2BOQI%2Bol0V0eJ0 Request Headers: Connection: keep-alive Host: evening-citadel-2263.herokuapp.com User-Agent: Apache-HttpClient/4.2.6 (java 1.5)
The HTTP Cookie Manager stores and sends cookies like a web browser does. The cookie of any request that contains one is automatically extracted and stored by the component to be used for all future requests from that particular thread. Each JMeter thread gets its own session just like in a regular web browser to prevent users' sessions from overlapping with each other.
Single-page applications are the new wave of web applications being developed in today's technological industry. The benefits of developing such applications can't be overstated. They relieve the servers of enormous load and bring faster responsiveness to the end user. They are architected differently from traditional web applications, which make them slightly different to develop test scripts for.
In this recipe, we will work through creating a script for an SPA. Perform the following steps:
Launch JMeter.
Add HTTP(S) Test Script Recorder and set it up for recording (see the Recording a script via JMeter HTTP proxy recipe).
Click the Add suggested Excludes button.
Start the HTTP(S) Test Script Recorder.
Point your browser to http://angular.github.io/peepcode-tunes/public/.
Add the two available albums (on the right) to your playlist (on the left).
Randomly select a song to listen to.
Use the buttons on the player to jump to the next or previous song or pause them.
Stop the HTTP(S) Test Script Recorder.
Add a listener to your test plan.
Save and run the test plan.
The actions of the user are tracked and recorded via the script recorder we set up in step 2. Like traditional web applications, we record all actions and exclude irrelevant static resources, such as images, JavaScript, and style sheets. Every call that makes a server call to backend services is also recorded as part of the test plan and is available for replay during test execution. At the end, we have a script that is almost identical to what we would get when recording a traditional web application.
Most SPAs tend to be JavaScript-intensive. As JMeter isn't a web browser, JavaScripts embedded within a page or included from a separate file altogether won't be executed. With this in mind, it means JMeter can't be accurately used to measure page load times or browser DOM rendering. What it can do, however, is record any calls made to the server from your JavaScript files and play those back when the test is re-executed.
Such calls have an impact on the servers and are critical to measure to know how slow or fast a user's experience will be when the application is under considerable load.
In today's stack of web applications, it is almost unthinkable to build an application without some dynamic content being retrieved from a backend service. Most of the time, these applications tend to lean towards partial page fresh. That is, only the needed sections of a rendered page are refreshed as opposed to the whole page loading its entire content again. This leads to more responsive pages, which improves the overall experience of the user.
In this recipe, we will walk through how you can test such applications using JMeter. Perform the following steps:
Launch JMeter.
Add HTTP(S) Test Script Recorder and set it up for recording (see the Recording a script via JMeter HTTP proxy recipe).
Click the Add suggested Excludes button.
Start the HTTP(S) Test Script Recorder.
Point your browser to https://maps.google.com.
Perform a couple of searches in the provided search box (for example, pizza, restaurants, hotels, and so on).
Click on a few of the returned results.
Repeat steps 6 and 7 two more times.
Stop the HTTP(S) Test Script Recorder.
Add a listener to your test plan.
Save and run the test plan.
The actions of the user are tracked and recorded via the script recorder we set up in step 2. Like traditional web applications, we record all actions and exclude irrelevant static resources, such as images, JavaScript, and style sheets. Calls that trigger backend server calls are trapped and are available for replay later. At the end, we have a script that is almost identical to what we would get when recording a traditional web application.
AJAX-centric applications tend to involve a lot of asynchronous server requests made from within the client (frontend). These calls are normally made from embedded script tags within a view technology, for example, HTML, Java Server Pages (JSP), Groovy Server Pages (GSP), or from an included JavaScript file in the page. As such, JMeter records all such server requests and they can be played back at the time of running our test plans. This allows us to simulate the intended load on our servers, as though the application was the one making the AJAX calls.
