Overview - Rational Performance Tester v8.5

Rational Performance Tester v8.5 - Overview

Introduction

Rational Performance Tester
HTTP testing
SAP testing
Citrix testing
Service testing
Socket API testing
TN3270 testing

Get started
Streamlined vs full Eclipse

Overview

IBM Rational Performance Tester automates load generation for web, ERP, and server-based software applications, and provides reporting to identify system bottlenecks. RPT captures network traffic rendered for the following protocols...

HTTP
SAP (GUI)
Citrix
Socket
TN3270
Service (SOA)

RPT generates tests out of recordings. Tests can be edited, adding dynamic data and verification points. We emulate workloads by adding virtual users using the schedule editor. On a typical retail web site, 80% of the user traffic are browsers and 20% are buyers. RPT Agent is installed to capture data, and is connected with the workbench. Data collection is supported on IBM WebSphere Application Server and Oracle WebLogic Application Server. You can import data from IBM Tivoli Composite Application Manager. You can integrate RPT with IBM Rational Quality Manager and IBM Rational Team Concert.

HTTP performance testing

There are five stages when performance testing HTTP applications:

test creation
test editing
workload emulation with schedules
schedule execution
evaluation of results

Test creation We generally create HTTP performance tests by recording interactions with an application.
Test editing After recording a test, run it and inspect the results. Replace a value in a recorded test with values in a datapool, add dynamic data (data correlation), and enable verification points.

Workload emulation with schedules
A typical schedule contains user groups and tests, user groups running from a remote location, and optional schedule items, such as loops, delays, and think time behavior settings, to further emulate a load.
Schedule execution

Evaluation of results We can regenerate reports after the run, customize reports, and export reports in HTML format.

SAP performance testing

Use IBM RPT Extension for SAP Solutions allows you to test the performance of SAP R/3 applications.

Test creation Record tests with the SAP GUI client, which logs on to the SAP R/3 server and interacts with the application. The recorded session is split into transactions and SAP screens. Response time measurements and verification points are automatically added to transactions and SAP screens.
Test editing You can edit events in each transaction and SAP screen. The SAP Protocol Data view provides snapshots of the SAP screen to edit the events, allowing you to replace recorded test values with variable test data, or add dynamic data to SAP tests. You can set verification points on field values or window titles.
Test validation Run tests manually as a single virtual user.

Workload emulation with schedules
Add SAP batch input tests to the schedule to simulate a heavy load on the servers while minimizing virtual tester resources.
Schedule execution Run the schedule, deploy test execution over virtual users hosted on remote hosts. Each virtual user runs an instance of the SAP GUI client. Response time results are provided by the SAP R/3 server and recorded. Verification points are checked and results are recorded.
Evaluation of results Evaluate the results produced by the SAP performance tests through the various reports that are generated during execution.

Citrix performance testing

IBM RPT Extension for Citrix Presentation Server allows you to test the performance of Citrix applications.

Test creation Create tests by recording a session with the Citrix XenApp client. Typically, the recorded session starts when you log in to the Citrix server. Interact with the application to produce a relevant performance test. The session ends when you log out. The recording is split into window events and contains keyboard and mouse interactions with the Citrix server. Use the Citrix Recording Control window to add screen captures or comments. Add image synchronizations to help the test remain synchronized with the server.
Test editing After recording, edit the events in each window element. Because the recorded input is primarily made of low-level keyboard and mouse input, you can streamline the test by, for example, replacing key-press events with string inputs. Use the comments and recorded screen captures to make navigating through the test easier. Replace recorded test values with variable test data, or add dynamic data to the test. Set verification points on window titles or image synchronizations to validate that the application behaves as expected.
Test validation Before deploying, run the test manually as a single virtual user to verify the test synchronizes user input actions and server output correctly in a nominal environment with minimal server load.

Workload emulation with schedules
When the test runs repeatedly as anticipated, specify an execution schedule and user groups to emulate a workload generated by a large number of virtual users.
Schedule execution Deploy test execution over virtual users that can be hosted on remote hosts. Each virtual user runs an instance of the Citrix client.
Evaluation of results Evaluate the results produced by the tests through the various reports that are generated during execution. Design custom reports.

Before testing the performance of Citrix applications, a Citrix XenApp client must be installed on the same computer as IBM RPT. The Citrix XenApp client is required for recording and execution of performance tests.
If you are deploying tests over remote computers to emulate a large number of users, the following software must be installed on each remote computer:

The Citrix XenApp client
The IBM RPT Agent

