Home
Rational® Performance Tester
Test Execution Specialist Guide
This guide describes tasks that you can perform on schedules, test execution with custom code, and Extending Rational® Performance Tester to support other protocols. This guide is intended for testers or test execution specialists.
Running schedules with performance testing
After you have added the user groups, tests, and other items to a schedule, and you are satisfied that it represents a realistic workload, you run the schedule.
Debugging HTTP tests
If a test does not behave as expected during playback, you can use the protocol data and test log to assist in debugging the test.
Replaying a virtual user after a run completes
After you create a schedule, run it with a small number of users and watch their activity to verify that the schedule is behaving as expected. You can compare the visual data that is rendered as well as the events that are logged for each user.

Rational® Performance Tester
- Release Notes
  This document contains information about what's new, installation instructions, known issues in IBM® Rational® Performance Tester and contact information of IBM Customer Support.
- System Requirements
  This document includes information about hardware and software requirements for IBM® Rational® Performance Tester.
- Getting Started
  This guide provides an overview and describes the task flows to get you to start with Rational® Performance Tester. This guide is intended for new users.
- Tutorials
  This section contains the tutorials which explains the main features of Rational® Performance Tester.
- Samples
  This section describes about the sample project which can be used with Rational® Performance Tester to test the functionality of an application.
- Administrator Guide
  This guide describes how to install Rational® Performance Tester. After you install the product, you can perform administration tasks such as license configuration and integration with other products. This guide is intended for administrators.
- Test Author Guide
  This guide describes how to create test scripts in Rational® Performance Tester and enhances tests by applying different test elements such as dataset, variables, and verification points. This guide is intended for testers.
- Test Execution Specialist Guide
  This guide describes tasks that you can perform on schedules, test execution with custom code, and Extending Rational® Performance Tester to support other protocols. This guide is intended for testers or test execution specialists.
  - Running schedules with performance testing
    After you have added the user groups, tests, and other items to a schedule, and you are satisfied that it represents a realistic workload, you run the schedule.
    - Running a local schedule or test
      You can run a test locally or a schedule, in this context, is used to refer to both VU Schedule and Rate Schedule on remote locations with a default launch configuration.
    - Running a long run mode SAP GUI test
      When running a SAP GUI test that could last for many hours and could use up the operating system resources, you can choose to run the test with the Long Run Mode process. It is an external process that restarts automatically after the specified number of SAP sessions are over. So, tests of longer duration tests are more likely to finish.
    - Running long duration Citrix tests
      When tests exceed many hours, resource consumption issues can cause problems for the Citrix clients. The long run mode increases the reliability of long duration tests with the Citrix protocol by running the test using multiple processes.
    - Testing with Docker images
      IBM® Rational® Performance Tester, IBM Rational Functional Tester, and IBM Rational Performance Tester Agents are available for download as Docker images. You can use them to fulfill the continuous testing aspects of your DevOps lifecycle.
    - Testing with IBM Cloud Private
      You can automate your testing environment by using Docker container images of the workbench and agents on top of IBM® Cloud Private.
    - Adjusting delays in HTTP tests
      You can configure HTTP tests to use client-side processing delays. Client-side processing delays wait for the first character or last character that is received in a response for a previous request in order to better emulate the work done on the client computer. You can also scale the recorded delays in HTTP tests to change the rate at which a test runs.
    - Setting a launch configuration
      Instead of using the default launch configuration, you can specify the file name for the execution results, the name of the folder for the execution results, and, for a test, the number of users.
    - Running a configured schedule
      If you do not use the default launch configuration, you can configure the schedule and then run it.
    - Configuring multiple host names for a location
      You can run several locations on the same computer by configuring multiple host names for a location. This configuration affects all tests running at that location; all tests will run with the configured port.
    - Automating tests from command line
      You can run a schedule from the command line. You can also set preferences to export results after the run completes from the command line or from the workbench. Together, these features let you run tests and analyze results without opening the workbench. You can even write scripts to process the exported results.
    - Controlling caches size
      If you use an infinite loop and the number of cached responses in a test increases exponentially, you can set a limit to cache for a user group in the schedule.
    - Increasing memory allocation
      The virtual users that access your web server require memory to prepare requests, send requests, and receive responses. Because the amount of memory is not automatically set on remote computers, you might receive an out-of-memory error. To correct this situation, increase the memory allocation for that computer.
    - Controlling execution of web analytic reports
      When a schedule is in the running state, you can perform the following actions from the web analytics reports to cater to your need.
    - Debugging HTTP tests
      If a test does not behave as expected during playback, you can use the protocol data and test log to assist in debugging the test.
      - HTTP debugging overview
        If a test is not behaving as expected, you can use the Protocol Data view to debug the test. This view can be useful after you record a test, after you make changes to an existing test by adding datasets or data correlation, or after you make changes to the system under test.
      - Debugging HTTP Data Correlation Errors
        Data correlation errors are very common and sometimes complex to fix. A dedicated Eclipse-based perspective can guide you to debug data correlation errors.
      - Watching a virtual user during a test run
        The Browser page in the Protocol Data view displays browser results during an individual HTTP test run. The Browser page displays each page in real time.
      - Watching a virtual user during a schedule run
        During a schedule run, you can select any virtual user and watch that user's real-time browser. Watching the real-time browser lets you investigate the status of individual virtual users while they are running. You can determine whether a run is valid despite the occurrence of individual virtual user failures.
      - Replaying a virtual user after a run completes
        After you create a schedule, run it with a small number of users and watch their activity to verify that the schedule is behaving as expected. You can compare the visual data that is rendered as well as the events that are logged for each user.
      - Viewing the playback summary of a virtual user
        The Event Log page in the Protocol Data view provides a summary of what happened during an HTTP test run. A complete summary is always available for a test. The information available for a schedule depends on its logging level.
      - Inspecting HTTP test logs in the Protocol Data view
        To verify that a test is performing as you intend, use the Protocol Data view, which displays the HTML details that were generated during a schedule run. If problems occur in a test run, you can also compare the data retrieved during the run with the recorded data.
      - Managing HTTP information in the Protocol Data view
        Several actions can be performed on the text displayed in the Protocol Data view. You can save the text from the Protocol Data view pages to a text file for use in other applications. You can search for text in the protocol data. You can compare the data retrieved during a run with the recorded data from an HTTP test. Typically, you compare a request or response from the test log to its corresponding data in the recorded test. You can also compare requests or responses from different virtual users in one test log.
    - Debugging Citrix tests
      The Citrix dashboard is an optional panel that displays detailed information and control commands for each virtual user during the run of a schedule. This is useful for debugging your tests and allows you to pause, interact, resume, or stop the execution of individual virtual user sessions.
  - Extending test execution with custom code
    You can extend how you run your tests by writing custom Java™ code and calling the code from the test. You can also specify that results from the tests that are affected by your custom code be included in reports.
  - Extending Rational® Performance Tester to support other protocols
    The Rational® Performance Tester Extensibility Software Development Kit (SDK) enables you to create extensions to support testing new protocols without modifying the core product code. You can create an extension that provides functionality for testing other protocols in addition to the HTTP protocol support that is standard in Rational Performance Tester.
