To execute a test script, perform the following steps:

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]

An example of running in non-GUI mode

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

In this recipe, we cover how to record test scripts with HTTP(S) Test Script Recorder. Perform the following steps:

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!

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:

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:

This recipe shows you how to generate a test script from captured HTTP web requests in your browser. Perform the following steps:

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.

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:

The View Results Tree component is shown in the following screenshot:

Once added, the test results will be written in real time to these listeners as the test is going on. Each listener gives a different data representation of the test results. Depending on what you are interested in, you will use a different set of listeners.

There are graph listeners that plot graphs in real time, helping you visualize your test results in a graphical way. Also, there are extensions to JMeter that provide even additional result listeners just in case you need more than the built-in listener components.

This recipe shows you how to feed data into your script to handle such scenarios. Perform the following steps:

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:

In this recipe, we will show you how to mimic realistic user behaviors using the JMeter timers.

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.

In this recipe, we will detail how to accomplish this with JMeter. Perform the following steps:

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.

Apart from the automatically extracted cookies by the HTTP Cookie Manager component, JMeter provides a way to add user-defined cookie values to a test plan. Unlike their automatically extracted counter parts, once defined, all threads executing in the test plan will share these values.

In this recipe, we will work through creating a script for an SPA. Perform the following steps:

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 this recipe, we will walk through how you can test such applications using JMeter. Perform the following steps:

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.