Citrix performance tests use window creation and change events, and optionally image recognition techniques, to synchronize user input with server output. Before you record a session with a Citrix application, the behavior of that application must be perfectly reproducible. Specifically, the application must always create windows and GUI elements at the same locations and in the same sequence. Mouse or keyboard events must always produce the same output. Consider these examples:

If the application displays windows or dialog boxes on only the first execution of a particular program or feature, such as tips or security warnings, ensure that they are disabled when you record the test. Any windows or dialog boxes that were recorded but are not displayed on subsequent executions, or displayed at different coordinates on the screen, will fail the test and cause synchronization timeouts.
If you save a file during a recorded session, the application might issue a warning for an existing filename when you replay the tests. If the warning was not in the recorded session, this will fail the test and cause errors.

It is essential to be aware of the context of user actions when you edit a test. Because the Citrix performance tests interact with the Citrix XenApp client at a very low level (mouse movements and key presses) any changes that you make to the test after the recording, such as moving test elements, adding loops or conditions, or inserting new sequences, can alter the context of the emulated user actions and cause synchronization timeouts.

Service testing

The service testing capabilities of IBM RPT or IBM Rational Service Tester for SOA Quality automate the creation, execution and analysis of functional, regression and performance tests for SOAP-based web services, including support for Java Messagine Service (JMS), Websphere MQ, and Microsoft .NET Windows Communication Foundation (WCF), as well as any service that produces XML, plain text, or binary data.

Preparation Set up the test environment with the libraries and configuration files required for SOAP-based web services or custom security algorithms. Import WSDL definition files and digital certificates required by the web services to automatically generate the tests. Create SOAP security profiles with security algorithms for the web service calls and message returns.
Test creation Record the service requests and responses either with the generic service client, or with an existing client or a web browser through a recording proxy. When you start the recording, you interact with the service by performing service requests and receiving responses. Create service tests manually or from a synchronous BPEL model.
Test editing After recording, edit the requests and responses in the test. Use XSD documents to facilitate XML edition. Replace recorded test values with variable test data, or add dynamic data to the test.
Functional testing Run the test to ensure that service matches the expected behavior defined in verification points. During the run, each verification point is checked and receives a pass, fail or inconclusive status.
Performance testing Specify an execution schedule and user groups to emulate a workload generated by a large number of virtual users. Then, run the schedule, deploying test execution on virtual users that can be hosted on remote computers. Each virtual user runs an instance of the test client. Response times are measured and recorded. Verification points are checked and recorded.
Stub simulation Service stubs are functional simulations of an existing service. Service stubs are useful for replacing a service that is unavailable or impractical to use in a test environment. They can also be used to input specific data into a service under test or for prototyping. Deploy stubs onto a stub server, which can replace the actual server in your test or development environment.
Evaluation of results Evaluate results using performance and verification point reports that are generated during execution. Design custom reports by manipulating various counters. Functional reports provide a comprehensive view of the behavior of the service under test. Reports can be exported and archived for validation.

Service testing tools

Use the generic service client to manually perform service requests for a variety of transport protocols, authentication configurations and security profiles. It effectively replaces a dedicated client and can be used to record service calls or for manual testing and debugging a service during development. To open the generic service client, click the Generic Service Client toolbar button.
The WSDL security editor allows you to set up algorithm stacks that contain digital certificate information and the security algorithms applied to messages to perform secure communication with a web service. Algorithm stacks are made of blocks, which can be key definitions, encryption , time stamp, or signature operations which can be associated with any operation in the WSDL file. To open the WSDL security editor, right-click a WSDL file in your workspace and select Edit WSDL Security or click the WSDL Security Editor button in the generic service client..
After recording, use the test editor to add data correlation, verification points, loops and conditions.
Use the stub editor to create service stubs. With the stub editor, you can define multiple input conditions, which are similar to verification points. Each condition triggers a predefined simulated response, which is functionally identical to a response from the simulated service.
In RPT, the schedule editor lets you deploy multiple virtual users on local and remote computers to generate a heavy load for performance testing. A schedule typically contains multiple tests and multiple virtual users.

Socket API performance testing

With IBM RPT Extension for Socket Protocols, you can test the performance of any application that uses a TCP/IP socket-based protocol.

