5 Defining Virtual User Scenarios

This chapter explains how to define virtual user scenarios based upon the virtual user profiles.

5.1 Defining Scenarios

Virtual user scenarios specify the following attributes for each profile:

number of virtual users to simulate
the system on which the virtual users will run
which browser to emulate
the delay time between virtual user iterations
pacing of the visual scripts
type of user to simulate
object downloading
use of Data Banks
error handling for virtual users
setting up virtual users for viewing in the Virtual User Display component

The following sections explain how to specify virtual user scenarios.

5.1.1 Selecting Profiles

Once you have a set of virtual user profiles, you can define Oracle Load Testing scenarios to run performance and load testing on your Web pages or application. Virtual user profiles can be either default profiles (basic Oracle Functional Testing Visual Scripts) or user-defined profiles created in Oracle Load Testing.

To add profiles to the Scenario Profiles list:

If necessary, open a saved Scenario file.
Select the Build Scenarios tab.
Select the repository and workspace containing the profile you want to add.
Select the profile you want to add.

Note:
For databank settings to work properly, the name of the profiles added to the scenario should be unique.
Click the Add to Scenario button or double-click the profile name in the profile list.

5.1.2 Specifying Scenario Profile Attributes

Once you select the scripts and user-defined profiles to include in the scenario, you can specify the Scenario parameters for each one. To set the parameters for a specific script or user defined profile.

If necessary, open a saved Scenario file.
Select the Build Scenarios tab.
Select the scripts and user-defined profiles to include in the Scenario.
Click the Scenario Detail button to display the Edit Scenario Details dialog box.

Note:
A subset of the parameters in this dialog box can be specified directly in the Build Scenarios tab. To specify which parameters are displayed in the Build Scenarios tab, select Options from the Tools menu then select Scenario Defaults and select the fields you want to display by selecting the Show checkbox for each field.

Right Click Menu - lets you copy and paste settings from one script or user defined profile to another. Right click on the script or user defined profile whose settings you want to copy and click Copy. Right click on the script or user defined profile that you want to copy the settings to and click Paste.

Main - the main settings are as follows:
- # VUs - specifies the number of virtual users to run for the selected profile. For each virtual user, Oracle Load Testing runs a separate instance of the Visual Script(s) specified in the virtual user profile.
- System - specifies the machine on which the virtual users will run. When running virtual users across systems on a LAN/WAN, enter the machine name of a system running either Oracle Load Testing or Oracle Load Testing Agent. Systems are defined using the Systems Manager. Initially, you must define the machine names or IP addresses of the system(s) in the Systems Manager. Once the name(s) or IP addresses have been specified, you can select the system name from the drop-down list for future load tests.
- User Mode - the mode in which to run Oracle Load Testing virtual users. The following options are available:
  - Thick Client - the virtual users run using full browser capabilities. This mode requires more resources and is less scalable than Thin Client, and should only be used in special cases. Reasons for using Thick client may include Web pages that require large amounts of client side processing.
  - Thin Client - a less resource intensive method that provides a high level of Web compatibility and Visual Script verification. Thin Client mode consumes fewer system resources per process than Thick Client, and is able to run more virtual users on a given agent system.
  - Java Client - a highly scalable version of the Thin Client that executes a compiled Oracle Functional Testing script. This agent provides a flexible code interface for performing customized scripting operations.
    
    Note:
    User-defined scriptlets will not be executed when using the Java Client regardless of how the Execute User Defined Scriptlets options is set.
    
    When determining the number of virtual users to run per process or system, you need to include the Client overhead in the resource allocation. Each VU in Thin or Java Client requires approximately 350 KB-500 KB of memory to run. When calculating the available memory to run VUs on an agent system, you must account for a 20-30% client system overhead. Therefore, you only have 70-80% of the physical memory (RAM) available to run VUs.
