This chapter explains how to define scenario profiles based upon OpenScript scripts and Oracle Load testing profile properties.
Virtual user profiles are Oracle OpenScript scripts plus the specified Oracle Load Testing attributes. 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 OpenScript scripts, you can define Oracle Load Testing profiles to create scenarios to run performance and load testing on your Web pages or application.
To add script profiles to the Scenario list:
If necessary, open a saved Scenario file.
Select the Composer tab.
Select the repository and workspace containing the profile you want to add.
Select the script you want to add as a Virtual User profile in the Available Scripts list.
Note:
For databank settings to work properly, the name of the profiles added to the scenario should be unique.Click the Add button or drag the script name in the Available Scripts list to the Profile section.
If you add a password protected script to configure parameters in the Composer tab, the Import Script Password dialog box opens for specifying the script password. Enter the script password and click Validate to verify the password is correct.
Repeat steps 5 and 6 to add additional scripts to the Virtual User profile.
Once you select the scripts to include in the scenario, you can specify the Profile Properties for each one.
When finished adding scripts, click Ramp to specify the ramp-up, and stop settings for the scenario.
Click Goals to specify the test goals for the scenario.
Click Monitoring to specify ServerStats monitors for the scenario.
.Optionally, save the scenario.
To remove profiles from the Scenario Profiles list:
If necessary, open a saved Scenario file.
Select the Composer tab.
Select the profile in the Profiles list.
Click the Delete button.
Save the scenario by selecting Save from the Scenario menu.
Once you select the scripts to include in the scenario, you can specify the Scenario properties for each one.
To set the properties for a specific script:
If necessary, open a saved Scenario file.
Select the Composer tab.
Select the scripts to include in the Scenario.
Edit the properties in the Properties pane. The tabs in the Properties pane shows the settings for the script selected in the Profile pane. Select the script name in the Profile pane and set the properties. Note that the properties 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 Profile pane of the Composer tab. To specify which parameters are displayed in the Profile pane, select Options from the User menu then select Default Properties in the Profiles group and select the fields you want to display by selecting the Table View 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 properties.
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 and user defined profile to another.
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 Settings. Right click on the script or user defined profile that you want to copy the settings to and click Paste Settings.
The following are the settings for Load test-type profiles:
General - the main settings are as follows:
Max. # 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.
Agent 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.
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.Data Bank - the Data Bank load testing playback settings are as follows:
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.
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.
Sync Points Settings- the Sync Point settings are 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:
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.
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.
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 5.1.7, "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:
Generate Timers For Pages - when true, Oracle Load Testing automatically adds timers for each script page for reporting. The timers are used in Oracle Load Testing to provide performance monitoring and timing information for each page of the script played back by a scenario.
Generate Timers For 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.
Generate Timers For 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:
Maximu Users Per Process - sets the maximum number of virtual users per single agent process. When running virtual users as threads in a single process, Max 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.
Max 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.
Agent 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 to the database.
See Section 11.10, "Using Raw Data" for additional information about 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 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.
Secure Protocol - 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.
Ignored Url - ignores requests in the script that end with the extensions specified in this field. Specify the file extensions, separated by commas, that should not be requested. For example, .png,.ico,.gif,.jpg,.jpeg,.css,.js. This setting only applies to only to OpenScript load test 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
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, Ignore, or Report 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.
Report Error and Continue: Report 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.
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.
Encrypting/Decrypting Failed - specifies the error recovery action if an error occurs encrypting or decrypting a script.
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.
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.
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.
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.
The following are the settings for Functional test-type profiles:
General - the general settings are as follows:
Max # 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.
Agent 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.
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.
Dismiss Alerts 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).
Table Test - turns Table Test logging on and off. The default is off. This setting is specific to functional test scripts.
Object Test - turns XML 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.
XML Test - turns XML Test logging on and off. The default is off. This setting is specific to functional test scripts.
Reporting- the Reporting settings are as follows:
Generate Timers For 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.
Generate Timers For 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:
Agent 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 to the database.
See Section 11.10, "Using Raw Data" for additional information about 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.
Encrypting/Decrypting Failed - specifies the error recovery action if an error occurs encrypting or decrypting a 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.
Event Timeout - the Event Timeout settings for EBS/Forms are as follows:
Forms Startup Timeout - specifies the maximum number of seconds playback should wait for a form to appear before considering the form not found. This is the default timeout when waiting for a form to appear before invoking an action against it. This is also the default timeout when waiting for a form to appear before continuing the script.
Forms Action Timeout - specifies the maximum number of seconds Oracle Load Testing should wait for forms action playback until success.
Forms Response Timeout - specifies the maximum number of seconds playback should wait for forms response before timing out.
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, to determine system resource usage. See Section 4.3, "Estimating Hardware" for additional information about using the Oracle Load Testing Hardware Estimation tool.
Oracle Load Testing virtual users can play back scripts that access a Data Bank. You enable Data Bank access by selecting the Use Data Bank option in the Data Bank properties tab 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:
Select the Composer tab.
Add a script that uses a Data Bank to the Profile list.
Make sure the script or profile is selected in the Profiles panel.
In the Data Bank tab of the Properties pane, select the Use Data Bank option.
Select the Data Bank name to show the properties.
Specify the Range, Starting Record, and Databank Settings.
The Data Bank names are listed on the left. Select which Data Bank to view.
Preview - shows the Data Bank variables, values, and types, as follows:
Source - shows the path, name, type and number of records of the selected databank file.
Iterate Over Range - when selected, the virtual user uses the specified subset of records in the databank. Specify the first and last records to use for the range as the minimum and maximum values. The range includes both the starting and ending record in the specified range.
Start with Record - specifies which databank record to use first. The first record in a databank is 1. The starting record must be within the specified range of records. For example if you select Iterate Over Range and set the range to 5:10, the starting record must be at least 5, but not more than 10.
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 Next 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 Each User Iterates 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 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 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().
Each User Iterates 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 <b>Let Each User Iterate Over Records Independently</b> option may not be available.
Use the arrow buttons to change the record data.
Select other Scenario Profile options as needed to configure how each Oracle Load Testing agent uses Data Bank records.
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.
Click the Active Session tab and select the Sync Point Status sub-tab.
-or-
Click the Virtual User Status sub- 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 Profile Properties on the Composer tab, set Use IP Spoofing to True in the Browser Settings section.
Start the scenario.
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.You can use the Script Options to import and export scripts that have been exported from OpenScript as .zip files. This can be useful if you are accessing Oracle Load Testing on a remote machine via the Web UI and want to upload scripts from your local Oracle Functional Testing.
To import script.zip files:
Select Options from the User menu.
Select Scripts in the Manage group.
This dialog box lets you import and export script files from the local machine to the Oracle Load Testing server.
Import - opens the Choose File dialog box for browsing and selecting a file.
Export - opens the file dialog box for browsing and selecting a file location.
Click Import.
Enter the file name or click Browse to locate the file.
Click Open.
Click OK.
Click Upload.
To export script.zip files:
Select Options from the User menu.
Select Scripts in the Manage group.
Select the script you want to export.
Click Export.
Specify the file location and click OK.