Test creation Create tests by recording a session with a client application. Typically, the recorded session starts when you run the client application. Interact with the application to produce relevant network traffic. The session ends when you close the application or end the recording. The recording is used to generate a performance test that reproduces the behavior of the client application.
Test editing Edit recorded events. Replace recorded test values with variable test data or add dynamic data to the test.
Test validation Before deploying, run the test manually as a single virtual user to verify the test runs smoothly and produces the expected results in a nominal environment with minimal server load.

Workload emulation with schedules
When the test runs repeatedly as anticipated, specify an execution schedule and user groups to emulate a workload that a large number of virtual users generates.
Schedule execution Run the schedule, deploying test execution over virtual users that can be hosted on remote hosts. Each virtual user runs an instance of the test. Response time results are collected.
Evaluation of results Evaluate the results using the reports generated during schedule execution.

TN3270 performance testing

With IBM RPT Extension for Socket Protocols, you can test the performance of TN3270 terminal server applications.

Test creation Create a test by recording a session with a client application. Typically, the recorded session starts when you run the TN3270 terminal client. Interact with the application to produce relevant network traffic. The session ends when you close the terminal client or end the recording. The recording is used to generate a performance test that reproduces the behavior of the client application.
Test editing After recording, edit the recorded events. Replace recorded test values with variable test data or add dynamic data to the test.
Test validation Before deploying, run the test manually as a single virtual user to verify the test runs smoothly and produces the expected results in a nominal environment with minimal server load.

Workload emulation with schedules
When the test runs repeatedly as anticipated, specify an execution schedule and user groups to emulate a workload that a large number of virtual users generates.
Schedule execution Run the schedule, deploying test execution over virtual users that can be hosted on remote hosts. Each virtual user runs an instance of the test. Response time results are collected.
Evaluation of results Evaluate the results that the tests produce through the various reports that are generated during execution.

Get started

To get started...

Record a test.
Create datapools to supply variable data to tests.
Adjust data correlation.
Create a schedule to model workloads by adding user groups and stages.
Generate and customize reports.

Streamlined Eclipse and full Eclipse

With streamlined Eclipse mode, only those functions that are directly related to RPT are enabled in the workbench. When you install RPT, by default, the check box to use the streamlined Eclipse mode is selected. With the full Eclipse mode, you have access to all Eclipse functions. If you start the product in the streamlined mode you can close the workbench and restart it in the full Eclipse mode.
To start the workbench for IBM Rational Performance Tester or IBM Rational Service Tester for SOA Quality in the full Eclipse mode.

Click either...
Start | Programs | IBM Software Delivery Platform | IBM RPT | IBM RPT - Full Eclipse

...or...
Start | Programs | IBM Software Delivery Platform | IBM Rational Service Tester | IBM Rational Service Tester - Full Eclipse

If this is your first time starting this installation of RPT or Rational Service Tester, you will be prompted to select a working directory.

Type the path of the working directory in the Workspace field or click Browse to select the directory.
Select Use this as the default and do not ask again to make this your default workspace. To change the workspace File > Switch Workspace.

Click OK.

In order to start the workbench in the streamlined mode, the streamlined mode must be installed as an optional feature. It is automatically selected during the installation process.

Click...
Start | Programs | IBM Software Delivery Platform | IBM RPT | IBM RPT

...or...
Start | Programs | IBM Software Delivery Platform | IBM Rational Service Tester | IBM Rational Service Tester

If this is your first time starting this installation of RPT or Rational Service Tester, you will be prompted to select a working directory.

Type the path of the working directory in the Workspace field or click Browse to select the directory.
Select Use this as the default and do not ask again to make this your default workspace. To change the workspace...
File | Switch Workspace

Click OK.

See also

Information Centers and Libraries for IBM software by brand
Other versions of this information center
Rational Software RFE Community
Rational Top 10 FAQ
RPT Support
RPT Wiki
developerWorks
Rational training and certification
Information quality survey
Software consumability survey

Test creation	We generally create HTTP performance tests by recording interactions with an application.
Test editing	After recording a test, run it and inspect the results. Replace a value in a recorded test with values in a datapool, add dynamic data (data correlation), and enable verification points.
Workload emulation with schedules	A typical schedule contains user groups and tests, user groups running from a remote location, and optional schedule items, such as loops, delays, and think time behavior settings, to further emulate a load.
Schedule execution
Evaluation of results	We can regenerate reports after the run, customize reports, and export reports in HTML format.