- Iteration Delay - specifies the amount of time (in seconds) to wait between iterations of virtual user runs. You specify the number of iterations using the Autopilot.
- VU Pacing (Think Time) - specifies the Visual Script playback delay for each virtual user. There are four options:
  - Recorded - uses the delay times that were recorded in the Oracle Functional Testing Visual Script. You can set minimum and maximum delay times (in seconds) that override the Visual Script delay times in the Minimum and Maximum edit boxes.
  - Recorded/Random - uses random delay times based upon the recorded user delay. Oracle Load Testing sets the low end of the random range as the actual user delay minus the Lower percentage setting. Oracle Load Testing sets the high end of the random range as the actual user delay plus the Upper percentage setting. For example, if the actual recorded delay time was 100 seconds and the Lower and Upper settings are 10% and 25% respectively, Oracle Load Testing uses random delay times between 90 and 125 seconds.
  - Random - uses random times for Virtual User pacing. You can set minimum and maximum delay times for random delay in the Minimum and Maximum edit boxes.
  - No Delay - plays back the Visual Scripts at the fastest possible speed.
  Note:
  For OpenScript scripts, the VU Pacing overrides the times specified in think() and beginStep() methods.
- Use Data Bank - when true, Visual Scripts that have Oracle Functional Testing Data Banks will use the Data Banks as part of the virtual user playback. When false, Visual Scripts playback using the recorded data rather than the Data Bank.
Browser Settings- the browser settings are as follows:
- Browser Emulation - specifies the type of browser to emulate.
- Connection Speed Emulation - specifies the line speed to simulate for the virtual user's Internet connection. Set the speed to a specific number if you want the virtual user to simulate a dial-up connection using a modem, DSL, or other speed. Set the speed to True Line Speed if you want the virtual user to run using the actual connection speed.
- Cache Emulation - specifies the type of user to simulate. This is useful for simulating different profiles of virtual users. A first time user places more of a load on the Web server because pages and image are not yet cached. A repeat user places less of a load on the server as only newer pages are requested and brought down from the Web server. There are three options:
- Do Not Cache - cache is not used.
  
  Note:
  When using WinInet, selecting Do Not Cache has the same effect as selecting 1st Time as the Cache Emulation method. In this case, document cache is not created and not cleared. When using Thin Client for JHTTP, selecting Do Not Cache does not create cache or clear it. When the Cache Emulation method is set to 1st Time for Thin Client for JHTTP, cache is created and cleared after each iteration which can consume considerable amounts of memory.
