Home
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.
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.
Editing HTTP tests
After you record a test, you can edit it to include variable data rather than the data that you recorded and can include verification points to confirm that the test runs as expected. You can also edit the test to include [NB1] transactions, conditional processing, custom code, and standard header or custom header to a request or response.
Verifying expected behavior
To check whether an expected behavior occurred during a run, you add verification points. When you run a test that contains a verification point, an error is reported if the expected behavior did not occur. When global verification points are disabled (the default), you can enable verification points for a specific test.
Specifying the expected response size
Response size verification points verify that the number of bytes returned in a response is what you expected. If the byte count does not match, the test log reports a failed verdict event. You can specify an exact response size or verify that the byte count is within a range.

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.
  - Editing HTTP tests
    After you record a test, you can edit it to include variable data rather than the data that you recorded and can include verification points to confirm that the test runs as expected. You can also edit the test to include [NB1] transactions, conditional processing, custom code, and standard header or custom header to a request or response.
    - Redirection support for HTTP tests
      When you run HTTP tests, redirect requests are followed automatically, which supports common usage patterns, such as load balancing.
    - Creating secondary HTTP requests
      A recording creates multiple HTTP requests and responses. In some cases, a response from the server can be dynamic, because of which the subsequent requests might need to be modified. While playing back the test, some of these dynamic requests might fail. For example, recording and playback might involve a different set of users with different permission settings or the UI elements might have changed since the time you recorded the test.
    - HTTP test editor overview
      With the test editor, you can inspect or customize a test that you recorded.
    - Specifying the number of allowable URL redirects during test runs
      When you run a test in a load-sharing environment, an unexpected redirection loop might occur during HTTP processing. An unexpected redirect response occurs when an HTTP request that normally returns a specific document redirects the browser to another location.
    - Cutting and pasting in tests
      You can cut, copy, and paste in HTTP tests.
    - Defining requirements in tests
      You can define requirements for elements in a test. These requirements specify acceptable thresholds of performance and validate service level agreements. Starting from version 9.2.0.1, you can define both performance and functional requirements in the tests. The verdict of the test is computed based on the requirements defined in the schedule. You can view the verdict in the Requirements report.
    - Adding an authentication folder
      Web application servers can include an option to force a login. You might have recorded a test with this option disabled but want to run the test with the option enabled. Adding an authentication folder to the appropriate test request lets you do this without recording the test again.
    - Adding or removing header in batches
      You can add or remove HTTP header from multiple HTTP requests or responses in batches to improve the script efficiency. For example, during the development process, there might be HTTP headers change or addition of new HTTP headers to the requests. These changes in the HTTP headers will result in the test script failure.
    - Verifying expected behavior
      To check whether an expected behavior occurred during a run, you add verification points. When you run a test that contains a verification point, an error is reported if the expected behavior did not occur. When global verification points are disabled (the default), you can enable verification points for a specific test.
      - Specifying the expected page title
        Page title verification points verify that the primary request for a page returns the expected page title. If the returned title is unexpected, the test log reports a failed verdict event. Although the comparison is case-sensitive, it ignores multiple white-space characters (such as spaces, tabs, and carriage returns).
      - Specifying the expected response code
        Response code verification points verify that the response code matches an expected value. If the returned code is does not match, the test log reports a failed verdict event. You can specify an exact response code or verify that the code is within the same category.
      - Specifying the expected response size
        Response size verification points verify that the number of bytes returned in a response is what you expected. If the byte count does not match, the test log reports a failed verdict event. You can specify an exact response size or verify that the byte count is within a range.
      - Specifying the expected content
        Content verification points verify that the response contains—or does not contain—an expected string. If the content returned is unexpected, the test log returns a failed verdict event. You can create a content verification point from specific response text.
    - Specifying error-handling behavior
      You can specify how error conditions are handled when running a test or schedule. Error conditions include verification point failures, connection failures, server timeouts, custom code alerts, and problems with data correlation.
    - How loops affect the state of virtual users
      If verification points fail unexpectedly during a run, the cause might be that virtual users in loops do not maintain their original state. To enable each virtual user to enter the loop in the original state, you can modify the test's HTTP options or add custom code.
    - Splitting a test
      After you record a test, you can split it into smaller tests. By splitting a test, you can create modular building blocks of smaller tests and combine them to make bigger tests. The original test is unchanged.
    - Splitting a test page
      You can split an HTTP page into two contiguous pages. The page title, think times, primary request, and delay are automatically recalculated for the affected pages. Customized page titles, think times, primary requests, and delays revert to the default values.
    - Merging test pages
      You can two or more contiguous HTTP pages into one page. The page title, think times, primary request, and delay are automatically recalculated for the affected pages. Customized page titles, think times, primary requests, and delays revert to the default values.
    - Disabling and enabling secondary HTTP requests
      You can disable all secondary requests within an HTTP performance test or a subset of requests in the test. Secondary requests are all requests within a page other than the primary request.
    - Adding custom actions to requests
      After an HTTP test is generated, you might want to add a few actions before or after a particular request is processed. For instance, for preprocessors, you can modify the headers before sending them to the server. Similarly, for postprocessors, you can extract data from the response and set it to a variable.
    - Reusing tests on different hosts: Server connection variables
      Your tests represent a significant investment in time and effort. You can share or reuse them for different configurations and web hosts by changing the variables for the host name and port.
    - Converting tests to use SSL connections
      You can convert a test that was recorded without Secure Sockets Layer (SSL) connections to use SSL connections.
    - Working with Server Name Indication (SNI) recordings
      If you have recorded against a server that supports Server Name Indication (SNI), an extension of the TLS protocol, the recording session file displays true for the SNI Extension field. There might be a need for you to access both SNI and non-SNI applications from the same server. To run the same test without using the SNI extension, you can manually change the value to false.
    - Viewing a test in the Protocol Data view
      The Protocol Data view enables you to inspect the actual test data. You can see requests, response headers, and response contents, as well as the rendered images that you see through your browser. Use this view to obtain the information you need to add custom code or to manually correlate data. This view also lets you compare the recorded data with the data retrieved during a run.
    - Testing Siebel applications
      When you record a Siebel application, a Siebel-specific test is automatically generated. However, before you run this test, install the Siebel Test Automation library and edit the test to use built-in Siebel variables.
  - Editing SAP tests
    After you record a test, you can edit it to include variable data (rather than the data that you recorded) and verification points (to confirm that the test runs as expected).
  - Editing Citrix tests
    After you record a test, you can edit it to include variable data (rather than the data that you recorded), verification points (to confirm that the test runs as expected), transactions, conditional processing, and custom code.
  - Editing service tests
    After you record a service test, you can edit the calls and message returns to include variable data (rather than the data that you recorded). You can add verification points (to confirm that the test runs as expected), transactions, conditional processing, and custom code.
  - Editing Socket tests
    Improve the Socket tests by adding test elements.
  - Editing Kerberos tests
    You can change the Kerberos realm, user name, and password when editing tests.
  - Adding test elements
    You can add a variety of elements to a test, such as transaction blocks, IF-THEN conditions, loops, and comments.
  - Searching within tests
    Search request data or response content by right-clicking in the data or content and selecting Find. To search for specific element types and to display the results in a table, click Select. For a still more powerful search and replace, use the Test Search function.
  - Exporting a test
    To share the test scripts with manual testers or reviewers who do not have the workbench, export the test scripts to text files. You can export one file at a time.
  - Copying test assets with dependencies
    You can export test assets, and then import them into another project or workspace without losing any dependencies. Test assets include projects, schedules, and tests. You can export and import test assets to collaborate with other testers.
  - Disabling portions of a test
    When you disable portions of a test, you can still see the disabled portion, but it is not executed during a run. You can also disable portions of a schedule by using the following procedure.
  - Running test elements in random order
    You can record multiple user scenarios in a test and then run each scenario in a random order. To do this, you put each scenario under a random selector and then select the proportion of time that the scenario should be run.
  - Renaming test assets
    As your test assets increase and become more complex, you might want to rename them. Use the Eclipse Rename function or save the assets under a different name.
  - Deleting test assets
    As your test assets grow and become more complicated, you might want to delete the assets that you no longer use.
  - Debugging custom code for tests and compound tests
    If you have custom code added to a test or a compound test, you can debug the custom code for any errors by clicking the Debug button.
  - Providing tests with variable data (datasets)
    You can produce more realistic tests by changing them to use datasets. During execution, a test that uses a dataset replaces a value in the recorded test with variable test data that is stored in the dataset. This substitution allows each virtual user to generate a different request to the server.
  - Test variables
    A test variable is a user-defined, name-value pair that stores and refers to information throughout a test and between tests.
  - Correlating response and request data
    For a test to run correctly, a request that is sent to a server might need to use a value that was returned by a previous request. By ensuring that this data is correlated accurately, you can produce better performance tests.
  - Data transformation
    You can transform HTTP application specific data such as JSON data, binary data and encoded data to a more readable format to use data correlation.
