Browse Prior Art Database

System and method for Web 2.0 applications load testing automation Disclosure Number: IPCOM000212055D
Publication Date: 2011-Oct-27
Document File: 3 page(s) / 32K

Publishing Venue

The Prior Art Database


Disclosed is a system for Web User Interface (UI) load test automation that maximizes the number of concurrently simulated HTTP clients and minimizes the manual effort involved in test construction and maintenance.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 3

System and method for Web 2.0 applications load testing automation

Existing web UI test tools are based on two different solutions/approaches:

A) "record & playback" (manual record with a browser, automated playback without a browser, using a simpler client that sends HTTP requests and receives HTTP responses). This is the most widespread trend in load testing tools such as IBM Rational Performance Tester or HP LoadRunner.

B) "Record-less", using a "scriptable" browser: an HTTP client that can be programmed to generate HTTP requests. This approach is used for existing functional testing tools, some of them being able to work in "record & playback" mode.

Both approaches have drawbacks, especially "record & playback":

it is generally recognized that "recording is the least cost-effective way of

automating web testing " . The main reason is that very often even a small UI change may require re-recording all/most tests, a manual activity that can take considerable time;

Javascript generated dynamic content and asynchronous behaviors are not

handled well (or at all);

very often lots of manual correlations between requests and responses are needed to make the playback work, with related high automation costs.

For the "record-less" approach the main drawback is that only a limited number of simulated clients can be run on a single box either because the tool allows only a single browser instance running on each box (if interacts with the browser taking the control of the input devices as RFT does) or because a browser with a Javascript engine needs more hardware resources than a simple HTTP client, limiting the number of clients that can be run at the same time on a given hardware.


The proposed new solution is based on a hybrid/combined approach between the two described above. It basically comprises two phases:

1. A "training" phase using a Javascript enabled client and adopting a "record- less" approach.

This phase consists in executing several times, using different users, the same test with the purpose of identifying the actual correlations between responses and requests. This will replace the manual recording phase and is able to provide a better correlation because it analyzes a larger amount of data than with the single-user single-run of the "record & playback" approach.

2. An actual simulation phase, consisting of an arbitrary amount of simulated clients that will playback what has been recorded in the training phase. In this phase a simple HTTP client will be used like in the "record & playback" approach but it will exploit the better data correlation coming from the previous phase.

The flow of activities to implement this solution starts with the definition of test steps


Page 02 of 3

in a high-level scripting/markup language, with simple actions/statements such as:

goto URL

enter text in text-box labeled T1

click button with label B1

and so on...

After the test is defined (this is the on...