- 1st Time- the virtual users are considered to be using the Web site or application for the first time for each iteration so no cache is used. The cache is used during the iteration.
- Repeat - the virtual users are considered to have visited or used the Web site or application previously. Pages and images are retrieved from the cache.
- Use IP Spoofing - when true, Oracle Load Testing uses different IP addresses for Virtual User agents. Each virtual user must get a defined IP address. You must define the IP addresses available for use by Oracle Load Testing Agents in the TCP/IP network protocols of the system. All IP addresses must be added to each Agent system. When using IP spoofing, it is recommended that VUs run with Thin Client without WinInet or with Java Client. See Using IP Spoofing with Oracle Load Testing in Chapter 5 for additional information.
- Use Download Manager - when true with Thin Client or Java Client User Mode, filters specified and enabled in Download Rules (select Options from the Tools menu) will be used to download objects as part of virtual user playback. When true with Thick Client User Mode, image objects will be downloaded as part of virtual user playback. Downloaded objects will be included as timers if you have Auto generate timers for all resources selected in the Scenario Defaults ( select Options from the Tools menu) and save data for reporting.
- Use Winninet - when true, Oracle Load Testing uses its Microsoft Win32 Internet (WinInet) application programming interface (API) version of the Thin Client agent. When false, Oracle Load Testing uses a custom (JHTTP) version of the Thin Client agent (referred to as "Thin Client for JHTTP").
- Enable Cookies - when true, the virtual user profiles will use cookies. Use this setting if your Web application uses cookies to manage session and other context information.
Extensibility - the extensibility settings are as follows:
- Execute User Defined Tests - when true, Oracle Load Testing runs Oracle Functional Testing Text Matching and Server Response tests.
- Execute User Defined Scriptlets - when true for Thick or Thin client, Oracle Load Testing runs Test Scriptlets included in Oracle Functional Testing Visual Scripts. Scriptlets are not executed when using the Java Client regardless of how this option is set. See the Oracle Functional Testing User Guide for more information about using Test Scriptlets with Oracle Functional Testing.
VU Display - the VU Display settings are as follows:
- View All Responses - select when you want to display all responses, on error, always, never.
- Show Request Headers - select when you want to display request headers, on error, always, or never. When displayed, request header information for Web page resources requested by the selected Virtual User appear in the Virtual User Display history list.
- Show Response Headers - select when you want to display response headers, on error, always, or never. When displayed, the Response header information for Web page resources requested by the selected Virtual User appear in the Virtual User Display history list.
Reporting- the Reporting settings are as follows:
- Auto Generate Timers For All Pages - when true, Oracle Load Testing automatically adds timers for each Visual Script page for reporting. The timers are used in Oracle Load Testing to provide performance monitoring and timing information for each page of the Visual Script(s) played back by a virtual user profile.
- Auto Generate Timers For All Resources - when true, Oracle Load Testing automatically adds timers for all resources for monitoring and reporting purposes. Resources include images and other objects downloaded from the server as specified by the Download Rules setting (select Options from the Tools menu).
Error Handling - the Error Handling settings are as follows:
- Object Download Errors Are Fatal - when true, a Web page object download error is considered a fatal error that ends the current iteration.
- Zero Length Download Errors Are Fatal - when true, a server response that indicates zero bytes length is considered a fatal error. Set this setting to false if your Visual Scripts are recorded as Siebel scripts.
- Stop Remaining Iterations on Failure - when true, all remaining iterations for a virtual user are stopped if an error is encountered.
- On Error Stop Virtual User - when true, a virtual user is stopped if an error is encountered.
- Request Timeout - specifies the maximum amount of time a virtual user waits to access a page before timing out.
- Stop Remaining Iterations on Failure - when true, remaining iterations for a virtual user are stopped if an error is encountered.
- Socket Timeout - specifies the maximum amount of time a virtual user waits for a socket connection before timing out.
Advanced - the Error Handling settings are as follows:
- Maximum Users Per Process - sets the maximum number of virtual users per single agent process. When running virtual users as threads in a single process, Maximum Users Per Process sets the maximum number of virtual user threads in a single process. Oracle Load Testing spawns new processes if the number of virtual users exceeds the maximum number in any single process and runs the additional virtual uses as threads in the new process.
  
  The default setting is unlimited virtual users per agent process.