- Test Manager Guide
  This guide describes how to keep track of the performance of the application by evaluating the test results. This guide is intended for test managers.
- Troubleshooting Guide
  This guide describes how to analyze and resolve some of the common problems that you might encounter while you work with Rational® Performance Tester.
- Reference Guide
  This guide describes, additional topics to gain more knowledge about Rational® Performance Tester.
- All Guides (PDFs)
  You can find the link to view or download the content of the release notes, system requirements, and persona guides of Rational® Performance Tester as a PDF file.
- Security Considerations
  You can take certain actions to ensure that your installation is secure, customize your security settings, and set up user access controls.
- Notices
  This document provides information about copyright, trademarks, terms and conditions for the product documentation.

Replaying a virtual user after a run completes

After you create a schedule, run it with a small number of users and watch their activity to verify that the schedule is behaving as expected. You can compare the visual data that is rendered as well as the events that are logged for each user.

Procedure

Open the schedule, click the Test Log tab, and set each Log Level to All.
This setting makes sure that the virtual user that you select will have complete test log data.
Verify that the schedule contains a small number of virtual users.
1. Open the schedule, click the User Load tab and set a small number of users.
  Setting a small number of users prevents the log from becoming unwieldy, which can occur when the log level is All.
2. If you are running a fixed number of users, select each user group and set the numbers so that the total is equal to that in the User Load tab.
Save the schedule and click Run to run the schedule with the limited number of users.
After the schedule completes, open the test log: Right-click the schedule run, and select Display test log.
In the test log, click the Events tab, expand the test log to display the virtual users, and select a virtual user to watch.
In the Protocol Data view, click Replay ().
The virtual user's pages, which were loaded during the run, are redisplayed. Each page pauses the number of seconds that you set in the Replay Delay preference (Window > Preferences > Test > HTTP Protocol Data View).
To stop replaying, click Stop Replay ().