Testing Web Pages

User rating:
4.1 (21 ratings)

The content on this page is related to a deprecated version of LoadUI, which has been superseded by LoadUI NG Pro in the Ready! API platform. Click here to learn more.

Try the full experience of Pro:

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.

1. 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.

2. 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:



2.1. 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.

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)

3. 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).

4. Checking Web Page Performance

The key component for checking the performance of a Web Page is the Statistics Tab which in combination with Assertions can continuously validate that the performance of your web pages are in line with the requirements.

5. 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 canvas 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 canvas 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):