- Maximum HTTP Threads Per Process - specifies the number of threads per agent process for optimizing the pooling of virtual user requests into a finite number of I/O worker threads.
- Maximum HTTP Connections Per User - specifies the maximum number of server connections per process per server. Each VU makes multiple connections to request additional resources for images and additional frames for example. Setting this option specifies a limit on the total number of connections that the VU s can make to the server. The default setting is "Default," which means use the default connection limits as configured on the agent machine. (See Microsoft KBase article Q183110 for more information.) This setting is used to override the agent machine configuration for Thin Client agents using WinInet.
- Ignore HTTP Proxy Settings - specifies whether to ignore the agent machine's default proxy setting as defined in Internet Explorer.
Java Client Preferences - these options only appear when User Mode is set to Java Client. When a setting is set to the default value, this means that the value that will be used is what is set in the OracleATS\OFT\jagent\ JavaAgent.properties file, unless a value is not set in the JavaAgent.properties file. In this case, the Java Agent uses the internal default value.
- Report Counters - when true, Oracle Load Testing counters are reported.
- Maximum Bytes of VU Display - when you select other, enter the number of bytes to send to the VU display per item, that is, a request is one item, a response is an item, and content is an item. The default in the JavaAgent.properties file is-1, which returns everything. The value entered roughly equates to the number of characters.
- Report Sender Interval - when you select other, enter the time in milliseconds for how frequently the agent reports its status and accrued counters. The default in the JavaAgent.properties file is 5000.
- Maximum JVM Heap Size (MB) - specifies the maximum size of the JVM heap. This value cannot be more than 90% of the total memory size.
- Proxy Host - select other to enter the proxy host and override the system-specified proxy host.
- Proxy Port - select other to enter the proxy port and override the system-specified proxy port.
- Non Proxy Hosts - select other to enter non-proxy hosts. Delimit multiple hosts with a bar (|).
- Enable GZIP - when true, gzip support is enabled.
- Enable Deflate - when true, deflate compression support is enabled.
- Language - when you select other, enter the language to override the Accept-Language header. The default is the locale assigned by the JVM.
- HTTP Version - select the HTTP version.
- Accept String - this setting controls what the Accept: HTTP header value looks like. When you select other, enter the string. The default in the JavaAgent.properties file is: text/html, image/gif, image/jpeg, */*. If you modify a navigation in a script by adding a custom Accept: header, the custom header value from the script is used instead.
- Enable Keep Alive - when true, keep alive is enabled.
- Preserve Connections Between Iterations - used to preserve connections between OpenScript and the browser between successive iterations of the script.
- Preserve Variables Between Iterations - used to preserve or automatically clear variables added in the Run section of OpenScript scripts between successive iterations of the Run section.
- Preserve Cookies Between Iterations - used to preserve or automatically clear cookies added in the Run section of OpenScript scripts between successive iterations of the Run section.
- Max Number of Keep Alive Requests - select other to specify the maximum number of requests to make on a keep alive connection before closing it.
- Download Local Files - when true, the Java Agent retrieves the requested local file contents.
- Max Content Download Size - specifies the maximum size for downloads. You can specify Unlimited or Other. If you select Other, specify the maximum size in kilobytes.
- SSL Version - select the SSL version.
- Agent Inactivity Timeout - specify the length of time, in milliseconds, that Oracle Load Testing will wait to hear from the agent before it assumes that the agent is not available.
- Ignored Url - specify the Urls, separated by commas, that should not be requested. This setting only applies to certain OpenScript scripts.
- Additional Arguments - specifies custom OpenScript script.java code arguments. You can create your own settings in OpenScript scripts. For example, you can create custom settings in OpenScript script.java code, as follows:
```
if (getSettings().get("MyCustomSetting").equals("abc")) {

  info("We're running in ABC mode.");

}
```
  You can then set the additional arguments in the Additional Arguments field as follows:
```
-MyCustomSetting abc
```
OpenScript Error Recovery - The OpenScript Error Recovery categories lets you specify error recovery actions for exceptions that occur during playback. You can set the error recovery action for individual playback exceptions. You can set the action as Fail, Warn, or Ignore, as follows:
- Fail: Report the error as failure and stop script execution.
- Warn: Report the error as a warning and continue script execution.
- Ignore: Ignore the error and continue script execution.
Error Recovery playback preferences specified in the OpenScript Preferences are stored on the local machine and only apply when the script is played back from inside OpenScript on that machine. If you upload your script to Oracle Load Testing on another server and your script depends on an error recovery setting being a certain way in order for it to work, then you can set the error recovery setting in the OpenScript script Java code.

In OpenScript scripts, error settings can be turned on and off at any time, overriding the default Oracle Load testing and OpenScript Preferences using script Java code. For example:
```
getSettings().setErrorRecovery("http.zeroLengthDownloads", "IGNORE");

// user code executed in script, such as http.get(), http.post(), ...

getSettings().setErrorRecovery("http.zeroLengthDownloads", "FAIL");
```
See the OpenScript documentation for a list of error recovery settings.

OpenScript Error Recovery - General - the General Error Recovery settings are as follows:
- File Not Found - specifies the error recovery action if a file is not found.
- Segment Parser Error - specifies the error recovery action if the XPath Segment Parser cannot verify the correctness of an XPath.
- Create Variable Fail - specifies the error recovery action if a script fails to create a variable.
- Encryption Service not Initialized - specifies the error recovery action when the password encryption service was not initialized.
- Binary Decoding Error - specifies the error recovery action if a binary post data parameter error occurs.
- Variable Not Found - specifies the error recovery action if a variable cannot be found when parsing transformed strings.
- Unexpected Script Error - specifies the error recovery action if any unexpected script error occurs.
OpenScript Error Recovery - HTTP - the HTTP Module Error Recovery settings are as follows:
- HTML Parsing Error - specifies the error recovery action if an HTML parsing error occurs.
- Text Match Fail - specifies the error recovery action if a text matching test fails.
- Solve Variable Fail - specifies the error recovery action if the value of any variable cannot be solved.
- Response Time Error - specifies the error recovery action if a Server Response Time test fails.
- Invalid HTTP Response - specifies the error recovery action if the sever returns an invalid HTTP response.
- Invalid URL - specifies the error recovery action if the server returns an Invalid URL response code.
- Zero Downloads Fatal - specifies the error recovery action if a server response indicates zero bytes length.
- Client Certificate Keystore Error - specifies the error recovery action if the Client Certificate Keystore indicates an error.
OpenScript Error Recovery - Oracle Forms Load - the Oracle Forms Load Test Module Error Recovery settings are as follows:
- Forms Connect Error - specifies the error recovery action if a server connection error occurs.
- Forms I/O Communication Error - specifies the error recovery action if a read/write or communication error occurs with an Oracle Forms message.
- Forms Playback Error - specifies the error recovery action if an error occurs during forms playback.
- Forms Component not Found - specifies the error recovery action if a component of a form is not found.
- Forms Content Match Failed - specifies the error recovery action if a content matching test fails.
Select the script or user defined profile that you want to edit from the list.
Set the attributes.
Repeat steps 5 and 6 for each script and user defined profile or use the copy and paste functions on the right click menu to copy settings from one script or user defined profile to another.
Click OK.

5.1.3 Determining the Number of Virtual Users

The number of virtual users that can run reliably and provide accurate performance data for your application depends upon several factors:

The User Mode (type of client browser) setting for the virtual user;
Resources required by the application;
Number of machines being used for the load test;
Amount of memory on each machine;
Operating system being used;
CPU utilization.

The general rules of thumb for determining the number of virtual users are as follows:

Keep CPU usage below 90% for each system in the load test, including the Oracle Load Testing system and each agent system.
Keep memory consumption for each workstation in the load test below 70-75% of the physical amount of memory in each workstation. That is, keep the number of virtual users below where page swapping of memory takes place.
The User Mode setting on the Build Scenarios tab of Oracle Load Testing affects the amount of memory overhead required for each Virtual User process (single or separate). Thick Client requires more system resources per Virtual User than Thin Client. Thin Client requires 350 KB to 500 KB per VU. Thick client can require anywhere from 1-2 MB to 10 MB depending on the application and the script size. The application being tested will also affect the memory requirements for virtual users depending upon the size of the Visual Script and design of the Web applications. Web applications using scripts or applets may require additional memory.
If you need to run more virtual users for your load test than CPU usage or memory limits provide for, you should add more physical memory to a system, or add additional agent systems.

You can use system performance monitoring tools, such as Performance Monitor or Task Manager in Windows 2000/2003, to determine system resource usage.

5.1.4 Managing Sessions

Sessions specify the scope for Oracle Load Testing data collection and reporting. The data collected while the Autopilot is running virtual users is shown in the virtual user grid, Oracle Load Testing ServerStats runtime performance statistics and load graphs, and can be saved to a database for post-testing analysis.

You can specify default settings for how sessions start and end data collection using Options from the Tools menu then selecting Session Start/Stop. Selecting this option opens the Session Start and Stop Options dialog box:

Define how a session starts - defines actions for a new session.

Save data for reporting - specifies if virtual user data is saved for real-time and post testing analysis reports. There are three options:
- No - the virtual user data is not saved. There will be no real-time or post-run graphs.
- Yes - the virtual user data is saved to the database. You can use Create Reports tab at a later time to generate reports and graphs for analysis.
- Ask - Oracle Load Testing prompts you to save the data each time you start a new Autopilot session.
Auto assign session name - when selected, the specified session name prefix, plus a four-digit increment number, is assigned when a new session starts.
Session Name Prefix - specifies a fixed name to add before the session name. Enter a name to use or "Default". Oracle Load Testing adds the increment number to the name you define. When set to "Default," the name is "session" (for example, session0001).

Define How a Session Ends - defines how a session ends. When a session ends, Oracle Load Testing stops updating runtime data in the performance statistics, load graphs, and the database (if Save data for reporting is used). Subsequent Autopilot runs start a new session for data collection and reporting purposes.

Stop session on last VU completion - when selected, the session ends when the last virtual user has finished the run in the Autopilot.
Stop attached session after browser closes - when there is an attached session, stops the session when the session timeout is reached after the browser is closed. When not checked and the browser is closed, the session continues to run until it's normal stopping time or until you reattach to the session and stop it manually. The default session timeout is ten minutes.
Terminate all agents at end of session - when selected, all Oracle Load Testing Agents automatically close when a session ends.

Agent error handling - defines how to handle agents that encounter errors.

Stop ramp-up on agent error - when selected, the autopilot stops submitting new virtual users if any virtual users fail to complete the initialization process. This may happen due to complications when starting the agent process or failures during e-Test script pre-run verification. This does not stop the test and previously running users continue to execute until the end of the session.
Drop failed agents from session - when selected, the autopilot stops submitting new users to the agent machine that had the failure if a virtual users fails to start or is set to orphaned for any reason.

5.1.5 Using the Data Bank Control

You can use the Data Bank Control to view Data Bank records and set Oracle Load Testing preferences.

Note:

If you have added the same profile to the scenario multiple times, the databank settings for the first instance of the profile in the scenario will apply to all instances of the profile in the scenario.

To use the Data Bank control:

Add a Visual Script or profile that uses a Data Bank to the Configure parameters of the scenario list.
Click the Edit Scenario Details button.
In the Main section, set the Use Data Bank field to True.
Select other Scenario Profile options as needed to configure how each Oracle Load Testing agent uses Data Bank records.
Click OK to exit the dialog box.
Click the Configure Data Bank button.

The Visual Scripts and Data Bank names are listed on the left. Select which Data Bank to view.

Data Bank Variables - shows the Data Bank variables, values, and types, as follows:
- Name - lists the names of the Data Bank variables.
- Value - list the values of the Data Bank variables.
- Type - shows the type of Data Bank variable: Internal, External, or Not Mapped.
Record Usage - lets you configure how the Data Bank is used.
- Set/View Record # - shows the current Data Bank record number. You can change the current record using the arrow buttons or by entering a record number and pressing Enter.
- Record buffer size - specifies the number of Data Bank records allocated to each Oracle Load Testing agent.
- Data Usage - lets you select which records to use.
  - Sequential - Use Starting Record Only - specifies that each virtual user takes the next record in the Data Bank and keeps on using that same record for each iteration. Use this setting if you want each virtual user to keep the same data for each iteration.
  - Sequential - Loop Records Continuously - specifies that the virtual users cycle through the Data Bank records until the load test finishes.
  - Unique - Stop After All records Used - specifies that the virtual users use all of the records in the Data Bank and then stop. For example, if the virtual users start at record 50 of 100, they run from 50 to 100, then loop back and run from record 1 to 49 and then stop.
  - Unique - Stop After Last Record Used - specifies that the virtual users stop when the end of the Data Bank has been reached regardless of the starting point in the Data Bank. For example, if the virtual users start at record 50 of 100 records, they run from record 50 to record 100 and then stop.
Make sure the script or profile is selected in the tree view.
Use the arrow buttons or enter a record number in the Set/View Record # field.
Click OK.

5.2 Using IP Spoofing

Oracle Load Testing can use IP spoofing to assign different IP addresses to virtual users. Each virtual user must get a defined IP address when using IP spoofing.

Before virtual users can use IP spoofing, you must define the IP addresses available for use by Oracle Load Testing in the TCP/IP network protocols of the workstation.

You define the IP addresses using the Advanced IP Addressing options of the TCP/IP properties of the Network Protocols. On Windows NT systems, the Network Protocols are accessed using the Control Panel, as follows:

The general procedure is as follows:

Open the TCP/IP Network Protocols.
In IP Address, select Specify an IP Address.
In the Advanced IP Address settings, add the IP Address and Subnet Mask.
Enter as many IP addresses/Subnet Masks as you have available for use by Oracle Load Testing virtual users.
Repeat the above steps on each Oracle Load Testing Agent system.
In the Edit Scenario Details dialog box, set Use IP Spoofing to True in the Browser Settings section.
If you are using WinInet, set the Maximum Users Per Process to one in the Advanced section.
Submit and Start the scenario in the Autopilot.

The virtual users on each Agent machine will use the defined IP addresses in the order they were defined in the TCP/IP network protocols. For example the first virtual user uses the first IP address (index value 0), the second virtual user uses the second IP address (index value 1), and so on. If there are more virtual users than available IP addresses, Oracle Load Testing loops back to the first IP address and goes through the list of IP addresses repeatedly until all virtual have been assigned an IP address.

Note:

Oracle Load Testing uses layering on the TCP/IP stack to perform IP spoofing with virtual users. While virtual users are running, the Oracle Load Testing layer is at the top of the TCP/IP stack. If an unusual event (for example, a restart) occurs while the system is running Oracle Load Testing virtual users with IP spoofing, other applications that use the TCP/IP stack may be affected. If this occurs, use regsvr32.exe to unregister the file sporder.dll.

5.3 Working with Scenario Files

Once you select virtual user profiles and set the attributes, you can save the Scenario to a file for future use. Oracle Load Testing automatically assigns the name LoadTest# for the scenario.

5.3.1 Saving Scenarios

To save a Scenario:

Select Save or Save As from the Scenario menu or click the toolbar button.

Repository - a list of repositories. Select the repository in which you want to save the scenario.

Workspace - lists the workspaces available in the selected repository.

<Scenario list> - lists the scenarios in the selected workspace.

Name - enter the name for the scenario.
If the Save As dialog box appears, specify a file name in the Name field.
Select the repository and workspace where you want to save the scenario.
Click OK.

Note:

Oracle Load Testing saves the current Autopilot settings as part of a saved scenario.

5.3.2 Opening Existing Scenarios

If you have previously defined a scenario and saved it to a file, you can open the scenario for use in Oracle Load Testing.

To open an existing Scenario:

Select Open from the Scenario menu. Oracle Load Testing opens a dialog for selecting the scenario file. Scenario files have a .scn filename extension.

Repository - a list of repositories.

Workspace - lists the workspaces available in the selected repository.

<Scenario list> - lists the scenarios in the selected workspace.
Select the Repository and Workspace containing the scenario you want to open.
Select the scenario and click OK.

5.3.3 Renaming Scenarios

To rename a scenario:

Select Scenario from the Manage menu to display the Scenario Manager.

Repository - a list of repositories.

Workspace - lists the workspaces available in the selected repository.

Edit - opens the Edit Scenario Dialog Box for editing the selected scenario.

Delete - deletes the selected scenario.

Name - lists the scenarios in the selected workspace.
Select the scenario you want to edit.
Click Edit to display the Edit Scenario dialog box.

Name - enter a name for the scenario.
Enter a new name for the scenario.
Click OK.
Click Close to exit the Scenario Manager.

5.3.4 Deleting Scenarios

To delete a scenario:

Select Scenarios from the Manage menu to display the Scenario Manager.

Repository - a list of repositories.

Workspace - lists the workspaces available in the selected repository.

Edit - opens the Edit Scenario Dialog Box for editing the selected scenario.

Delete - deletes the selected scenarios. To select more than one scenario, hold down the CTRL key.

Name - lists the scenarios in the selected workspace.
Select the scenarios you want to delete. To select more than one scenario, hold down the CTRL key.
Click Delete.
Click Yes to confirm the deletion.
Click Close to exit the Scenario Manager.

5.3.5 Removing Profiles From a Scenario

To remove profiles from the Scenario Profiles list:

If necessary, open a saved Scenario file.
Select the Build Scenarios tab.
Select the profile in the Configure parameters of the scenario list.
Click the Delete button.
Save the scenario by selecting Save from the Scenario menu.

5.3.6 Running Scenarios from the Command Line

You can run and stop scenario files using the command line Java file OLTCommandLine.jar located in the \lib directory under the installation directory. Use the following command syntax to start a scenario:

cd installdir\lib

OLTCommandLine.jar -run -scenarioFile=PATH_TO_OLT_SCENARIO_DIR\scenarioFile.scn -OLTServer=hostName:portnumber -user=username -password=password [-log=logfilename]

Use the following command syntax to stop a scenario:

cd installdir\lib

OLTCommandLine.jar -stop -session=sessionName -OLTServer=hostName:portnumber -user=username -password=password

The following are the command parameters:

run - Executes the selected scenario until the stop command is issued or the stop conditions specified in the scenario are reached.

scenarioFile - the scenario file to load. Specify the full path and file name of the scenario file. Scenario files have a .scn extension.

stop - shuts down the specified session. The Stop command is not required if the specified Scenario being run has a Stop condition of some defined time or number of iterations saved in the Autopilot settings.

session - specify the session to be shut down. The session name is automatically generated when you run the scenario. You can get the session name from the console or the log file specified with the scenario run command line parameters.

OLTServer - specify the Weblogic server name which hosts Oracle Load Testing. The port number is required.

user - specify the admin user name of the Weblogic server. The default username is "oats".

password - specify the admin user password of the Weblogic server.

log (Optional) - redirects console output to logfilename. Specify the path and file name to use for the log file.

5.3.6.1 Error Handling

If the OLT server is not running, an error will occur.

If the scenario file does not exist, an error will occur.

If the scenario file is not a correct xml, an error will occur.

5.3.6.2 Examples

The following example command line starts the test1 scenario:

cd C:\OracleATS\lib

OLTCommandLine.jar -run -scenarioFile="C:\OracleATS\OFT\Default!\test1.scn" -OLTServer=localhost:8088 -user=oats -password=password1 -log C:\OracleATS\OFT\Default!\mylog.log

The following example command line stops SESSION0001:

OLTCommandLine.jar -stop -session="SESSION0001" -OLTServer=localhost:8088 -user=oats -password=password1

5.4 Submitting Scenarios to Autopilot

Once you have defined a scenario and set the profile attributes, you submit the scenario to the Oracle Load Testing Autopilot.

5.4.1 Submit without Starting the Scenario

Submitting the scenario to the Autopilot without starting allows you to specify the start and stop times for running the scenario profiles.

To submit a Scenario without starting the Autopilot click the Add to Autopilot button.

Oracle Load Testing automatically opens the Autopilot tab with the scenario loaded.

5.4.2 Submit and Start Scenario in Autopilot

If you want to use the default Autopilot settings and start the Scenario, you can submit scenarios and automatically start the Autopilot in one step.

To submit a Scenario and start the Autopilot click the Run Test button.

Oracle Load Testing automatically opens the Autopilot tab with the scenario loaded and starts the virtual user run.