- 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.

Specifying the expected response size

Response size verification points verify that the number of bytes returned in a response is what you expected. If the byte count does not match, the test log reports a failed verdict event. You can specify an exact response size or verify that the byte count is within a range.

Procedure

In the Test Navigator, browse to the test and double-click it.
The test opens.
Right-click the test name, a test page, or a request, and select Enable Response Size VPs
Your choice determines whether the verification point is added to all test pages, to a page in the test, or to a particular request. The following figure shows a response size verification point within a test:
Note: When you modify a test, the modified items appear in italic type. The italic type changes to regular type after you save the test.
Click the verification point to display the response size editing fields in the Test Element Details area.
Responses to HEAD requests, by definition, have no contents; the size is always 0.
To disable an individual response size verification point, clear the Enable verification point field.
From the Select matching method list, click an option to indicate how closely the response size that is returned in the page request must match the recorded response size.
- The default matching method for a primary request is Range, with a percentage adjustment based on the value in the field on the right. (You can change the percentage basis as well as the matching method.) When the test is run, an error is reported if the actual response size falls outside the adjusted range.
- For other requests, the default matching method is Exact. When the test is run, an error is reported if the response size does not exactly match the expected size.

What to do next

You can also change the preferences so that Response Size verification points are set automatically. To do this:

Change subsequent tests that you record. Click Window > Preferences > Test > Test Generation > HTTP Test Generation > Verification Points, and select HTTP Response Size. This changes subsequent tests that you record.
Optionally, regenerate existing tests with the changed preference, as shown in Generating a new test from a recorded session.