This chapter explains how to define virtual user scenarios based upon the virtual user profiles.
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 scripts
type of user to simulate
object downloading
use of Data Banks
use of synchronization points
error handling for virtual users
setting up virtual users for viewing in the virtual user logs component
The following sections explain how to specify virtual user scenarios.
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 are Oracle OpenScript load testing scripts.
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.
Once you select the scripts to include in the scenario, you can specify the Scenario parameters for each one. To set the parameters for a specific script.
If necessary, open a saved Scenario file.
Select the Build Scenarios tab.
Select the scripts to include in the Scenario.
Click the Scenario Detail button to display the Edit Scenario Details dialog box. This dialog box shows the settings for the scripts in the current scenario. Select the script name in the left pane and set the settings. Note that the settings differ between load test-type (protocol based) scripts and functional test-type (DOM based) scripts.
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.Select the script or user defined profile that you want to edit from the list. See the preconditions for functional testing-type scripts in Section 3.1.2, "Preconditions for Using Functional Testing Scripts".
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.
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.
The following are the settings for Load test-type profiles:
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 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.
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 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 script playback delay for each virtual user. There are four options:
Recorded - uses the delay times that were recorded in the Oracle OpenScript script. You can set minimum and maximum delay times (in seconds) that override the 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 scripts at the fastest possible speed.
Note:
For OpenScript scripts, the VU Pacing overrides the times specified inthink() and beginStep() methods.Use Data Bank - when true, scripts that have Oracle OpenScript Data Banks will use the Data Banks as part of the virtual user playback. When false, 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 Download Pages - when true, downloaded pages are stored in a local cache and caching options are enabled. Caching places less of a load on the server as only newer pages are requested and brought down from the Web server. When false, caching is not used. No caching places more of a load on the Web server because pages and images are brought down from the Web server for every request.
Clear Cache After Iteration - when true, each Virtual User will clear its own cache after each iteration (after the script completes each iteration of its run()section).
Automatically (when page is out of date): when true, the web server is checked for newer versions if the page is out of date. The Web server is not checked for newer versions of unexpired cached pages. This setting behaves like the "Automatically" cache setting in Internet Explorer.
Every visit to the page: when true, the Web server is always checked for newer versions of all cached pages. This setting behaves like the "Every time I visit the web page" cache setting in Internet Explorer.
Maximum In-Memory Cache Size - specifies the maximum amount of in-memory storage to allocate for cached document contents. This setting applies to all virtual users in the process, even though each virtual user keeps its own cached documents. After the in-memory cache is exhausted, document contents will be cached to a temporary folder on disk in <installDir>\agent\cache. There is no upper bound on how much disk storage may be used to store cached documents. The disk cache is cleared every time the agent process starts. The default value is 128MB.
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. See Section 4.2, "Using IP Spoofing" for additional information.
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 OpenScript Text Matching and Server Response tests.
Virtual User Logs - the VU Logs settings are as follows:
Enable Logging - turns VU logging on and off. The default is on. When On, the Message Delivery and Logged Messages settings are also enabled.
Message Delivery - specifies when messages are delivered to the Virtual User log, as follows:
On Error - enables delivery of messages only when an error occurs. Using this a user can debug what happened on a particular step or transaction when an error occurred. All messages, as specified by the Logged Messages settings, for steps or transactions are cached an error occurs.
Always - all messages generated by Virtual Users will be logged.
Logged Messages - specifies the type of logged messages, as follows:
Standard - The standard messages consist of basic level messages which provide an overview of the chronological flow of a Virtual User. The types of messages included in this are as follows:
BeginPage -Logs the step-group (page) name, when VU starts a page.
FoundResource - Logs the resources' urls when download manager is turned on and discovers resources from pages.
ScriptError [Without stack trace] - Logs the script exception type and messages, when an OATS defined exception happens. It does not matter if the 'Error Recovery' settings handles it as 'warn' or 'ignore'. The name of the exception class is appended to "ScriptError" as a whole message type, for example, ScriptError<SolveException>
CachedData - Logs the cached resources' urls, when a VU requests on a cached resource (304 NOT MODIFIED or Found In Cache).
ThinkTime - Logs a message with the think time in seconds when a VU is in iteration delay, step delay, or manual delay.
SyncPoint - Logs whether a VU is suspended by a Sync Point or continues from a Sync Point.
Action - Logs the details of an action when a VU is navigating to a page (http), or executing a sql statement (util).
Extended - The extended messages consist of all the message types included in Standard plus selective inclusion of extended message types, which can have a substantial overhead. Selecting this option enables the selection of the previously excluded message types. All these message types or their groups are turned off by default. The extended message types or their groups are as follows:
Server Communication Content - Enables logging of all contents that are communicated with the server. For example, for an HTTP script it will consist of RequestHeader, ResponseHeader and ResponseContent.
Parameter Substitution - Enables logging of the variables name/value being substituted when parameters are transformed (messages of type ParameterSubstitution).
Error Stack Trace -Enables logging of messages of type ScriptError to be reported with the stack trace in the content.
User Defined Messages - Enables logging of the messages if API 'info()' , 'warn()', 'fail()', 'reportFailure()' methods are used (messages of type CustomizedLog).
Verification Notifications - Enables logging of the test type, test name, and test result of all types of verifications/tests (messages of type Verification).
Reporting- the Reporting settings are as follows:
Auto Generate Timers For All Step Groups - when true, Oracle Load Testing automatically adds timers for each OpenScript Step Group for reporting. The timers are used in Oracle Load Testing to provide performance monitoring and timing information for each Step Group the script(s) played back by a scenario.
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 OpenScript Download Manager section of the Scenario Defaults.
Error Handling - the Error Handling settings are as follows:
On Error Stop Virtual User - when true, a virtual user is stopped if an error is encountered.
Stop Remaining Iterations on Failure - when true, all 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.
Request Timeout - specifies the maximum amount of time a virtual user waits to access a page before timing out.
Connection Idle Timeout - specifies the socket 'idle timeout' and uses a new connection when reusing an idle-timeout socket. This is used to specify the timeout for a socket that gets closed by the server side after a long idle period.
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 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.)
Ignore HTTP Proxy Settings - specifies whether to ignore the agent machine's default proxy setting as defined in Internet Explorer.
Java Client Preferences - 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.
Persist Raw Data - when true, Oracle Load Testing saves every single measured data point in a set of CSV files. The files are saved locally on the agent machines in directories specified as follows:
<oats_install>/agent/rawdata/<controller-identifier>/<session_name>/<agent-id>/<YYYY-MM-DD HH:mm:ss>
See Section 6.9, "Using Raw Data" for additional information about the counter files and how to use the raw data.
Report Counters - when true, Oracle Load Testing counters are reported.
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, support for gzip compression is enabled. The browser Request includes the Accept-Encoding: gzip header indicating a gzip compressed page response will be accepted. If the server uses gzip compression, the response includes the Content-Encoding: gzip header indicating the returned page is in gzip compressed format. The browser unzips the compressed file before rendering the HTML page. Gzip compression is typically used to provide faster transfer of large HTML pages between the browser and the server.
Enable Deflate - when true, support for deflate compression is enabled. The browser Request includes the Accept-Encoding: deflate header indicating a deflate compressed page response will be accepted. If the server uses deflate compression, the response includes the Content-Encoding: deflate header indicating the returned page is in deflate compressed format. The browser inflates the compressed file before rendering the HTML page. Deflate compression is typically used to provide faster transfer of large HTML pages between the browser and the server.
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 protocol version to specify in the GET or POST request/response between client and server. The HTTP/1.0 protocol is an early implementation of the Hypertext Transfer Protocol. HTTP/1.1 is a standards-based enhancement to the HTTP/1.0 protocol. See the Key Differences between HTTP/1.0 and HTTP/1.1 at http://www8.org/w8-papers/5c-protocols/key/key.html
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, the connection request header is set to Connection: Keep-Alive. For HTTP/1.0, the socket connection is kept open until either the client or the server drops the connection. For HTTP/1.1 all connections are kept alive unless a Connection: close header is specified.
Preserve Connections Between Iterations - used to preserve connections between Virtual User agents and the browser between successive iterations of the script. Set to True if the browser should attempt to reuse any open browser connections if possible between iterations. Each virtual user maintains its own set of connections that it never shares with other virtual users. The default value is True, preserve connections between iterations.
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 Secure Socket Layer version to use for the proxy server. When recording a secure site in the browser, the user only sees the Proxy Recorder's certificate not the secure web site's certificate. The Browser, Proxy Recorder, and Secure Server each have their own private and public keys which are used to encrypt/decrypt data.
SSL: Use Secure Socket Layer protocol with the proxy server. OpenScript uses Sun Java Secure Socket Extension (JSSE). Sun JSSE by default supports SSLv2, ASSLv3, ASSL, ATLSv1, ATLS, and SSL_TLS.
SSL without TLS: Use Secure Socket Layer without Transport Layer Security. In some cases, a JSSE issue may cause a TLS Protocol connect failure. Use this option if a protocol connect failure occurs when using the SSL option.
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
Global Headers - specifies any custom "Global Headers" string to use in the Request header for script playback. The format is in the form: name1:value1;name2:value2;name3:value3. For example: x-oracle-slm-message-id: bcn=<beacon_name>; svc=<service_name>.
Replace URLs - specifies the URL replacement string in the form: originalURL1=replacementURL1,originalURL2=replacementURL2,[...]. During playback, anytime the agent makes a request to a URL starting with a segment, originalURL, the agent replaces the original URL segment with replacementURL. This feature is only supported for Load Test scripts.
originalURL - Specify the starting segment of the URL:port that appears in the script that should be replaced. This value is case-sensitive.
replacementURL - Specify the new starting segment URL:port that the agent requests instead of originalURL.
For both parameters, if the protocol is omitted, HTTP protocol is assumed. If no port is specified after the host, port 80 is assumed for HTTP protocol, and port 443 is assumed for HTTPS protocol. URLs are replaced after all correlations are applied. One or more URL replacement pairs may be specified, separating each replacement pair with a comma. The following examples show the format of Replace URLs strings:
test_server:7789=production_server:7789 test:7789=prod:7789,https://stage.oracle.com/main=https://prod.oracle.com/home
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 import 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.
Child Script Failed - specifies the error recovery action if an error occurs in a script that is a child of another script.
Unexpected Script Error - specifies the error recovery action if any unexpected script error occurs.
Call Function Failed - specifies the error recovery action if an error occurs in a script that calls a function of another script.
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.
OpenScript Download Manager - the OpenScript Download Manager settings are as follows:
Use OpenScript Download Manager - when true, the Download Manager is enabled during playback. When false, the Download Manager is not enabled during playback.
Ignored Urls (Using Regex): Specifies the Regular Expression(s) string to use to ignore specific resources. For example, the expression Login_Banner(.+?) would not download resources such as Login_Banner1.gif and Login_Banner2.gif. Multiple Regular Expressions can be separated using a comma (,).
CSS Resource - when true, css resources in <Link> tags are downloaded during playback. When false, css resources are not downloaded during playback.
Image Resource - when true, image resources in <Img> tags, in the "background" attribute of a tag, or in <style> tags with "background:url" patterns are downloaded during playback. When false, image resources are not downloaded during playback.
Embeded Object Resource - when true, object resources in <Embed> tags or in <Object> tags are downloaded during playback. When false, object resources are not downloaded during playback.
Script Resource - when true, script resources in <Script> tags are downloaded during playback. When false, script resources are not downloaded during playback.
Applet Resource - when true, applet resources in <Applet> tags are downloaded during playback. When false, applet resources are not downloaded during playback.
Forms LT Playback - the Oracle EBS/Forms load testing playback settings are as follows:
Capture Message Details: Specifies if forms message details are captured during playback. When selected, OpenScript captures and stores Forms message requests, responses, and information about all loaded Forms components during playback. This information is useful to have when debugging the script.
OpenScript displays captured details in the "Messages" and "Object Details" tabs of the Details view. Oracle Load Testing displays this information in the virtual user logs based on the "virtual user logs" settings.
Capturing message details is a memory-intensive operation. During heavy load testing, it is recommended to clear this setting to reduce the amount of heap space required by the agent.
Heart Beat Interval (sec): Specifies how often to check the connection to the EBS/Forms server.
Databank Configuration - the Databank Configuration load testing playback settings are as follows:
Databank Setup Timeout: Specifies how much time to spend preparing a databank for use before timing out. The value is in seconds. This setting includes the total time to do all of the following activities:
If using a Database-backed databank:
Connect to the database
Query
Read records, write into the file
Create the index simultaneously
Disconnect
If using a CSV-backed databank:
Time required to parse the CSV file and create the index
If using Random Unique:
Time to shuffle the index
Read Timeout - specifies the amount of time to wait for a databank read or get operation for a script at run-time before timing out.
The following are the settings for Functional test-type profiles:
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 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.
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 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 script playback delay for each virtual user. There are four options:
Recorded - uses the delay times that were recorded in the Oracle OpenScript script. You can set minimum and maximum delay times (in seconds) that override the 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 scripts at the fastest possible speed.
Note:
For OpenScript scripts, the VU Pacing overrides the times specified inthink() and beginStep() methods.Use Data Bank - when true, scripts that have Oracle OpenScript Data Banks will use the Data Banks as part of the virtual user playback. When false, scripts playback using the recorded data rather than the Data Bank.
Browser Settings- the browser settings are as follows:
Browser Type - specifies the type of browser to use for functional test scripts: Internet Explorer or Firefox. The default is Internet Explorer on Windows. The default is Firefox on Linux. This setting is specific to functional test scripts.
Browser Path Override - specifies tan alternative path to use when launching the specified browser type. Explorer and Firefox browser processes physically exist in the file system. In case the path to one of these browsers is incorrect, specify an alternative path to use when launching the specified browser type. This setting is not intended to be used to specify the path to an unsupported browser. This setting is specific to functional test scripts.
Browser Additional Arguments - specifies any additional startup arguments that should be used when launching the browser process on playback. The default is no additional arguments other than what may be required internally. This setting is specific to functional test scripts.
Resolution Size - specifies the screen resolution of the playback agent machine. Functional test scripts with mouse-click actions and screenshot capturing are dependent upon this setting. This setting is specific to functional test scripts.
Automatically dismiss Javascript alert dialogs - specifies if JavaScript alert dialog boxes are automatically dismissed if they appear during playback. The default is false; do not automatically dismiss alert dialogs.
Virtual User Logs - the VU Logs settings are as follows:
Enable Logging - turns VU logging on and off. The default is on. When On, the Message Delivery and Logged Messages settings are also enabled.
Message Delivery - specifies when messages are delivered to the Virtual User log, as follows:
On Error - enables delivery of messages only when an error occurs. Using this a user can debug what happened on a particular step or transaction when an error occurred. All messages, as specified by the Logged Messages settings, for steps or transactions are cached an error occurs.
Always - all messages generated by Virtual Users will be logged.
Logged Messages - specifies the type of logged messages, as follows:
Standard - The standard messages consist of basic level messages which provide an overview of the chronological flow of a Virtual User. The types of messages included in this are as follows:
BeginPage -Logs the step-group (page) name, when VU starts a page.
FoundResource - Logs the resources' urls when download manager is turned on and discovers resources from pages.
ScriptError [Without stack trace] - Logs the script exception type and messages, when an OATS defined exception happens. It does not matter if the 'Error Recovery' settings handles it as 'warn' or 'ignore'. The name of the exception class is appended to "ScriptError" as a whole message type, for example, ScriptError<SolveException>
CachedData - Logs the cached resources' urls, when a VU requests on a cached resource (304 NOT MODIFIED or Found In Cache).
ThinkTime - Logs a message with the think time in seconds when a VU is in iteration delay, step delay, or manual delay.
SyncPoint - Logs whether a VU is suspended by a Sync Point or continues from a Sync Point.
Action - Logs the details of an action when a VU is navigating to a page (http), or executing a sql statement (util).
Extended - The extended messages consist of all the message types included in Standard plus selective inclusion of extended message types, which can have a substantial overhead. Selecting this option enables the selection of the previously excluded message types. All these message types or their groups are turned off by default. The extended message types or their groups are as follows:
Server Communication Content - Enables logging of all contents that are communicated with the server. For example, for an HTTP script it will consist of RequestHeader, ResponseHeader and ResponseContent.
Parameter Substitution - Enables logging of the variables name/value being substituted when parameters are transformed (messages of type ParameterSubstitution).
Error Stack Trace -Enables logging of messages of type ScriptError to be reported with the stack trace in the content.
User Defined Messages - Enables logging of the messages if API 'info()' , 'warn()', 'fail()', 'reportFailure()' methods are used (messages of type CustomizedLog).
Verification Notifications - Enables logging of the test type, test name, and test result of all types of verifications/tests (messages of type Verification).
Object Test - turns XML Test logging on and off. The default is off. This setting is specific to functional test scripts.
XML Test - turns XML Test logging on and off. The default is off. This setting is specific to functional test scripts.
Table Test - turns Table Test logging on and off. The default is off. This setting is specific to functional test scripts.
Screenshot - turns Screenshot logging on and off. The default is off. This setting is specific to functional test scripts.
Reporting- the Reporting settings are as follows:
Auto Generate Timers For All Step Groups - when true, Oracle Load Testing automatically adds timers for each OpenScript Step Group for reporting. The timers are used in Oracle Load Testing to provide performance monitoring and timing information for each Step Group the script(s) played back by a scenario.
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 OpenScript Download Manager section of the Scenario Defaults.
Error Handling - the Error Handling settings are as follows:
On Error Stop Virtual User - when true, a virtual user is stopped if an error is encountered.
Stop Remaining Iterations on Failure - when true, all remaining iterations for a virtual user are stopped if an error is encountered.
Advanced - the Error Handling settings are as follows:
Password for Windows Account/Linux VNC - specifies a password to use to login to the Windows Remote Desktop or Linux VNC viewer for functional test scripts. For Windows agent systems, a Windows account will be created on that system automatically. If not specified, the password of the account will be random. If you want to login to the RDP session in case some error happened or want the playback in the RDP sessionscan, you need to configure a general password in this setting. You will not be able to login to the RDP session after the load test, because RDP sessions together with Windows account will be killed and removed.
For each Linux VUser/Agent process started, 'Agent Manager' will startup one VNC server automatically. If not specified, the password of the display will be random. If you want to login to the display, install VNC viewer and specify the general password for the displays in this setting. You will not be able to login to the display after the load test, because VNC server will be killed along with the Firefox browser. When concurrent VUs are running, the VNC server can only be started up one by one. So from the Oracle Load Testing standpoint, the VUs will not ramp-up at the same time.
Object Timeout - specifies the maximum time to wait for an object to download before timing out.
Java Client Preferences - 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.
Persist Raw Data - when true, Oracle Load Testing saves every single measured data point in a set of CSV files. The files are saved locally on the agent machines in directories specified as follows:
<oats_install>/agent/rawdata/<controller-identifier>/<session_name>/<agent-id>/<YYYY-MM-DD HH:mm:ss>
See Section 6.9, "Using Raw Data" for additional information about the counter files and how to use the raw data.
Report Counters - when true, Oracle Load Testing counters are reported.
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.
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.
Replace URLs - specifies the URL replacement string in the form: originalURL1=replacementURL1,originalURL2=replacementURL2,[...]. During playback, anytime the agent makes a request to a URL starting with a segment, originalURL, the agent replaces the original URL segment with replacementURL. This feature is only supported for Load Test scripts.
originalURL - Specify the starting segment of the URL:port that appears in the script that should be replaced. This value is case-sensitive.
replacementURL - Specify the new starting segment URL:port that the agent requests instead of originalURL.
For both parameters, if the protocol is omitted, HTTP protocol is assumed. If no port is specified after the host, port 80 is assumed for HTTP protocol, and port 443 is assumed for HTTPS protocol. URLs are replaced after all correlations are applied. One or more URL replacement pairs may be specified, separating each replacement pair with a comma. The following examples show the format of Replace URLs strings:
test_server:7789=production_server:7789 test:7789=prod:7789,https://stage.oracle.com/main=https://prod.oracle.com/home
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 - 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.
Child Script Failed - specifies the error recovery action if an error occurs in a script that is a child of another script.
Call Function Failed - specifies the error recovery action if an error occurs in a script that calls a function of another script.
OpenScript Error Recovery - Functional Test - the Functional Test Module Error Recovery settings are as follows:
Text Matching Failed - specifies the error recovery action if a text matching test error occurs.
Object Test Failed - specifies the error recovery action if an Object test error occurs.
Table Test Failed - specifies the error recovery action if a Table test error occurs.
XML Test Failed - specifies the error recovery action if an XML test error occurs.
OpenScript Error Recovery - Web Functional Test - the Web Functional Test Module Error Recovery settings are as follows:
Response Time Error - specifies the error recovery action if a Response time error occurs.
Solve Variable Failed - specifies the error recovery action if a Solve Variable error occurs.
Wait for Page Timeout - specifies the error recovery action if a Wait for Page Timeout occurs.
Object Not Found - specifies the error recovery action if an Object Not Found error occurs.
Playback Failed - specifies the error recovery action if a Playback Failed error occurs.
Title Test Failed - specifies the error recovery action if a Title Test Failed error occurs.
HTML Test Failed - specifies the error recovery action if a Title Test Failed error occurs.
OpenScript Error Recovery - Oracle Forms Functional Test - the Oracle Forms Functional Test Module Error Recovery settings are as follows:
Oracle Forms Error - specifies the error recovery action if an Oracle Forms error occurs.
Status Bar Test Error - specifies the error recovery action if a Status Bar Test error occurs.
Databank Configuration - the Databank Configuration load testing playback settings are as follows:
Databank Setup Timeout: Specifies how much time to spend preparing a databank for use before timing out. The value is in seconds. This setting includes the total time to do all of the following activities:
If using a Database-backed databank:
Connect to the database
Query
Read records, write into the file
Create the index simultaneously
Disconnect
If using a CSV-backed databank:
Time required to parse the CSV file and create the index
If using Random Unique:
Time to shuffle the index
Read Timeout - specifies the amount of time to wait for a databank read or get operation for a script at run-time before timing out.
Cache and Cookies - the Cache and Cookies settings are as follows:
Clear Cache Before Playback - specifies if the browser cache is cleared before script playback begins.
Clear Cache Between Iterations - specifies if the browser cache is cleared between each playback iteration.
Clear Session Cookies Before Playback - specifies if the session cookies are cleared before script playback begins.
Clear Session Cookies Between Iterations - specifies if the session cookies are cleared between each playback iteration.
Clear Persistent Cookies Before Playback - specifies if the persistent cookies are cleared before script playback begins.
Clear Persistent Cookies Between Iterations - specifies if the persistent cookies are cleared between each playback iteration.
The number of virtual users that can run reliably and provide accurate performance data for your application depends upon several factors:
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.
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. See Section 4.3.7, "Estimating Hardware" for additional information about using the Oracle Load Testing Hardware Estimation tool.
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.
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. 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 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.
Oracle Load Testing virtual users can play back scripts that access a Data Bank. You enable Data Bank access by setting the Use Data Bank option to True in the Edit Scenario Details dialog box for the selected virtual user profile. The virtual user must use a script that is configured in OpenScript with a Data Bank asset.
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 script or profile that uses a Data Bank to the Configure parameters of the scenario list.
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 scripts and Data Bank names are listed on the left. Select which Data Bank to view.
Databank Source - this section shows the following information about the selected databank:
Type - shows the type of the selected databank file. Databanks can be CSV text files or databases.
Source - shows the path and filename of CSV text files or the database source of database databanks. While there is not a maximum file size, the recommended maximum sizes is 200 MB. The only limitation is how long it takes to generate the index. The databank must be indexable within 30 seconds, by default. This setting is configurable in the "Databank Timeout" setting in the General Options. See Section 3.14.8, "Setting General Options" for additional information about setting the Databank Timeout.
Records - shows the number of records in the databank.
Preview - 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.
Databank Settings - this section specifies the settings to use for the selected databank:
Advance to Next Record - specifies when the virtual user should advance to the next databank record during script playback. The following options are available:
When Script Requests a Record - the databank record advances every time a script explicitly requests a record during script playback. A record request corresponds to the script Java code calling the getDatabank(alias).getNextRecord() method. This is the default behavior.
Each Iteration of Script - the databank record advances before a script containing the databank starts another playback iteration.
Each Occurrence - the databank record advances when a script refers to a databank column (i.e. databank field) in the script. A record request corresponds to the script Java code evaluating a parameterized value such as {{db.fmstocks_data.ticker}}. For example, if you have an employee databank with a firstName field and the firstName column is specified as the Column value in the OpenScript script, the databank record advances only when the {{db.employees.firstName}} value in the script Java code is evaluated on script playback.
Keep the First Record Assigned - the databank record does not advance once a virtual user gets a record from the databank, it uses that record forever and never requests another record. This option applies to scenarios running more than one virtual user. Virtual users may still request an individual record using getRecord(n), getLastRecord(), or getFirstRecord().
Select Next Record - specifies how a new record is selected from the databank when the databank record advances. The following options are available:
Sequentially - the databank records increment one by one in sequential order from the start of the specified range. When multiple virtual users are running, records are distributed in sequential order across all virtual users.
Random - the databank records are selected at random from the databank. The same record may be used multiple times before all records are exhausted. Random record selection is only provided for databanks that can be indexed. When configuring databank settings, if the databank file is too large to index, the Random or Shuffle options may not be available. The When Out of Records and Let Each User Iterate Over Records Independently settings do not apply when Random is selected.
Shuffle - the databank records are selected at random from the databank ensuring that once a record is selected, it is never selected again. The setting works similar to selecting a random card from a deck until no cards are left. Shuffle mode only supports databanks containing fewer than 200,000 records. For databanks containing more than 200,000 records, you can shuffle the values in the actual data file or you should use the Random mode.
Use Seed - specifies a randomization seed value to use when using the Random or Shuffle modes. Use the same seed across multiple tests to create the same sequence of random numbers for all tests. If 0 or not specified, a seed is generated automatically based on the current time.
When Out of Records - specifies the action the virtual user takes if all databank records in the specified range have been used and a new record is requested. The following options are available:
Loop Over Range - loops back to the first record in the range after all records in the range are used and continues distributing records. Use the Maximum Iterations settings to prevent the virtual user from running forever.
Stop the User - the virtual user immediately stops running the next time a record is requested from the databank after all records in the range are used. The virtual user will stop regardless of how many iterations are specified by the Maximum Iterations settings.
Keep the Same Record - continues to use the last record requested after all records in the range are used. No additional records are requested from the databank. Any calls in the Java code to getNextDatabankRecord() are ignored after all records are used. Custom Java code may be used in the script to have Virtual users request an individual record using getRecord(n), getLastRecord(), or getFirstRecord().
Let Each User Iterate Over Records Independently - when selected, each Virtual User cursors through records independently. For example, VU 1 gets records 1, 2, 3, [...] and VU 2 gets records 1, 2, 3, [...]. This option only applies for scenarios running more than one virtual user.
This option only applies for databanks that can be indexed. When configuring databank settings, if the databank file is too large to index, the Let Each User Iterate Over Records Independently option may not be available.
Make sure the script or profile is selected in the tree view.
Use the arrow buttons to change the record data.
Click OK.
A sync point allows multiple virtual users to synchronize their actions and interactions with the application under test. Sync points provide the ability to create realistic multi-user situations that may expose resource conflicts such as deadlocks. When you specify a sync point, multiple virtual users executing the script will reach this sync point at various times depending on a number of factors (for example, the speed of the machine).
Sync points cause each virtual user to wait until all virtual users have reached that sync point. Each of the virtual users notifies the master upon reaching the sync point. The master waits for all of the virtual users to notify it and then issues the go-ahead for all the virtual users to continue past that sync point.
Sync points are added to individual scripts (parent or child scripts) when they are created in OpenScript. The execution parameters for sync points are defined in the Oracle Load Testing application.
To add a sync point to an OpenScript script:
Create or open a script in OpenScript.
Select the script node were you want to add the sync point.
Select Add from the Script menu then select Other.
Select the Synchronization Point node and click OK.
Enter a name for the synchronization point and click OK.
Save the script in OpenScript.
To define the sync point execution parameters in Oracle Load Testing:
Start Oracle Load Testing.
Select the script with the sync point and add it to the scenario.
Click the Configure Sync Point icon.
Expand the script name, select the name of the sync point in the left pane, and specify the execution parameters for the sync point in the right pane, as follows:
Name - specifies the name of the Synchronization point. This is the same name as specified for the sync point in the OpenScript script.
Group type - specifies how to determine when to release virtual users based on the following options:
All users in scenario - calculates when to release virtual users based on all virtual users whether or not they are running.
Running users - calculates when to release virtual users based on the number of running users only.
Release trigger - specifies the percentage of virtual users that must be waiting before they are released. For example, if ten virtual users are running and the release trigger is set to fifty percent, then the waiting virtual users are released when five of them are waiting. Setting the value greater than one hundred percent causes the virtual users to wait until they are manually released.
Open gate time - specifies the amount of time to keep the release open after it has been triggered.
Maximum Wait - specifies, per individual virtual user, the maximum amount of time, in seconds, that the synchronization point will wait before releasing the virtual user.
Repeat these steps to specify the execution parameters for other sync points in the same or other scripts.
Click the OK button when you have finished specifying sync point execution parameters. The sync point execution parameters will be saved as part of the virtual user scenario.
To check the sync point status or release sync points for running virtual users:
Start a virtual user scenario with one or more scripts containing sync points.
Select Sync Point Status from the Tools menu.
-or-
Click the Watch VU Grid tab and right-click on a running virtual user.
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.
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.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 Scenario### for the scenario.
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.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.
File Type - specifies the type of scenario file to open.
Scenario - specifies a scenario that has been save using the Save As option on the Scenario menu. Scenario files have a .scn filename extension.
Self Contained Scenario - specifies a scenario saved as a self contained zip file using the Export option on the Tools menu. Self Contained Scenarios can include recorded data, playback results, and databanks. Scenario files have a .scnzip 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.
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.
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.
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.
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 -session=sessionName -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.
session - specifies the name to use for the session. If you do not do not provide a session name, Oracle Load Testing generates a session name.
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. You can not use both "-Run" and "-Stop" in the same command.
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.
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.
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
The Hardware Estimation tools provide ways for you to get an estimate of the amount of hardware that will be required to run an Oracle Load Test session for a given scenario.
The quick estimate is a simple, quick and quite accurate solution for estimating the hardware requirements of an OpenScript script that will be used as a Virtual User in an Oracle Load Test scenario.
The estimate process consists of the following:
Running a script in no delay mode and collecting hardware consumption data (CPU/Memory/Network) for only one VU for a short period of time.
Measuring the CPU and Memory consumption data of a VU
Deducing hundreds or thousands of VUs running concurrently with simulated think time.
Estimating the hardware requirements of the specified number of VUs based on the deduction result.
To run a hardware estimate:
Add scripts to the Build Scenarios tab and save the scenario.
Select Hardware Estimation from the Tools menu.
Select the Repository and workspace folder in which the scenario file is located.
Select the scenario to use for the hardware estimate session.
Click Estimate to start a hardware estimation session for the selected scenario. A background session and local agent start and run one Virtual User for the selected scenario.
When the estimation finishes, click View Report to view the results.
To run a hardware estimate report for an Oracle Load testing scenario:
Make sure you have generated a Hardware Estimation using the Hardware Estimation option on the Tools menu.
Click the Create Report tab.
Click the Reports tab.
Select Estimation Report from the Report list.
Select the Repository and workspace folder in which the report is located.
Select the Scenario report and click Generate to generate the Hardware Estimation report.
The Hardware Estimation Report provides the following:
Hardware configuration for each agent, including CPU information, memory size, and network bandwidth limitations.
Process Runtime Configuration for each agent, including Operating System information, Max Virtual Users per Process setting, and Max heap size setting.
Estimated consumption for each script running on the corresponding agent, including CPU usage, heap size usage, and network bandwidth usage.
Suggested Configuration, including idle resources monitored before start estimation, estimated number of required machines, and suggested configurations for better performance.
Once you have defined a scenario and set the profile attributes, you submit the scenario to the Oracle Load Testing Autopilot.
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.
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.
Perform baseline for Oracle DB - specifies if an Oracle Database snapshot is taken before the load test session. This option only appears if the session has a ServerStats configuration with Oracle Database Metrics applied when load test is launched. Oracle metrics are identified by the database driver connection properties. If you add an Oracle Database metric after the load test is running, there is no way to take snapshots during the load test. The following options are available:
No - no database snapshot will be taken during the load test.
Yes - a database snapshot and baseline will be created during the load test. An Oracle Database "snapshot" is a PL/SQL call that causes the database to record a timestamp during the gathering of performance data. A "baseline" is a PL/SQL call that uses the ID of two snapshots, which causes the data recorded between the snapshots to be persisted indefinitely rather than expiring after a user-configured persistence interval (the default is 8 days). The snapshot and baseline allow you to retrieve Enterprise Manager drilldown information for a load test session long after the session has been run. When Yes is selected, two snapshots - one at the beginning and one at the end of a load test session - and a baseline cause the data gathered during the session to be persisted indefinitely.