Home
Rational® Performance Tester
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.
Emulating workloads
You emulate a workload by creating a schedule and adding user groups/rate runner groups, tests, and other elements to it.
Creating a VU Schedule
You can create a VU Schedule to accurately emulate the actions of individual users.
User group overview
User groups enable you to group tests in a logical order.

Rational® Performance Tester
- Release Notes
  This document contains information about what's new, installation instructions, known problems 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 started 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 software, 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.
  - Creating tests
    To create a test, you record representative interactions with an application.
  - Editing tests
    After you record a test, you can edit it to include datasets (to provide variable data rather than the data that you recorded), verification points (to confirm that the test runs as expected), and data correlation (to ensure that returned data is appropriate for the corresponding request). You can also add protocol-specific elements to a test. When you edit a test, the modified items appear in italic type. The italic type changes to regular type after you save the test.
  - Compound tests
    You can create compound tests to help you organize smaller tests into scenarios that can then be run end-to-end. You can combine tests from different extensions to achieve end-to-end flow.
  - Simulating services with stubs
    Service stubs enable you to simulate the behavior of an actual service for a wide variety testing or integration purposes.
  - Sending service requests with the generic service client
    The generic service client enables you to send requests to services for which you do not have a convenient client and to view the responses returned by the service.
  - Emulating workloads
    You emulate a workload by creating a schedule and adding user groups/rate runner groups, tests, and other elements to it.
    - Schedule overview
      A schedule is the "engine" that runs a test. However, schedules are much more than simple vehicles for running tests. You can design or emulate the real-life workload by creating various groups and dividing the load across different remote agents that generate load on the application under test. A schedule can be as simple as one virtual user or one iteration running one test, or as complicated as hundreds of virtual users or iteration rates in different groups, each running different tests at different times.
    - Creating a VU Schedule
      You can create a VU Schedule to accurately emulate the actions of individual users.
      - Setting the user load
        By setting stages, you can model workloads over time and change the number of users that perform certain tasks to reflect real-world usage. You can vary the user load and collect performance metrics for each stage independently, which means that a single run can more efficiently accomplish the work of multiple runs that require shutting down and restarting users. Each stage, which lasts a specific amount of time and contains a specific number of users, defines a different load.
      - User group overview
        User groups enable you to group tests in a logical order.
      - Adding a user group to VU Schedule
        By defining user groups, you can group related tests and run the tests in parallel. Tests belonging to different user groups run in parallel.
      - Adjusting user groups
        You can adjust multiple user groups simultaneously to distribute a load across groups and to set the groups to run on the workbench computer. Typically, when you run VU Schedule, user groups run on remote agent computers, not on the local workbench computer.
      - Emulating slower network traffic (HTTP)
        You can emulate various WAN connection speeds used for HTTP traffic to determine its effect on response times and throughput.
      - Running a user group at a remote location
        You can run a user group at a remote location (also called an agent computer), rather than on your local computer, to prevent your workbench activity from affecting the ability to apply load.
      - Delaying virtual users or actions
        By adding a delay to a schedule or a compound test, you can emulate user actions more accurately.
      - Synchronizing users
        Inserting a synchronization point enables you to coordinate the activities of a number of virtual users by pausing and resuming activities. You can synchronize all virtual users at the beginning of a schedule and stagger the release times so that the users do not overload the system. Synchronization points are also useful in stress testing.
    - Creating a Rate Schedule
      By creating a Rate Schedule, you can model the different behaviors of how the application is accessed and measure the rate accuracy.
    - Using Application Performance Management in a schedule
      You can use Application Performance Management (APM) in a schedule to enable Dynatrace application and enhance the data collection during load testing by adding HTTP headers to the request in your HTTP tests. You can also use APM to monitor the performance of applications.
    - Think time overview
      Think time is a delay in the processing of a request to reproduce the time that a human would take to read or examine the data that is displayed from a previous user action. Think time is calculated from the time that a request is received (that is, the display is complete on the monitor) until the time that the user clicks a key or link to perform an action.
    - Working with agents
      If you have a significant workload to test, typically a single computer might not be able to process the load efficiently. You need to distribute the load across multiple computers, also called Rational® Performance Tester agents. The agents are installed on computers to generate the load on the application.
    - Adding a test to a schedule
      By adding a test to a A schedule, in this context, is used to refer to both VU Schedule and Rate Schedule, you can emulate the action of an individual user.
    - Adding must run tests
      In a schedule, you can use the Finally block to specify tests that must be run after the main workload is completed, when the last stage duration is expired, or a schedule is stopped manually.
    - Assigning variables
      In addition to assigning variables at the test level, you can assign variables at the A schedule, in this context, is used to refer to both VU Schedule and Rate Schedule level and User or Rate Runner group level. When you assign variables at the schedule level, all the tests and groups in the schedule can use the variable initial values, if they have the same variable names.
    - Defining performance requirements in schedules
      You can define performance requirements to specify the acceptable thresholds for the performance parameters in a schedule. The performance requirements that you define can also be used to validate the service-level agreements.
    - Repeating tests in a schedule
      By adding a loop to a A schedule, in this context, is used to refer to both VU Schedule and Rate Schedule, you can repeat a test for a number of iterations and set the rate for running a test. If the loop contains a synchronization point, the synchronization point is released after the first iteration of the loop and stays released for all further iterations.
    - Creating rate generators in user groups
      A rate generator is a workload container that specifies the number of tasks that the virtual testers run in a given time period. For example, you might be testing an Order Entry group that completes 10 forms every hour, or you might be testing a web server that you want to be able to support 100 hits every minute. Use a rate generator to model this time-based behavior.
    - Running tests at a set rate
      To run a test at a set rate, you add a loop to the schedule to control the iteration rate, and then add tests to the loop. The tests, which are children of the loop, are controlled by the loop. If the loop contains a synchronization point, the synchronization point is released after the first iteration of the loop and stays released for all further iterations.
    - Running tests in random order
      A schedule that contains only user groups and tests will run each test in a user group sequentially. By adding a random selector to a schedule, you can repeat a series of tests in random order, thus emulating the varied actions of real users.
    - Adding a transaction to a schedule
      A transaction is a specific group of test elements whose performance you are interested in. When viewing the test results, you can view performance data about any transactions that you have added.
    - Emulating network traffic from multiple hosts
      By default, when you run a schedule, each virtual user has the same IP address. However, you can make each virtual user appear as though it is running on its own host. To do this, you configure IP aliases on the host computer, and enable IP aliasing in the schedule. When you run the schedule, the network traffic will appear to be generated by multiple hosts.
    - Monitoring resource data
      Resource Monitoring is used to capture data, such as processor or memory usage, while running a test schedule. It can provide a comprehensive view of a system under test, to help identify issues. You can monitor data sources from a local or cloud schedule, or from a Service.
    - Resource Monitoring Service
      When you apply load to a system under test, the system's resources are consumed increasingly. If the capacity of the resources does not match the load, you will notice performance degradation in the results. With the Resource Monitoring Service, you can continually observe the health of the system's resources.
    - Monitoring response time breakdown
      You can use response time breakdown to see statistics on any page element that is captured while running a test schedule or imported from historical data.
    - Setting log and statistic levels
      Within a schedule, you set the size and sampling rate of the test log and the problem determination log, as well as the statistics that are displayed during a run.