Test creation	Record tests with the SAP GUI client, which logs on to the SAP R/3 server and interacts with the application. The recorded session is split into transactions and SAP screens. Response time measurements and verification points are automatically added to transactions and SAP screens.
Test editing	You can edit events in each transaction and SAP screen. The SAP Protocol Data view provides snapshots of the SAP screen to edit the events, allowing you to replace recorded test values with variable test data, or add dynamic data to SAP tests. You can set verification points on field values or window titles.
Test validation	Run tests manually as a single virtual user.
Workload emulation with schedules	Add SAP batch input tests to the schedule to simulate a heavy load on the servers while minimizing virtual tester resources.
Schedule execution	Run the schedule, deploy test execution over virtual users hosted on remote hosts. Each virtual user runs an instance of the SAP GUI client. Response time results are provided by the SAP R/3 server and recorded. Verification points are checked and results are recorded.
Evaluation of results	Evaluate the results produced by the SAP performance tests through the various reports that are generated during execution.

Test creation	Create tests by recording a session with the Citrix XenApp client. Typically, the recorded session starts when you log in to the Citrix server. Interact with the application to produce a relevant performance test. The session ends when you log out. The recording is split into window events and contains keyboard and mouse interactions with the Citrix server. Use the Citrix Recording Control window to add screen captures or comments. Add image synchronizations to help the test remain synchronized with the server.
Test editing	After recording, edit the events in each window element. Because the recorded input is primarily made of low-level keyboard and mouse input, you can streamline the test by, for example, replacing key-press events with string inputs. Use the comments and recorded screen captures to make navigating through the test easier. Replace recorded test values with variable test data, or add dynamic data to the test. Set verification points on window titles or image synchronizations to validate that the application behaves as expected.
Test validation	Before deploying, run the test manually as a single virtual user to verify the test synchronizes user input actions and server output correctly in a nominal environment with minimal server load.
Workload emulation with schedules	When the test runs repeatedly as anticipated, specify an execution schedule and user groups to emulate a workload generated by a large number of virtual users.
Schedule execution	Deploy test execution over virtual users that can be hosted on remote hosts. Each virtual user runs an instance of the Citrix client.
Evaluation of results	Evaluate the results produced by the tests through the various reports that are generated during execution. Design custom reports.

Preparation	Set up the test environment with the libraries and configuration files required for SOAP-based web services or custom security algorithms. Import WSDL definition files and digital certificates required by the web services to automatically generate the tests. Create SOAP security profiles with security algorithms for the web service calls and message returns.
Test creation	Record the service requests and responses either with the generic service client, or with an existing client or a web browser through a recording proxy. When you start the recording, you interact with the service by performing service requests and receiving responses. Create service tests manually or from a synchronous BPEL model.
Test editing	After recording, edit the requests and responses in the test. Use XSD documents to facilitate XML edition. Replace recorded test values with variable test data, or add dynamic data to the test.
Functional testing	Run the test to ensure that service matches the expected behavior defined in verification points. During the run, each verification point is checked and receives a pass, fail or inconclusive status.
Performance testing	Specify an execution schedule and user groups to emulate a workload generated by a large number of virtual users. Then, run the schedule, deploying test execution on virtual users that can be hosted on remote computers. Each virtual user runs an instance of the test client. Response times are measured and recorded. Verification points are checked and recorded.
Stub simulation	Service stubs are functional simulations of an existing service. Service stubs are useful for replacing a service that is unavailable or impractical to use in a test environment. They can also be used to input specific data into a service under test or for prototyping. Deploy stubs onto a stub server, which can replace the actual server in your test or development environment.
Evaluation of results	Evaluate results using performance and verification point reports that are generated during execution. Design custom reports by manipulating various counters. Functional reports provide a comprehensive view of the behavior of the service under test. Reports can be exported and archived for validation.

Test creation	Create a test by recording a session with a client application. Typically, the recorded session starts when you run the TN3270 terminal client. Interact with the application to produce relevant network traffic. The session ends when you close the terminal client or end the recording. The recording is used to generate a performance test that reproduces the behavior of the client application.
Test editing	After recording, edit the recorded events. Replace recorded test values with variable test data or add dynamic data to the test.
Test validation	Before deploying, run the test manually as a single virtual user to verify the test runs smoothly and produces the expected results in a nominal environment with minimal server load.
Workload emulation with schedules	When the test runs repeatedly as anticipated, specify an execution schedule and user groups to emulate a workload that a large number of virtual users generates.
Schedule execution	Run the schedule, deploying test execution over virtual users that can be hosted on remote hosts. Each virtual user runs an instance of the test. Response time results are collected.
Evaluation of results	Evaluate the results that the tests produce through the various reports that are generated during execution.