Running a local schedule or test

You can run a test locally or a schedule, in this context, is used to refer to VU Schedule and Rate Schedule on remote locations with a default launch configuration.

Before you begin

To play back tests against the applications that require client authentication such as Digital Certificates or Kerberos, you must provide the appropriate authentication before playing back the test.

About this task

When you run a schedule or test in this way, Test Performance automatically sets up a simple launch configuration. A test runs on the local computer, with one user. A schedule runs with the user groups or Rate Runner groups and the locations that you have set. However, the execution results have a default name (the same as the schedule or test, with a suffix) and are stored in a default location.

The Rate Schedule can be run only on agent locations.

When you run a schedule with multiple agents, an agent might be lost, especially during the long load test run. Losing an agent is not common and occurs during some extreme cases such as when computer's memory is exhausted. When an agent is lost, by default, the schedule is stopped. When the schedule is stopped in this manner, you must fix the reason of agent loss or add more agents before running the schedule. To continue to run the schedule without the lost agent, in the Schedule editor, click the Advanced tab and clear the Loss of an agent halts execution check box.

Typically, the agents divide the load among themselves. So, running a schedule without the lost agent might give unpredictable results. If you use a segmented dataset and if you run a schedule without the lost agent, the data is not redistributed among the surviving agents. Also, if the schedule has multiple stages, by default, the load is distributed among the surviving agents at the next stage. But, if the Replace lost users in current stage check box is selected, then the load is distributed evenly among the surviving agents in the current stage. If the check box is cleared and a percentage of users or clients are allowed to exit during stage execution, the load is distributed among the surviving agents in the next stage. Loss of an agent in a schedule run is logged in the Performance Report.

To stop a test gracefully without causing incomplete page hits, select the Active actions are allowed to complete if stop requested check box at Window > Preferenes > Test > Test Execution.

To receive email notification for the status of the run, specify the email properties in Window > Preferenes > Test > Test Execution.

Procedure

  1. In the Test Navigator, expand the project until you locate the schedule or test.
  2. Right-click the schedule or test, and then click Run As > Performance Schedule or Run As > Test.
    Note: If you run an HTTP schedule on a remote Macintosh computer, the test fails. The cipher suite that is used for recording must be available in Oracle JDK on the Macintosh computer. For example, you can use TLS_RSA_WITH_AES_128_CBC_SHA on Macintosh.

Results

After you run a test or a schedule, the Performance Test Runs view opens. In this view, you can add comments about the selected result and view the settings that were used to run the schedule. To add comments, in the lower-left panel of the Performance Test Runs view, click User Comments. The comments that you enter are displayed on the Summary page of performance reports. To view the settings that were used for a schedule run, click Schedule Settings. The Performance Test Runs View Schedule Settings page displays and shows the statistics and test log settings that were used for the run.

Note: When you record a test that includes a file download, the file is not physically saved to disk. However, you can confirm that the file was retrieved from the server by looking in the response of the request that asked for the file. One method to locate the request for large downloaded files is to look for a request with a large response size.

What to do next

You can configure a schedule or test. A typical reason for setting up a configuration is to control where the execution results are stored. For more information, see Setting a launch configuration.