- 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.
- 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)
  This page contains the release notes, system requirements, and persona guides for IBM® Rational® Performance Tester in PDF format.
- 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.

User group overview

User groups enable you to group tests in a logical order.

With user groups, you can control test execution in several ways:

Group tests by characteristics. For example, you could have two user groups—a Buyers group and a Browsers group—that represent the types of users on your system.
Influence the order in which tests are run. When you run a VU Schedule, the first test in each user group runs—in parallel, not sequentially. After the first test in a user group is completed, the second test runs, then the third, and so on.

The following VU Schedule contains one user group.

Schedule with a user group called Browsers and Buyers. The user group contains five tests: Open, Browse, Open, Browse, Bid.

If you run this VU Schedule with 10 users, they are assigned to the only user group—Browsers and Buyers. When the run starts, the 10 virtual users start running the first test in parallel. As soon as one test is finished, a virtual user moves to the second test. Thus, you have 10 virtual users, all starting at the same time and running each test sequentially. This does not give you much control over the run.

The following VU Schedule contains the same tests in the same order, but they are divided between two user groups. Conceptually, this VU Schedule is easier to understand, because the user's tasks are grouped logically—the Browsers browse, and the Buyers browse and then bid on a product. But, even more important, this one gives a more accurate representation of the types of users on your system, because each user group contains tests that represent the actions that they do, and the proportions of the user groups (70% and 30%) represent the proportions of the users on your system.

Schedule with two user groups. Browsers group contains two tests: Open and Browse. Buyers group contains three tests: Open, Browse, Bid.

If you run this VU Schedule with 10 users, seven are assigned to the Browsers group, and three are assigned to the Buyers group. When the run starts, the seven Browsers and the three Buyers start in parallel. Thus, you have seven Browsers, each running two tests sequentially, and three Buyers, each running three tests sequentially.