Configure test settings

The Test settings page lets you configure your load test's behavior.

To access the settings, open a test in the Load tests tab, and click the Test settings button Test settings button.

Basic settings

In the Basic settings section, you provide a name and description for your test that enable you to identify it at a later time.

Action Task
Test name

Specify a meaningful name for the test. The test name cannot exceed 140 characters. To enable test duplication, ensure that the name does not exceed 120 characters.

Description Add a description of your load test.
Email a report when the test finishes

Select the checkbox to send a report by email when the load test finishes. By default, the report is sent to the logged in user, but you can add up to another five email addresses by clicking Add emails.

Template selection

When you enable the email option, you can choose the template to use for the test run report that is emailed to you at the end of a run. To select a template, click Select Template, make your selection, and then click Select. For details, see Create report templates.

Back to top

Run configuration settings

In the Run configurations section, you choose a license mode, run mode, and other run-related settings.

Action Description
License mode

Indicates the license type to use:

  • VUH: Enables you to run Vusers by the hour in load tests. 1 VUH is effectively 1 Vuser executing a load test for 1 hour.

  • VU: A fixed license enabling you to run Vusers.

  • Mixed VU/VUH: Uses VU licenses first and when no more are available, then uses VUH licenses to reach the required number of Vusers.

For details about restricting the use of VUH licenses, see Manage licenses.

Run mode

Sets the run mode type:

  • Duration: The load test runs each script for as many iterations as possible in the script's configured time duration. This is the default option.

  • Iterations: The load test runs each script for the number of iterations configured for the script.

    Note: You also configure a maximum duration for a script. If the number of iterations configured for the script has not been reached within this time, the Vusers for the script are terminated. The following features do not support the Iterations run mode:

    • Adding Vusers
    • Manual and advanced scheduling for scripts
    • Generating single user performance data
    • The Timeline tab when scheduling a load test
    • Changing the load in a running load test that is configured for iterations
    • DevWeb scripts included in a load test configured for Iterations mode that is run on an on-premises load generator, are only supported for on-premises load generators version 2020.05 or later.

  • Goal Oriented: The load test runs until a configured threshold is reached. For details, see Configure a goal.

Results aggregation interval

Select the time interval (in seconds) at which results data is aggregated during a test run.

The recommended time interval, and the only option available by default, is five seconds. To add additional aggregation interval options (1, 30, and 60 seconds) submit a service request.

For tests that have a long duration, many Vusers, or lots of transactions, increasing the aggregation interval can help avoid data loss and slow response time.

For smaller scaled tests, you can decrease the time interval to one second to obtain better granularity. This option is only available for load tests that have:

  • a duration of less than two hours

  • up to 10,000 Vusers

  • up to 400 unique transactions

Percentile goal

Select the percentage of transactions expected to complete successfully. This goal value impacts the percentile calculated in the dashboard, the report, and the SLA criteria.

The default value is 90%.

Optimal percentile (T-Digest)

Instructs OpenText Core Performance Engineering to use an optimal algorithm based on T-Digest in the Report, when calculating the percentile for TRT (transaction response time). For details, see Report sections.

This option is activated by default. If you deactivate it, OpenText Core Performance Engineering uses an average percentile algorithm. For details, see Percentiles.

Pause scheduling

Pauses the scheduling during a test run.

Select the total possible pause time during a run from the dropdown list (the maximum is two hours).

Note:

  • This feature does not support the Goal Oriented run mode.

  • When pausing is enabled, the following features are not supported:

    • Adding Vusers
    • Single user performance
    • Changing the load when running a test

For details on pausing a schedule during a run, see Run the test.

Note: This options adds 1 VUH to each Vuser in your test.

Add Vusers

Enables you to increase the maximum number of Vusers, above the predefined number of Vusers, while your test is running. When you enable this setting, you also need to provide a non-zero value in the Load profile page, indicating the percentage of Vusers to add. Set the value in the Add Vusers during the test run box in the Load profile page.

This feature is only relevant if all Vusers in all scripts are in Duration mode. If Vusers in at least one script are ramping up or ramping down, or a script finishes running, the change load capability is no longer available for the remaining scripts.

Note: To cover the cost of initializing extra load generators, additional VUH charges apply.

Delayed start

Delays the start of the test run, after initialization, for up to 60 minutes.

Note: This options adds 1 VUH to each Vuser in your test.

Exclude think time from TRT calculation

Excludes think time from the results and report calculations for the transaction response time. By default, this option is inactive, and think time is included.

Excluding the think time may affect the result's trend and benchmark comparisons if this option was not enabled for the compared run.

Note: To use this feature when running Vusers on an on-premises load generator, version 2020.10 or higher of the on-premises load generator is required.

Group transactions

Creates a transaction group for all the transactions with the same name in all scripts included in the load test. Metrics for this transaction group are displayed in the Dashboard and in Reports, in addition to the metrics for the individual transactions.

Note:

  • This option does not support dynamic transactions.
  • Transaction groups are not included in raw transaction data for export. For details on storing raw transaction data, see Store transactions raw data.

Back to top

Data and logs

This following table lists the data and logging preferences.

Action Task
Stream errors to Splunk

Enables the streaming of errors to a Splunk account. For details, see Splunk integration.

Note: When this option is unavailable, even if the checkbox is selected, errors are not streamed to Splunk.

Store errors

Stores all error messages generated during a test run, in raw format.

For details of exporting this data, see Export raw error data.

Store transactions raw data

Stores transaction data generated during a test run, in raw format.

For details of exporting this data, see Export raw transaction data.

Note: Transaction groups are not included. For details on grouping transactions, see Group transactions.

Collect Vuser logs from cloud-based load generators

