{ArticleIndex}

loadUIs interactive interface and real-time approach to load testing makes it an ideal tool for testing web pages or entire web sites. This document will give an overview of the possibilities and dig into the possibilities of creating realistic load simulations for asserting your sites performance.

Basics

loadUI provides two possibilities of performing web requests to a target web site that needs to be tested:

1. The Web Page Runner component is ideal for quickly testing any number of session-less web pages either in sequence or in parallel
2. The soapUI Runner component is ideal for testing more complex web scenarios where sessions, parameters, etc are important. The actual flow of web pages to be tested is first set up in soapUI (using its Web Testing functionality), the created soapUI TestCase is then run from inside loadUI.

Since the latter of these is described in detail in "Running soapUI TestCases", we’ll start with a quick look at the Web Page Runner before we dig into possibilities available for both these runners.

The Web Page Runner

The Web Page Runner is a simple component for calling a specified web page from inside soapUI and measuring its performance. You add it to your project from the Component Toolbar to the left:

Set the “Web Page Address” field to the address you want to test, connect a Generator to the input of the Runner and off you go:

The display counters to the right are the standard ones described for all Runners described in the Component Overview, so if we connect the left and right outputs to a statistics component we get the following setup:

Advanced Settings

Opening the Settings dialog for the Web Page Runner (via the wrench icon on its toolbar) we get the following dialog:

Here we can set a number of options related to failures and response handling. For example if we want a 404 response to be reported as a failure we can add the number “404” in the “Error Codes that Raise an Assertion” field and check the “Raise Assertion on Error”; now every 404 response will increase the global failure counter (see Validating Results).

By default the Web Page Runner does not read the actual response page in its entirety unless the “Read Response” option is checked (saving bandwidth), combined with the “Output Response Body” option the Web Page Runner will both read and add the response to each outgoing result message (on the left output terminal), which could for example be used for logging purposes:

(As you can see each result message contains not only the timestamp and time taken, but also the HTTP Status, size and URI of the request)

Testing more than one Web Page

Obviously loading only one web page is not enough for many scenarios. Fortunately there are many ways to load several pages, both in sequence or in parallel. Running two pages after each other is straight forward; just connect the left output of the first to the input of the second:

Since the Web Page Runner runs for each incoming message, it will execute every time the first Web Page Runner finishes a request and outputs the results. In this way we can chain and split flow how we want:

Here each result from the first Web Page Runner results in two parallel “runs” of two separate web pages after each other. Since this is not realistic (most users would not perform two parallel actions at the same time) we should add a Splitter component after the first Web Page:

The Splitter component sends the incoming message to the configured outputs either sequentially or randomly, so now our scenario randomly goes to either the left or the right flow of pages after the first page.

Let’s top this off by adding a delay between the last two Web Page Runners (since users usually spend some time on a web page before clicking onwards):

Here I’ve set a delay of 10000 ms using Gaussian distribution, which gives a reasonably realist simulation of user behavior (the delay should probably be longer).

Checking Web Page Performance

The key component for checking the performance of a Web Page is the Statistics Component which in combination with Assertions can continuously validate that the performance of your web pages are in line with the requirements. Let’s add a Statistics Component to the above setup for the first Web Page Runner:

As we can see the TPS value is steady around the 50 mark (as we are running 50 req/sec) and the average response time is between 10 and 20.

Let’s top this off by adding an assertion to validate that the average doesn’t go over 20 ms. The Statistics component periodically updates its values (every 500ms by default) and publishes the current values to its output terminal; we can connect this to an Assertion component and configure it to validate the Avg value to be between 0 and 20 continuously:

(Read more about Assertions in Validating Results)

Using soapUI for complex Web Tests

As nice as the above setups might be, they don’t fit the bill if you need to do one of the following in your Web tests:

• Maintain sessions via HTTP Cookies or some other mechanism
• Perform other HTTP requests than standard GET (for example if you want to submit a form with POST)
• Transfer some kind of values from the output of a response to the input of the next (for example transferring the ID of a found item in a search to the actual URL for retrieval of the item)
• Validate the content of the HTML responses to see that they contain the expected data
• Integrate the test with tests of other interfaces for example SOAP or JDBC (for example if you want to validate the back-end data or service layer has been updated in accordance with the actions you performed on your Web Pages)
• Etc…

