StressTester™ Screenshots

The StressTester™ GUI is designed to be easy to use without the need for extensive training or practise. The GUI consists of four clearly defined workspaces – one for the creation of User Journeys (simulated business transactions), another for specifying the underlying resources to monitor, a third for specifying the tests to be executed and a final one for analyzing the results of a test.

Throughout StressTester™, information pages guide you as to what you need to do to ensure your test is correct and realistic.

Help is available at any time by simply pressing the “Help” on the far right of the GUI toolbar.

Simply click the “Record” button, enter details of the User Journey and, if needed, of the proxy and/or client certificate security settings required to access the application.

Main User Journey details include sleep time variations and pacing, logging and protocol specific controls.

User Journey step details are easily configured by clicking on the required node in the tree – including adding data parameters, specifying success validation, and configuring alternate flows.

Dynamic Data is easily configured within a step by replacing the recorded value with the parameter identifier. Parameters can occur within the request, POST data, and success string.

Dynamic Data is configured via the User Journey tree – selecting a node displays the corresponding Dynamic Data item.

Auto-Correlated Dynamic Data allows StressTester™ to automatically handle all session identifiers (including Java’s jsessionid and .NET’s __VIEWSTATE) as well as application specific repeated fields.

Auto-Increment Dynamic Data allows you to create incrementing/decrementing values which can have a suffix and/or prefix and/or be padded to a certain length. Ideal for generating test data such as email addresses, phone numbers, etc.

Constant Dynamic Data allows a constant to be easily changed and affect the whole of the User Journey – typical uses are the host name of the application, date of the batch run, etc.

Delimited File Dynamic Data allows the data in any file to be mapped to one or (by using the Related type) more Dynamic Data Items.

Java Class Dynamic Data allows any Java (and hence .Net, C, C++, PHP, Perl) code to be called to provide the values for a Dynamic Data item.

Response Dynamic Data is used to mine the response of a previous step in the User Journey for values. Very powerful, can be used to retrieve one or two-dimensional data sets – all without writing a line of script code.

Flow Control can be implemented on any step required – allowing the tester to create User Journeys that realistically simulate the behaviour of users, or to be more precise, the behaviour of many users that may not all do the same thing or the same thing each time they execute the transaction.

Go To Flow Control allows the User Journey to jump to another step.

Fixed Loop Flow Control allows the User Journey to loop back to a step a set number of times.

Variable Loop Flow Control allows the looping to occur a random number of times between the two specified values. For example, adding a random number of items to a shopping cart is simply configured.

Percentage Based Flow Control allows the simulated users to go to different next steps based on a percentage weighing. For example, a certain percent of shoppers can use the slow purchase route, whilst another percentage can use a one-click route, and finally another percentage use an online payment facility.

Response Based Flow Control allows the next step to be executed to be determined by the response of the current or a previous step. Therefore, responding to the application informing the user there are no search results, there is a priority work flow item, or any other situation where a real world user would react to a server response is easily configured.

Dynamic Data Flow Control allows the User Journey to loop until a finite value set Dynamic Data item is exhausted; each loop uses another value from the value set. For example, simulating a user reading all their new emails or a task based worker iterating through their task list can be easily configured.

A key enhancement for StressTester™ 6 was a completely new approach to monitoring underlying system resources - and therefore allowing you to determine the causes for poor performance and scalability. StressTester™ is shipped with a number of Monitor Packs - collections of Resource Monitors for a particular infrastructure component.

Resource Monitors can be easily configured to be specific for your environment. For example, configuring a Resource Monitor to inspect a database you have created.

The Resource Monitors to execute during a test are easily selected and placed within a Monitor Set.

Monitor Sets can be reused to monitor as many instances of the infrastructure component as you wish - the Monitoring Configuration specifies how StressTester™ connects to the component.

Injectors simulate users accessing the system under test and can be situated anywhere in the World. StressTester™ is designed from first principles for load to be simulated from the locations where the real world users will reside.

You simply specify the User Journeys to run in each location (Injector), the ramp profile - very fine level granularity - and the system resources (Resource Monitors) to measure during the test.

Executing a performance test is just a case of clicking the Execute button, choosing a test run configuration, giving the test a name and clicking Start Test.

StressTester™'s Analysis screen allows real-time during test execution analysis of performance, throughput and Resource Monitor data, or historical analysis of completed tests.

A full graphing engine allows complete configuration of the graphs - type, colour, data to be displayed, ranges, orientation and much more.

Many different views of the data collected can be shown at once - completely customizable by yourself. Information can be analyzed at all business transaction (User Journey) level, or individual transaction level (drill-down on one specific Journey).

When performance problems occur, StressTester™ will automatically detect the Resource Monitors that have exceeded the configured thresholds - immediately identifying the areas of the system under test that are struggling with the load.

Resource Monitor information can be displayed alongside response times - it can be clearly seen in this graph that the problem is to do with overall CPU exhaustion, caused by the JVM utilising excessive CPU, which in turn is caused by growing number of JVM Garbage Collections.