Test-runs
Running a Test enables you to simulate real end user Web activity and to collect performance data from the components of the system under test. Use the results you produce during a Testrun to help evaluate the performance of target Web Application Environments (WAEs). You can also use HTTP/S Load to create and run Collector-only Tests to monitor WAEs in a production scenario. The ability to run load Tests and production monitoring Test means that you can directly compare the performance of your target system within these two environments.
HTTP/S Load's distributed software testing architecture enables you to run the Task Groups that comprise a Test on remote Hosts during a Test-run. Distributing Task Groups across a network enables you to run Tests that generate realistic heavy loads simulating the activity of many Virtual Users.

Dynamic Tests
In HTTP/S Load Tests are dynamic, which means that the Test contents and settings can be modified while it is running, giving you control over a Test-run and the results that are generated.
New Task Groups can be added and the contents and settings of the existing Task Groups that comprise a Test can be individually edited by temporarily stopping the Task Group, making the changes required then restarting them. These facilities give you control over the load generated and enable you to modify the type of performance data you monitor and record without stopping the Test-run.

Distributed Tests
HTTP/S Load supplies a distributed software testing architecture based on CORBA which enables you to utilize remote Host computers to run the Task Groups that comprise a Test. A Task Group can be run by a Task Group Executer process on a remote Host or the Repository Host during a Test-run.

Monitoring a Test-run
During a Test-run all Task Groups, the Tasks they contain and summary information can be monitored using Commander, from the Monitoring tab of the Test Pane. Open the Test that is currently running from the Repository Window

Trace Settings
The Trace Settings function is used to record the activity of the Test Executer processes that execute the Test and its constituent Script and Collector Task Groups when a Test is run. If you encounter problems during a Test-run, use the Trace settings option to supply you with information on the Test Executer processes and help identify the problem.
The level of data logged using this option can be increased from None, which is the default setting to High, until information relating to the problem is recorded. The amount of Tracing you select will have an affect on the performance of your system so it is best to increase tracing levels gradually over a series of Test-runs until you are able to identify the cause of a problem using the Trace files that are generated.
If you have additional OpenSTA Modules installed extra process entries are added to the Target Name entries column in the Trace settings dialog box, which is used to set the Trace level you want.
After a Test-run is complete the Trace files generated for the Test Executers you have selected are copied to the Repository where they can be found in the Test-run folders.

Tasks and Task Groups
Work from the Repository Window to create new Tests and to open existing ones. Its default location is on the left-hand side of the Commander Main Window,
The Repository Window displays the contents of the Repository and functions as a picking list from where you can select the Scripts and Collectors you want to include in a Test. Use it in conjunction with the Configuration tab of the Test Pane to develop the contents of a Test. Select a Script or Collector from the Repository Window then drag and drop it on to a Task column in the Test table.

Schedule Settings: apply to Script-based and Collector-based Task Groups
Schedule settings enable data to be collected, or an HTTP/S load to be applied, over specific periods by controlling when Task Groups start and stop during a Test run. Click on the Start cell in a Task Group and use the Properties Window to specify your Schedule settings. Once a Test is running, Schedule settings cannot be edited, but they can be overridden manually using the Start and Stop buttons that appear in the Status column of a Task Group.
The default setting for a Task Group to start is when the Test is run. The Scheduled option starts a Task Group after the number of days and at the time you set. The Delayed option starts a Task Group after the period of time you set, relative to when the Test was started.

Host Settings: apply to Script-based and Collector-based Task Groups

Specify the Host computer you want to use to run a Task Group during a Test-run. Click on the Host cell in a Task Group and use the Properties Window to select a Host.

Virtual User Settings: apply to Script-based Task Groups only
The load generated against target Web Application Environments (WAEs) during a Test-run is controlled by adjusting the Virtual User settings. Click on the VUs cell in a Script-based Task Group and use the Properties Window to specify your Virtual User settings.
Specify the number of Virtual Users you want to run the Task Group to control the HTTP/S load generated when the Task Group is run. Logging levels can be set here to specify the amount of HTTP/S performance statistics gathered from the Virtual Users running the Task Group. Select the Generate Timers option to record the time taken to load each Web page specified in a Script by each Virtual User running the Script.

Task Settings: apply to Script Tasks only
Edit the Task settings to control how many times a Script is run. Click on a Task cell in a Script-based Task Group and use the Properties Window to specify your Task settings.
You can schedule a Script Task to stop after a fixed period of time or after completing a number of iterations. You can also specify a Fixed or Variable delay to be applied between each Script iteration completed by a Virtual User during a load Test.

SCL Representation of Scripts
SCL, Script Control Language, is a scripting language created by CYRANO. Within Script Modeler, it is used to write the Scripts which define the content of your Tests. Make use of SCL commands to model Scripts and develop the Test scenarios you need

The Environment Section
The Environment section is always the first part of a Script. It is introduced by the mandatory Environment keyword. It is preceded by comments written by the Gateway which note the browser used and the creation date.
This section is used to define the global attributes of the Script including a Description, if you choose to add one, the Mode and Wait units

The Definitions Section
The Definitions section follows the Environment section and is introduced by the mandatory Definitions keyword. It contains all the definitions used in the Script, including definitions of variables and constants, as well as declarations of Timers and file definitions.

The Code Section
The Code section follows the Definitions section and is introduced by the mandatory Code keyword. It contains commands that represent the Web-activity you have recorded and define the Script's behavior. The Code section is composed of SCL commands that control the behavior of the Script.

Variables
When you create a new variable you need to choose the attributes it embodies in order to perform the functions you want when a Test is run. You can assign the properties you require from within the Variable Creation dialog box. To setup new variables select Variable > Create, or to edit existing variables, select Variable > Modify. Use these dialogs to control the function of your variables by selecting the settings you need.

Variable Scope Options
The Scope of a variable determines which Virtual Users and Scripts can make use them during a Test-run. The default variable scope is Local.

Variable Value Source
The Value Source option enables you to create new values for your variables or to use an existing source which can be externally accessed, from a file or a database. If you want to utilize an external value source select either File or Database from the Value Source drop down list and locate your value data.
The default option is the Value List.

Variable Order
The Order option controls how the variable values are selected during a Test-run. The choice for the selection of variable values is Sequential or Random. Choosing a sequential order for the selection of variable values results in values being used consecutively from your value list.

MUTEX Locking
MUTEX locking is a straightforward procedure that you can perform in order to ensure a Test-run which simulates unique, multiple Virtual Users is successful.

DOM Addressing
DOM Addressing is a modeling technique that enables you to effectively validate a Test by checking that the HTML responses are correct.