Collects Vuser logs from the cloud-based load generators used in the load test.

For details on downloading the logs, see Generate and download logs.

Note: Collecting Vuser logs may cause the load test to take longer to stop after it has run.

Collect Vuser logs from on-premises load generators

Collects Vuser logs from on-premises load generators used in the load test.

Note:

  • This option is turned off by default. To enable this option, submit a service request.

  • Each on-premises load generator must be configured to collect Vuser logs. For details, see Generate and download logs.

After your test run, you can download the logs as described in Download logs.

Note: Collecting Vuser logs may cause the load test to take longer to stop after it has run.

Back to top

Load generator settings

In the Load generators area, you add scripts from your assets and then manage them as described below.

Action Task
Enable Cloud LG Vusers configuration

Allows you to edit the number of Vusers that can run for each cloud load generator, per protocol. Expand the dropdown to see additional options.

  • System default: The maximum number of Vusers that are be able to run per protocol, correspond to those set by the administrator.

  • Manual: Lets you reduce the maximum number of Vusers that can run per protocol on cloud generator machines. For details, see Cloud LG infrastructure capacity.

Enable multiple IPs for cloud and on-premises load generators

Enables multiple IP addresses on each load generator.

This option is applicable for load generators in an AWS or Azure cloud (all regions except for AWS China) and for Windows on-premises load generators.

IP addresses are assigned to Vusers on a round-robin basis. For example, if a load generator has 10 IP addresses and 100 Vusers are running on it, the first 10 users each have a unique IP address and subsequently, each group of 10 Vusers repeat the IP address pattern.

Supported for the following script types:

  • Mobile Application HTTP

  • SAP - Web
  • Siebel Web
  • Oracle - Web
  • Web HTTP

  • Web Services

Note: Scripts in which WinInet is enabled do not support multiple IP addresses.

To enable this option, submit a service request.

On-premises load generators (Windows)

For Windows on-premises load generators, you must ensure that you have assigned all the valid IP addresses to the load generator machine so that OpenText Core Performance Engineering can use them in the load test. For information on how to add IP addresses to a load generator (also known as IP spoofing), refer to the LoadRunner Professional Help Center.

Cloud-based load generators

For AWS and Azure cloud-based load generators, OpenText Core Performance Engineering automatically assigns a maximum of 15 IP addresses for a single load generator, with a maximum of 300 IP addresses for the entire load test. To modify these default values, submit a service request.

When using the default values, OpenText Core Performance Engineering:

  1. Determines the required number of cloud-based load generators required for the test.

  2. Configures 15 IP addressees on each cloud-based load generator (or less, if applicable).

  3. Fails the test if the total amount of required IP addresses that need to be set for the test exceeds 300 (the default maximum).

  4. Fails the test if there are not enough allocated IP addresses to be distributed among the cloud-based load generators. This applies when you have dedicated (allocated) IP addresses for cloud-based load generators. The IP addresses used for the test are only taken from the allocated IP address pool.

The following examples show the different IP requirements for a test configured to use 3,000 Web HTTP Vusers and based on a limit of 2500 Vusers for each cloud-based load generator (thereby requiring 2 load generators for the test):

Do not use dedicated IPs for cloud load generators

If dedicated IP addresses were assigned to your tenant, by default OpenText Core Performance Engineering only uses cloud-based load generators on the dedicated IPs. To use cloud-based load generators on a non-dedicated IP for a specific test, deactivate this option.

For details, see Dedicated IP addresses.

Enable health monitoring of cloud load generators

Enables the monitoring of system health measurements for cloud-based load generators. The system health metrics include CPU and memory.

For details, see Load generator health monitoring.

Note: Cloud load generator monitoring is turned off by default. To enable this option, submit a service request.

Enable manual Vuser distribution for on-premises load generators

Enables manual Vuser distribution over your on-premises load generators. If this option is off, OpenText Core Performance Engineering uses the default distribution as described in Vuser balancing.

When you enable this setting, the adjacent dropdown presents two options:

  • Simple: Assign scripts in a load test to be run on specific on-premises load generators. For details, see Applying simple assignment.
  • Advanced: (not available for Goal Oriented mode) Assign the Vusers of each script to run on specific on-premises load generators. This option allows you to manually set the distribution. For details, see Applying advanced assignment.
Permit use of Linux load generators for Web Vuser scripts

OpenText Core Performance Engineering tries to use Linux cloud load generators (where applicable) to run Web Vuser scripts, providing faster provisioning.

To enable this feature, submit a service request.

Note:

  • This applies only to Web HTTP Vuser scripts.

  • Scripts in the load test cannot include Windows dependencies (such as a path or DLL).

  • Single user performance reports and network emulation are not supported.

  • Data Format Extensions (DFEs) are not supported. For details on DFEs, see the VuGen Help Center (select the relevant version).

Back to top

Generate and download logs

To generate and download logs for your load tests do the following:

Action Task
Enable logs
  1. Select the Load tests tab and select a load test.
  2. Click the Test settings button Test settings button to open the Test settings page.
  3. In the Data and logs section, select Collect Vuser logs from … load generators. For details, see Data and logs.
Configure your script to generate logs
  1. In VuGen, select VuGen > Runtime Settings > Logs > Log Level and associated options.

  2. Set the Log level to standard.
Configure your load generator to collect logs (on-premises LGs only)
  1. Under Assets, select the Load Generators tab.

  2. Select a load generator and click Edit.
  3. Turn on the Enable Vuser Logs Collection switch.
  4. Repeat the above steps for each on-premises load generator for which you want to collect logs.
Retain the log (on-premises LGs only)

For details, see the Options tab in the OPLG configuration tool.

Download the log

For details, see Download logs.

Back to top

See also: