Rational Performance Tester


Rational Performance Tester is a tool for automated performance testing of web- and server-based applications from the Rational Software division of IBM. It allows users to create tests that mimic user transactions between an application client and server. During test execution, these transactions are replicated in parallel to simulate a large transaction load on the server. Server response time measurements are collected to identify the presence and cause of any potential application bottlenecks. It is primarily used by Software Quality Assurance teams to perform automated software performance testing.

Overview

Rational Performance Tester is a performance test automation tool used to measure web and server-based application scalability. Using RPT, quality assurance teams can subject a web application or server to a large volume of transactions for the purpose of measuring the server response times. Lengthy response times are considered application bottlenecks, and information regarding these bottlenecks is typically passed along to application developers to correct, in an effort to decrease system response time. RPT is an Eclipse based performance test tool.

Performance test creation process

The following is an overview of the process of system performance validation with RPT.

Test creation

Tests are created using the RPT recording mechanism. The RPT recorder captures all transactions between application client and an application server. The resulting test is displayed as a tree view, where each branch of the tree represents a browser or client request and response.

Test editing

RPT tests are not represented as code. RPT tests are represented as a tree view, where each branch of the tree represents a browser or client request and response. To edit the test, the user selects menu options which allow for insertion of loops, "if-then" type decision structures, and response verification. Should a custom coding solution be required, users can insert Java code modules to perform complex computations.
RPT performs automatic test editing for data pooling and data correlation. With datapooling, RPT automatically edits tests to separate test data from the test actions. Test data, such as a user login ID and password values that were typed in by the user during the test, are stored in a spreadsheet like datapool. The test is crafted in such a way so that during test playback, each simulated user will access one row of the test data from the datapool. This ensures that each unique user uses unique data during playback, and prevents a situation where, for example, 100 simulated users attempt to log in with a single user ID and password.
Data correlation is the process by which RPT ensures continuity between test actions. Often in a performance test a value is created at one step of a test and subsequently used during a later step. Whenever such a value is created, RPT stores that value in a variable, and uses that variable later on the test when the data is accessed. This prevents hard coding of values, and ensures that tests will play back correctly in dynamic data environments.

Test scheduling

RPT can execute a single test, or it can create a suite of tests for playback. When creating a suite of tests, users drag and drop tests onto a schedule to simulate a given sequence of events. Tests can be grouped by user profile, to represent the activities of different types of users on a system. The volume of transactions can be set to increase at defined intervals to increase load during a test, in an effort to identify system bottlenecks.

Test reporting

RPT offers a variety of reports to identify the presence and cause of system performance bottlenecks. There are reports that measure accuracy of system response which ensure that the system did not error out or crash during a test. There are reports to measure system performance metrics such as disk, network and CPU utilization, to identify the presence of hardware bottlenecks. To identify software related bottlenecks, there are reports to measure load, throughput and response times. For Java EE environments, when a bottleneck is identified, users can drill down on the performance reports to identify the cause of the bottleneck, identifying slow performance classes, methods and individual lines of application source code.

Release history

The following is a release history of RPT.
The primary criticism of performance test automation tools such as RPT is that they can only find the performance bottlenecks that they are programmed to find. If a system performance bottleneck exists in an untested area of the system, RPT will not find the issue, and the system can go live without anyone's knowledge of the defect. Once the problem surfaces in a deployed system, organizations will experience all the related challenges of discovering and resolving a performance issue in production.