This is where soapUI comes in; all the above can easily be achieved with the corresponding web testing functionality in soapUI. Once you have your desired sequence of TestSteps set up in a soapUI TestCase you can use the soapUI Runner Component to run this as part of your loadUI test; just add a soapUI Runner Component to your loadUI scenario and configure it accordingly:

The soapUI Runner executes the entire sequence of steps in the contained soapUI TestCase every time it receives an incoming message (just like the Web Page Runner executes a single Web Page request) and can be “mixed into” your loadUI scenario just like we did with the Web Page Runner above, meaning:

• You can have multiple soapUI TestCases executing in parallel.
• You can have multiple soapUI TestCases executing after each other.
• Etc.

Of course you can mix the different runner components as required. In our above scenario we can add a third branch after the initial page that runs a single soapUI TestCase (which in turn contains a number of TestSteps):

As you can see we’ve added a Statistics component as well to see how the soapUI TestCase is performing (and all this was of course done while the loadUI test was running :-).

What is web load testing?

Web Load Testing involves checking how a website or service performs as the load on it (the number and volume of requests) is increased.

Why do web load testing?

A website needs to stay up under normal and expected load conditions, but in addition to that, the load will not remain constant, since there are several reasons why the number of requests might suddenly spike:

• Increased popularity of the website - This could happen very quickly, for example when a popular site links to yours (Digg and Slashdot effects). If your site is not able to cope with the sudden onrush of requests, it can render your site unusable.
• Denial of Service Attacks - This is what happens when somebody tries to bring down your site by making more requests than it can handle. The most common form is a Distributed denial of service attack, in which case numerous computers are used to make requests on the site at the same time.

Best practices

Here are some things to keep in mind when creating Web LoadTests:

• Test the most common behaviour that you expect from the users first.
• Test behaviours that you expect will cause high loads (e.g. Operations that involve a lot of database access might fall into this category).
• Spend at least some of the time doing exploratory testing.

For validation purposes, loadUI provides an Assertion component which can be found under Analasys category.

Once a component's output is connected to an Assertion component, a list of values that is available for validation is populated in the Assertion component so that a user can select the interested one. A maximum and minimum boundary must be set for the Assertion value so that all received values that are outside of these boundaries will be considered as invalid. This does not mean that every time a value is invalid a failure is raised. A failure depends on two additional parameters: Period and Tolerance.

For example, if a tolerance is 10 and period is 20 seconds then failure will be raised for every 10th invalid value which was received in last 20 seconds. Basically this means that you must have at least 10 invalid values and a period between the first and the last which must be less than or equal to 20 seconds to raise a failure. If a period is set to 0 (zero), then a failure is raised for every invalid value specified by a tolerance parameter disregarding the period e.g. when tolerance is 2 and period is 0, failure is raised for every second invalid value and when tolerance is 1 and period is 0 it is raised for every invalid value.

The total number of asserted values and raised failures are displayed on the component's display. Every failure increases a global failure counter. After a failure has been raised all previously buffered values are dismissed and counting is reset to zero. Tolerance and Period parameters can be set in the component's Settings dialog.

This is where a component can also be configured to raise a failure when a value is missing by setting the Fail on missing value property to true or when a sample ID does not match the specified one by setting the Fail on mismatching ID property to true.

loadUI can also be used as a Web Load Testing Tool. Writing a Web Load Test is very similar to writing any other Load Test, so before you start with this article, you may want to read Your First loadUI Project

The main difference between a Web Load Test and another Load Test is that a Web Load Test uses the Web Page Runner. The test will most likelly consist of a web page runner, a trigger and a statistics component, at least. We would also recommend adding some assertions to monitor the test behaviour better, and for better reporting.

loadUI as a Web Load Testing Tool

Web Load Testing Components

Depending on the amount of detail that you require, and on the configurations of the system being tested, the strucuture of your test can be very complex; using multiple triggers, runners and analysis components, as well as some of the components we have provided .

For a Web Page Load Test, we recommend starting with a FixedRate trigger to get some idea of how the system responds as you change the rate and use the data from that initial testing for more in-depth tests, perhaps using the variance trigger or the random trigger to better simulate the fact that people tend not to access the website at a steady rate.

For better results, distribute the tests across several agents, as detailed in the Distribution - Getting Started Tutorial

Web Testing depends on your setup, goals and needs. We hope that we have given you at least a starting point to build tests that will allow you to reach your goals.