Skip Headers
Oracle® Application Testing Suite OpenScript User's Guide
Version 9.10 for Microsoft Windows (32-Bit)

Part Number E15488-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

3 Creating and Modifying Scripts

This chapter explains the procedures for creating and modifying basic scripts in OpenScript. The module chapters provide additional information about creating scripts using the features and capabilities provided within specific modules.

3.1 Creating Repositories and Workspaces

Repositories and workspaces store project related script files and results log files. You can use repositories and workspaces to organize your various testing projects. OpenScript lets you create multiple workspaces.You can create repositories to organize the storage of your script projects.

Note:

As of OpenScript Version 9.10, scripts can be stored anywhere in the file system. However, any scripts you plan to run, along with any associated assets, in the Oracle Load Testing application must be stored in a repository/workspace.

A repository is the directory location where you store workspaces. Workspaces are user-specified subdirectories of the repository. As of version 9.10, OpenScript no longer uses an exclamation point at the end of the directory name to identify the directory as a Workspace directory. Any folder (directory) below the specified repository can be a workspace folder.

When you record and save scripts, or play back a script and save the log file, OpenScript stores the script or log file in the specified Workspace.

The OpenScript installation creates a default repository in C:\Documents and Settings\username\osworkspace\Repositories\<machinename>.<usernamename>.Default. You can create your own repositories and workspaces using OpenScript.

3.1.1 Creating a Repository

To create a repository:

  1. Select OpenScript Preferences from the View menu.

  2. Expand the OpenScript node.

  3. Expand the General node.

  4. Select the Repository node.

  5. Click Add.

    This dialog box lets you specify the name and location of the repository to use to store script files.

  6. Enter a repository name. The name is required.

    Name: Enter any name to identify the repository.

    Note:

    If you plan to use OpenScript scripts with Oracle Load Testing, the repository names you specify should match the repository name specified in Oracle Load Testing (including case).
  7. Enter the drive and directory location or click Browse to select the location to use for the repository.

    Location: Enter the drive and directory path to the repository or use the Browse button to select a location. The location must be a valid drive and directory path.

  8. Click OK to add the new repository to the list of repositories.

  9. Click OK to close the preferences.

When you create new a script project, you can select the repository to use to store the project.

3.1.2 Managing Repositories

To add, edit, or delete repositories:

  1. Select Manage Repositories from the Tools menu.

  2. Select the repository where you want to create the workspace.

  3. Click the Add, Edit or Delete buttons to manage repositories.

  4. Click Close when finished.

3.1.3 Managing Folders

When starting a new testing project, you should create a project-specific Workspace or file folder to store related files.

To create, rename, or delete workspaces or file folders:

  1. Select Manage Folders from the Tools menu. OpenScript opens a dialog box for managing file folders and workspaces in repositories.

  2. Expand the tree and select the workspace or file folder to manage.

  3. Click New, Rename, or Delete buttons to manage workspaces or file folders.

  4. Click Close when finished.

3.1.4 Managing Scripts

To rename or delete scripts:

  1. Select Manage Scripts from the Tools menu.

  2. Select the script.

  3. Click the Rename or Delete buttons to manage script files.

  4. Click Close when finished.

3.2 Creating a Script Project

You must create a script project to generate the basic structure that you can then customize.

To create a script project:

  1. Select New from the File menu.

  2. Expand a group node and select the type of asset or script to create:

    Functional Testing (Browser/GUI Automation): The Functional Testing group contains the following script types:

    • Oracle Fusion/ADF: This option lets you create a new script for automated functional testing of Oracle Application Development Framework (ADF)-based applications and other applications that utilize Web and ADF components at the browser/gui level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded Web navigations based upon the defined Step Group preferences and the Web navigations and ADF actions performed during recording. You can edit the script tree or Java code to customize the script.

    • Oracle EBS/Forms: This option lets you create a new script for automated functional testing of Oracle E-Business Suite and other applications that utilize Web and Oracle Forms components at the browser/gui level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded Web navigations based upon the defined Step Group preferences and the Web navigations and Forms actions performed during recording. You can edit the script tree or Java code to customize the script.

    • Siebel: This option lets you create a new script for automated functional testing of Siebel applications that utilize Siebel High Interactivity and Standard Interactivity/Web controls at the browser/gui level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded Web navigations based upon the defined Step Group preferences and the Web navigations performed during recording. You can edit the script tree or Java code to customize the script.

    • Web: This option lets you create a new script for automated functional testing of Web applications at the browser/gui level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded Web navigations based upon the defined Step Group preferences and the Web navigations performed during recording. You can edit the script tree or Java code to customize the script.

    General: The General group contains the following script types:

    • Java Code Script: This option lets you create a new automated test script using your own custom Java code through the OpenScript Eclipse IDE. A basic script structure contains only the Initialize, Run, and Finish nodes. You can edit the script tree or Java code to develop your own custom script.

    • Web Services: This option lets you create the basic structure of a Web Services script a new script for automated testing of Web Services at the SOAP/HTTP protocol level. A Web Services script structure contains only the Initialize, Run, and Finish nodes. You can use the WSDL Manager to add WSDL files and edit the script tree or Java code to customize the script. If you have a Web Services client application written already that communicates over HTTP and which communicates through a proxy, you can record the traffic using the OpenScript HTTP recorder.

    Load Testing (Protocol Automation): The Load Testing group contains the following script types:

    • Oracle Fusion/ADF: This option lets you create a new script for load testing of Oracle Application Development Framework (ADF)-based applications and other applications that utilize HTTP and ADF protocols at the protocol level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded HTTP protocol navigations based upon the defined Step Group preferences and the navigations and ADF protocol for actions performed during recording. You can edit the script tree or Java code to customize the script.

    • Oracle EBS/Forms: This option lets you create a new script for load testing of Oracle E-Business Suite and other applications that utilize HTTP and Oracle Forms (NCA) protocols at the protocol level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded HTTP protocol navigations based upon the defined Step Group preferences and the navigations and Forms protocol for actions performed during recording. You can edit the script tree or Java code to customize the script.

    • Siebel This option lets you create a Siebel script structure of a new OpenScript script project. A Siebel script lets you record Siebel Web navigations using a browser for load testing Siebel applications. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded HTTP protocol navigations based upon the defined Step Group preferences and the Web and Siebel navigations performed during recording. You can edit the script tree or Java code to customize the script.

    • Web/HTTP This option lets you create a new script for load testing of Web Applications at the HTTP protocol level. The resulting script will contain the Initialize, Run, and Finish nodes. The Run node will contain recorded Web navigations based upon the defined Step Group preferences and the Web navigations performed during recording. You can edit the script tree or Java code to customize the script.

    Script Asset: The Script Asset group contains the following script asset types:

    • Databank: This option lets you create a new databank or open an existing databank file. The new asset wizard lets you navigate to the databank file location of an existing databank file or enter the name of a new databank file. When you click Finish in the wizard, the existing or new databank file opens in a text editor view.

    • Object Library: This option lets you create a new Object Library or open an existing Object Library. The new asset wizard lets you navigate to the Object Library file location of an existing Object Library file or enter the name of a new Object Library file. When you click Finish in the wizard, the existing or new Object Library file opens in the Object Library editor view.

  3. Click Next.

  4. Select the location where you want to store the script project. As of OpenScript version 9.10, scripts can be stored in repositories and workspaces or anywhere else in the file system. However, load test scripts developed for use with Oracle Load Testing must be stored in a repository/workspace.

    • Path: Shows the file path of the selected repository/workspace or file folder.

    • My Repositories: Specifies the repository where the script project will be saved. Select a repository and workspace from the tree. Repositories can be managed using Manage Repositories on the Tools menu.

    • My Computer: Specifies the file folder location on the computer where the script project will be saved. Select a drive and folder from the tree.

    • [file list]: List the names of the existing files or scripts in the selected repository/workspace or file folder.

    • Script: Specify a name for the script project. The script name is required and must be unique.

  5. Enter a script name.

  6. Click Finish. For Java Code Scripts, a basic script tree will be created in the script view. You can edit the Java code in the code view. For module scripts, a script tree will be created in the script view. After you record the script, the tree view will contain the navigations and actions depending upon the type script.

3.2.1 Opening Existing Scripts

The introduction of Script Assets (in Script Properties) requires pre-version 9.10 scripts to be migrated to the current version of 9.10 or higher. This section provides information about backwards compatibility of OpenScript scripts and upgrading OpenScript scripts.

Scripts created in older versions of OpenScript will always run in new versions of the product without modification from the command-line, Oracle Load Testing, and Oracle Test Manager.

Older OpenScript scripts may not be opened or played back in the newer version of the OpenScript User Interface without upgrading them first.

Previously published script API functions are supported in the latest release. Some published API may be marked as deprecated, but will still work in the new release in order to maintain backwards compatibility.

3.2.1.1 Opening Older Scripts in OpenScript

OpenScript requires that scripts be upgraded to the latest release in order to open them in the OpenScript User Interface. You are not required to upgrade a script to the new version unless you want to open the script in the OpenScript User Interface. Older versions of OpenScript scripts can be run without modification from the command-line, Oracle Load Testing, and Oracle Test Manager.

Caution:

Version 9.10 and higher scripts cannot be played back in earlier versions of OpenScript, Oracle Load Testing, and Oracle Test Manager. If you want to maintain pre-version 9.10 scripts, you should make a back up copy of your scripts before opening and saving them in version 9.10 or higher. OpenScript automatically migrates any pre-version 9.10 scripts when the script is opened and saved in OpenScript version 9.10 or higher.

OpenScript automatically prompts you to upgrade older version scripts to the current version whenever the script is opened in the OpenScript User Interface. When opening an older script, you can choose not to open the script and the script will not be upgraded.

When prompted to upgrade a script, if the script depends on any child scripts or function libraries, OpenScript provides an option to upgrade the child scripts or function libraries to the new version also.

Once a script is upgraded to a new release, the script cannot be opened or run using older versions of Oracle Application Testing Suite (OpenScript, Oracle Load Testing, or Oracle Test Manager).

3.2.1.2 Migrating Older Scripts in OpenScript

If you wish to upgrade scripts without opening them individually in OpenScript, you can use the Migrate Scripts upgrade option on the Tools menu. The Migrate Scripts tool lets you migrate pre-version 9.10 scripts to the current version without having to open scripts individually.

The Migrate Scripts tool provides options for migrating top-level scripts and locating all dependent child scripts. The Migrate Scripts tool lets you select which scripts to migrate to the current version and find any child scripts that also need to be migrated.

Version 9.10 does not permit absolute paths for repositories or script assets in scripts that will be used with Oracle Load Testing. However, version 9.0x scripts permitted absolute paths. If your version 9.0x scripts use absolute paths, you can run the version 9.0x scripts, unmodified, in version 9.10 Oracle Load Testing. As soon as you upgrade the 9.0x scripts to 9.10 in the OpenScript User Interface or the Migrate Script tool, the script will not playback in Oracle Load Testing until the absolute paths are changed to relative paths. The Migrate Scripts tool does not migrate absolute paths to relative paths or to repository paths. The absolute paths must be changed in the scripts.

3.2.1.3 Running Mixed Versions of Scripts

You are advised not to run mixed versions of "job" scripts where a parent script calls child scripts or function libraries. This may happen in cases where you may have 9.1x "parent" scripts that run 9.0x "child" scripts or function libraries. Although this configuration has been tested and is supported, the combination of mixed versions scripts may lead to unpredictable results and some confusion as to which scripts are the latest version. In addition, mixed version job scripts may not be able to take advantage of certain new version 9.10 improvements, such as:

  • Version 9.10 provides an option to visually inspect and add child script functions into a parent script. If child scripts are not upgraded to 9.10, OpenScript will not display their available functions in the user interface options.

  • Version 9.10 scripts no longer require that parent scripts add all child script databanks as their own databanks. If child scripts are not upgraded to 9.10, then parent scripts still must have child script databanks added as their own databanks.

3.2.1.4 Multiple Users Opening Scripts

For existing scripts, the file concurrency control prevents multiple users from editing the same script. If you try to open a script that is in use by another user, The script copy wizard opens and you will be asked if you want to make a copy of the script and additional files.

3.2.2 Migrating Scripts

To migrate scripts to the current version:

  1. Select Migrate Scripts from the Tools menu.

    This dialog box lets you migrate pre-version 9.10 OpenScript scripts to the current version. The Prompt on the top of the dialog box shows if the selected script is current or should be migrated and prompts for the appropriate action. The Script Migration Manager has the following options:

    • Path: Shows the file path of the selected repository/workspace or file folder.

    • My Repositories: Specifies the repository for selecting scripts to migrate or search. Select a repository and workspace from the tree.

    • My Computer: Specifies the file folder location on the computer for selecting scripts to migrate or search. Select a drive and folder from the tree.

    • [file list]: List the names of the existing files or scripts in the selected repository/workspace or file folder.

    • Script: Specify a name of a script to migrate or search.

    • Migrate: When enabled, the selected script is a pre-version 9.10 script and can be migrated to the current version. When disabled, the script is already a version 9.10 or higher script and doe not require migration.

    • Find child scripts: When enabled, the selected script is a pre-version 9.10 script and can be migrated to the current version. When disabled, the script is already a version 9.10 or higher script and does not require migration.

  2. Expand the My Repositories or My Computer trees to navigate to a folder containing the script files.

  3. Select the script.

    If Migrate is enabled, the script is a pre-version 9.10 and can be migrated. If Migrate is disabled, the script is already a version 9.10 or higher script and does not require migration.

    If Find child scripts is enabled, the script is already a version 9.10 or higher script and you can use the Find child scripts feature to locate any child scripts that may be assets for the currently selected script. If child scripts are located, you can use the Migrate Child Scripts options to migrate child scripts or search for additional child scripts. If Find child scripts is disabled, the script is a pre-version 9.10 script and must be migrated to the current version.

  4. Click Migrate or Find child scripts as required for the selected script file.

  5. Click Close when finished.

3.2.3 Setting Script Properties

Script properties specify the property settings for a specific script. You can set script properties at any time when a script is open. Script properties include the following:

  • Script assets including Databanks, Object Libraries, Generic Jar files, and other scripts to run as child scripts.

  • Correlation properties for Load Testing (protocol automation)-type scripts.

  • Module properties specifying which module services to include with a script.

  • Step Group properties specifying how step groups are created during recording.

To set Script Properties:

  1. Open or a create a script project.

  2. Select Script Properties from the Script menu.

  3. Select the property type in the left pane.

  4. Use the options in the right pane to set specific properties.

  5. Click OK when finished.

The script property panes are described in the following sections.

3.2.3.1 Correlation

This dialog box lets you specify correlation properties for Load Testing (protocol automation)-type scripts. The Correlation pane has the following options:

  • Module: Specifies the module type the script will use for the correlation rules.

  • Selected Module's Settings: Shows the current script's Correlation library and rules settings. Expand the tree view to view the selected libraries and rules.

    • Edit: Opens the correlation properties window for the specified module type.

3.2.3.2 Modules

This dialog box lets you specify which module services to include with a script. The Modules pane has the following options:

  • Modules: Shows which module services are included with the current script. The Basic and Utilities modules are common to all script types. The Shared Data module can also be used with all script types. The HTTP module is common to all load testing (protocol automation)-type scripts. The Functional Test and Web Functional Test modules are common to functional test-type script. Other modules are specific to a script type.

3.2.3.3 Script Assets

This dialog box lets you specify assets to a script. The Script Assets pane has the following options:

  • Asset: Lists the Assets added to a script by type in a tree view. Script Assets can be Databanks, Object Libraries, Generic Jar files, and other scripts.

  • File: Shows the files added as Assets to the current script. Expand the tree view in the Assets column to view the files.

  • Add: Opens a file selection dialog box for selecting the file to add as an asset. Expand the My Repositories or My Computer trees to navigate to a folder containing the file.

    Note:

    As of OpenScript Version 9.10, scripts can be stored anywhere in the file system. However, any scripts you plan to run, along with any associated assets, in the Oracle Load Testing application must be stored in a repository/workspace that can be accessed by the Oracle Load Testing Controller.
  • Edit: Opens a file selection dialog box for changing which files is added as an asset.

  • Open: Opens the selected asset file in the appropriate editor.

  • Remove: Removes the selected asset file from the Assets tree. The file still exists in the file system or repository/workspace.

3.2.3.4 Step Groups

This dialog box lets you specify Step Group properties for the current script. The Step Group pane has the following options:

  • Module: Specifies the module type the script will use for the step group rules.

  • Selected Module's Settings: Shows the current script's Step Group settings. The settings are specific to the script type.

    • Edit: Opens the Step Group properties window for the specified module type.

3.2.4 Importing Oracle Real User Experience Insight (REUI) Session Logs

You can import a REUI captured user session log file to generate an HTTP-based OpenScript load testing script. The REUI User Session log must be generated using REUI version 6 or higher.

To create a script from REUI user session log:

  1. Select New from the File menu.

  2. Expand the Load Testing (Protocol Automation) group. and select the Web/HTTP script type.

  3. Click Next.

  4. Select the repository and workspace where you want to store the script.

  5. Enter a script name and click Finish. A new HTTP protocol script project is created in the Script tree.

  6. Select Import Oracle Real User Experience Insight (REUI) Session Log from the Tools menu.

  7. Enter the file path and name of the REUI User Session log (.tab file extension) or click Browse to select the file.

  8. Set the Correlate script and Create step groups options.

  9. Click OK.

The REUI Session log import recorder parses the log file and generates an HTTP-based OpenScript script using the specified Correlate script and Create step groups settings. The script creation time can vary depending upon the size of the log file and if the Correlate script and Create step groups settings are set or not. Generally, when Correlate script and Create step groups are set, the script creation time increases.

The REUI User Session Log consists of the following files and folder:

  • data.tab file: This file contains the url, host and port, method, postdata, etc.

  • version.txt: This files contains the export version number which determines the version of the OpenScript REUI User Session Log importer to use.

  • content folder: This folder contains text content that corresponds to the entries in the data.tab file.

3.3 Modifying Scripts

Once you have created a script project, you can customize the script for your specific testing purposes using the available menu options or editing your own code in the Java Code view.

3.3.1 Adding Step Groups to a Script

Step groups provide a way to group multiple procedures into a single reporting step.

To add a manual step group to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the step group.

  3. Select the Script menu and then select Step Group from the Add sub menu.

    This dialog box lets you specify or modify a step group node in a script tree.

  4. Enter a name for the Step Group.

    Title: Specify the title text of the step group. The title text will appear in the script tree.

  5. Enter any think time delay to add to the Step Group.

    Think time: Specify the amount of time in milliseconds to use as a think time delay for the step group.

  6. Click OK. The Step Group is added to the script tree.

To add a step groups to a script based upon preferences:

  1. Open or create a script project.

  2. Select OpenScript Preferences from the View menu.

  3. Expand the OpenScript node.

  4. Expand the Record node.

  5. Select the Step Groups node.

  6. Specify the Step Group preferences and click OK.

  7. Select Create Step Groups from the Script menu. The Step Groups will be automatically added to the script tree.

  8. In the Java Code view, the step group consists of the code executed between beginStep and endStep:

    beginStep("Step Group 1", 10);
    
    {
    
            /**
    
             * Add code to be executed for the step group.
    
             */
    
            getLogger().info("Step Group 1");
    
    }
    
    endStep();
    
    

3.3.2 Adding a Delay to a Script

To add a delay to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the delay.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the General node and select Think Time.

    This dialog box lets you specify or modify a delay time in seconds.

  5. Enter a valid integer to use as the think time in seconds.

  6. Click OK. The Think node is added to the script tree.

  7. In the Java Code view, the think(time;) (the time is in seconds) statement will be added to the script code:

    think(10.0);
    
    

3.3.3 Adding a Log Message to a Script

To add a log message to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the log message.

  3. Select the Script menu and then select Message from the Add sub menu.

    This dialog box lets you specify or modify a log message in a script tree.

  4. Enter the message text.

    Message: Specify the text of the log message. The text will appear in the Console view on script playback.

  5. Click OK. The log message node is added to the script tree.

  6. In the Java Code view, the type("log message") method will be added to the script code:

    info("Message");
    
    warn("Message");
    
    fail("Message");
    

The log message text appears in the Console View when the script is played back.

3.3.4 Adding a For Statement to a Script

To add a For statement to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the For statement.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the Control Statements node and select For.

    This dialog box lets you specify or modify the For statement loop count.

  5. Enter a valid integer to use as the loop count.

    Loop Count: Specify the number of times to loop though the For statement.

  6. Click OK. The For node is added to the script tree.

  7. In the Java Code view, the for (int i=0; i < loop count; i++) statement will be added to the script code:

    for (int i=0; i < 10; i++)
    
    

3.3.5 Adding a Function to a Script

You can add your own custom functions to your script and specify the arguments to pass to the function. Custom functions can be in the current script or in another script that has been added to the current script's Scripts Assets Properties.

To add a function to a script:

  1. Create a script project.

  2. Record a complete script.

  3. Select the Run node in the script tree.

  4. Select the Script menu and then select Other from the Add sub menu.

  5. Expand the General node and select Function.

    This dialog box lets you specify a custom function name with multiple arguments.

    Name: Specifies the name of the custom function. Click Add to define the names and data type of an argument.

    Description: Specifies a user-defined description for the custom function.

    Argument: Lists the defined function arguments for the custom function.

    Type: Lists the data type for the defined argument for the custom function.

    Description: Lists the user-defined description for the argument defined for the custom function.

    Add: Opens a dialog box for defining a new argument for the custom function.

    Edit: Opens a dialog box for editing the selected argument.

    Delete: Removes the selected argument from the list.

    Up: Moves the selected argument up one place in the list.

    Down: Moves the selected argument down one place in the list.

  6. Enter the function name.

  7. Enter a description for the function.

  8. Click Add.

    This dialog box lets you specify a custom function argument to use to pass data to the function.

    Name: Specify a name of the custom function argument.

    Type: Select the data type: String, Integer, Double, Long, or Boolean.

    Description: Specify a description for the argument (you may want to include the data type in the description so that it is indicated in the Substitute Variable list).

  9. Enter an argument name.

  10. Select the data type for the argument.

  11. Click OK.

  12. Click Add and add more arguments or click OK to add the function to the script. The function name node is added to the script tree.

  13. In the Java Code view, the public void function name statement will be added to the script code followed by the arguments with the data types:

    /**
    
     * My custom Function
    
     * @param argString Description of argString
    
     * @param argInt Description of argInt
    
     * @param argDouble Description of argDouble
    
     * @param argLong Description of argLong
    
     * @param argBool Description of argBool
    
    */
    
    public void MyFunction(@Arg("argString") String argString,
    
          @Arg("argInt") int argInt,
    
          @Arg("argDouble") double argDouble,
    
          @Arg("argLong") long argLong,
    
          @Arg("argBool") boolean argBool)
    
       throws Exception {
    
  14. Add items into the Function. You can use the Tree View drag/drop or cut/paste features to move Tree View items to the function. You can use the Script Add option to add variable items to the function. You can also use the Code View to add custom code to the function.

To pass arguments into a function:

Define the variables to use to pass values to the custom function arguments somewhere in the script before where the Call Function statement will be placed in the script:

  1. Select the script node where you want to add variables.

  2. Select the Script menu and then select Other from the Add sub menu.

  3. Expand the Variables node and select Set Variable.

    This dialog box lets you define a variable in a script.

  4. Enter the variable name and value.

    • Name: Specify the name of the variable.

    • Value: Specify the value to assign to the variable.

  5. Enter a value or click the Substitute Variable icon to select a variable value to assign to the variable.

  6. Click OK.

  7. In the Java Code view, the getVariables().set() statement will be added to the script code followed by the variable name and value for each variable:

    getVariables().set("MyString", "String");
    
    getVariables().set("MyInt", "1");
    
    getVariables().set("MyDouble", "1234");
    
    getVariables().set("MyLong", "1234560");
    
    getVariables().set("MyBool", "True");
    

    The following is an example of a variable set to a Databank value:

    getVariables().set("MyString", "{{db.customer.FirstName,String}}");
    
  8. Select the Function node (your custom function name) in the script.

  9. Select the Script menu and then select Other from the Add sub menu.

  10. Expand the tree and select the item to add. For example Message under the General node or Set Variable under the Variables node.

  11. Click the Substitute Variable icon to select a custom variable or function argument. The Select Variable tree lists the custom function with all of is defined arguments.

  12. Select an argument for the custom function.

  13. Click OK.

  14. In the Java Code view, the message statement (info, warn or fail) or getVariables().set() statement will be added to the script code followed by the variable name and value for each variable:

    public void MyFunction(@Arg("argString") String argString,
    
          @Arg("argInt") int argInt,
    
          @Arg("argDouble") double argDouble,
    
          @Arg("argLong") long argLong,
    
          @Arg("argBool") boolean argBool)
    
       throws Exception {
    
          info("{{arg.argString}}");
    
          getVariables().set("MyArgString", "{{arg.argString}}");
    
          getVariables().set("MyArgInt", "{{arg.argInt}}");
    
          getVariables().set("MyArgDouble", "{{arg.argDouble}}");
    
          getVariables().set("MyArgLong", "{{arg.argLong}}");
    
          getVariables().set("MyArgBool", "{{arg.argBool}}");
    
    }
    

To call a custom function in a script:

  1. Select the node in the script tree here you want to call the function.

  2. Select the Script menu and then select Other from the Add sub menu.

  3. Expand the Script Function Calls node and the sub node where the custom function is located. Custom functions can be in the local (currently open) script or in another script added to the Script Assets Properties (select Script Properties from the Script menu to add other scripts to the Script Assets Properties).

  4. Select the function to call and click OK.

    This dialog box lets you specify a custom function to call and specify the argument values.

  5. Enter the argument data to pass to the custom function or click the Substitute Variable icon to select a custom variable or databank variable.

    • Function: Select the name of the custom function. The names of custom functions that were added to the script will appear in this list.

    • Arguments: A field for each custom function argument will appear for the selected function. Enter the argument value or click the Substitute Variable icon to select a custom variable or databank variable.

  6. Click OK.

  7. In the Java Code view, the callFunction or getScript().callFunction() statement will be added to the script code followed by the function name and arguments as String data types. If the function is in the same script the callFunction statement is added:

    callFunction("MyFunction", "MyStringArg");
    

    To pass data types other than String, enclose a defined variable name in double curly braces as follows, "{{VarName}}".

    callFunction("MyFunction", "{{MyString}}", "{{MyInt}}", "{{MyDouble}}", "{{MyLong}}", "{{MyBool}}");
    

    If the function is in a child script (a script asset script), the getScript().callFunction() statement is added:

    getScript("myAlias").callFunction("MyFunction", "myString", "myInt", "myDouble", "myLong", "myBool"); 
    

3.3.6 Adding Script Assets

You can add assets to a script such as, databanks, generic Jar files, object libraries, or other scripts containing recorded steps or custom functions. The asset must exist before it can be added. Select New from the File menu to record scripts or create databanks and object libraries. You also use the Create option in the Script Properties to create databanks and object libraries.

To add assets to a script:

  1. Open or create a script project.

  2. Select a script node and select Script Properties from the Script menu.

  3. Select Assets in the property type list. The Assets pane has the following options:

    • Asset: Lists the Assets added to a script by type in a tree view. Assets can be databanks, object libraries, generic Jar files, and other scripts.

    • File: Shows the files added as Assets to the current script. Expand the tree view in the Assets column to view the files.

    • Add: Opens a file selection dialog box for selecting the file to add as an asset. Expand the My Repositories or My Computer trees to navigate to a folder containing the file.

      Note:

      As of OpenScript Version 9.10, scripts can be stored anywhere in the file system. However, any scripts you plan to run, along with any associated assets, in the Oracle Load Testing application must be stored in a repository/workspace that can be accessed by the Oracle Load Testing Controller.
    • Edit: Opens a file selection dialog box for changing which files is added as an asset.

    • Open: Opens the selected asset file in the appropriate editor.

    • Remove: Removes the selected asset file from the Assets tree. The file still exists in the file system or repository/workspace.

  4. Select the type of asset to add and click Add.

  5. Select the asset to add from a repository or the file system.

  6. Set the Save path relative to current script option. The Save path relative to current script option specifies how the current script will locate the specified script asset. When cleared, the current script locates the script asset by a repository path such as, [Repository: Default] Default!/WebTutor, if the asset is selected from a repository or full file path such as, C:\OracleATS\OFT\Default!\WebTutor, if the asset is selected from the file system. When selected, the current script locates the script asset by a relative path such as ../WebTutor. Selecting the Save path relative to current script option is not recommended as script-relative paths are more brittle than repository-relative paths if scripts are moved or shared.

    The following are guidelines when using script assets in a team or distributed environment:

    • Do not use Absolute Paths when referring to assets or saving assets. Oracle Load Testing does not support absolute paths.

    • OpenScript, Oracle Test Manager, Oracle Load Testing, and all command-line agents should all use the same shared repository names and paths.

    • Do not refer to an asset in another repository by a relative path.

  7. Click OK to add the asset to the script properties.

  8. Click OK when finished adding script assets to close the script properties.

Script asset information is stored in the assets.xml file located in the script project directory.

3.3.7 Adding a Script to Run from a Script

To add a script to run to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the script to run.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the Expand the General node and select Run Script.

  5. Click OK.

    This dialog box lets you specify the script to run from within another script.

    Script: Specifies the OpenScript script to run.

    New: Opens the script properties for selecting the script asset to run.

    Sections of script to run: Specifies which script sections to run during playback.

    • Initialize Section: When selected, the code in the Initialize section of the selected script to run is executed during playback. When cleared, the code in the Initialize section is skipped.

    • Run Section: When selected, the code in the Run section of the selected script to run is executed during playback. When cleared, the code in the Run section is skipped.

    • Finish Section: When selected, the code in the Finish section of the selected script to run is executed during playback. When cleared, the code in the Finish section is skipped.

    Iterations: Specify the number of script iterations to run.

  6. Select the script using New next to the Script field.

  7. Select the next script to run from the available script assets in the Script properties. Use the Add button to add scripts to the script assets properties.

  8. Select or clear the Sections of script to run option.

  9. Set the iteration count.

  10. Click OK. The script name node is added to the script tree.

  11. In the Java Code view, the getScript().run(); statement will be added to the script code:

    getScript(alias=String).run(interation count = int, initialize = true|false, run = true|false, finish = true|false);
    

    Example

    getScript("Web1").run(1, true, true, true);
    
    

3.3.8 Adding a Set Variable to a Script

To add a Set Variable to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the set variable.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the Variable node and select Set Variable.

    This dialog box lets you set a variable value in a script.

  5. Enter the variable name and value.

    • Name: Specify the name of the variable.

    • Value: Specify the value to assign to the variable.

  6. Click OK. The Set variable = value node is added to the script tree.

  7. In the Java Code view, the getVariables().set("variable name", "value"); method will be added to the script code:

    getVariables().set("sVar_MyVar", "My_Value");
    

    If you want to set the variable with a value from an Oracle Functional Testing transform variable (i.e. a variable value contained in {{}} syntax), use the Transforms.transform method with the getVariables().set, as follows (requires HTTP module):

    http.solve("varTitle", "<TITLE>(.+)</TITLE>", "Page Title Error", false, Source.Html, 0);
    
    
    getVariables().set("sVar_MyVar", Transforms.transform("{{varTitle}}", getVariables()));
    
    

3.3.9 Adding Comments to Script Results

To add comments to script results:

  1. Open or create a script.

  2. Click the Code view tab.

  3. Add comments or warnings using one of the following code examples:

  • Using a step group:

  • beginStep("Any comment string", 0);
    
    {
    
    //The comment string appears in the Name column of the Results view.
    
    }
    
    endStep();
    
  • Using the getStepResult().addComment method:

  • //The comment string appears in the Summary column of the Results view
    
    getStepResult().addComment("Any comment string");
    
  • Using the getStepResult().addWarning method:

  • //The warning string appears in the Summary column of the Results view. 
    
    //addWarning overides addcomment.
    
    getStepResult().addWarning("Any warning string");
    
    

3.3.10 Adding Error Recovery to a Script

To add error recovery to a script:

  1. Open or create a script project.

  2. Select the script node where you want to add the log message.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the General node and select Error Recovery Action.

    Exception: Select the type of exception error. The list will vary depending upon the script type.

    Action: Select the error recovery action: Fail, Warn or Ignore.

  5. Click OK. The log message node is added to the script tree.

  6. In the Java Code view, the setErrorRecovery(scriptType.constant, ErrorRecoveryAction.action); method will be added to the script code:

    setErrorRecovery(BasicErrorRecovery.ERR_VARIABLE_NOT_FOUND, ErrorRecoveryAction.Fail);
    
    

3.3.10.1 Script Types

The following are the possible values for scriptType in the Java code statements:

BasicErrorRecovery (Basic module)

FormsErrorRecovery (EBS/Forms Functional module)

FTErrorRecovery (Generic functional module)

HttpErrorRecovery (HTTP module)

NcaErrorRecovery (EBS/Forms Load module)

UtilitiesErrorRecovery (Generic Utilities)

WebErrorRecovery (Web Functional module)

3.3.10.2 Constants

The following are the possible values for constant in the Java code statements:

BasicErrorRecovery (Basic module)

ERR_VARIABLE_NOT_FOUND

ERR_CREATE_VARIABLE_ERRORCODE

ERR_FILE_NOT_FOUND

ERR_SEGMENT_PARSER_ERROR

ERR_BINARY_DECODE

ERR_ENCRYPTION_SERVICE_NOT_INITIALIZED

ERR_GENERIC_ERROR_CODE

FormsErrorRecovery (EBS/Forms Functional module)

ERR_FORMS_FT_ERROR

FTErrorRecovery (Generic Functional Module)

ERR_FT_MATCH_ERROR

ERR_OBJECT_TEST_ERROR

ERR_TABLE_TEST_ERROR

HttpErrorRecovery (HTTP Module)

ERR_ZERO_LENGTH_DOWNLOAD

ERR_MATCH_ERROR

ERR_RESPONSE_TIME_ERROR

ERR_SOLVE_ERROR

ERR_HTML_PARSING_ERROR

ERR_INTERNET_INVALID_URL

ERR_INVALID_HTTP_RESPONSE_CODE

ERR_KEYSTORE_LOAD_ERROR

NcaErrorRecovery (EBS/Forms Load Module)

CONNECT_ERROR

MESSAGE_IO_ERROR

CONTROL_INITIALIZE_ERROR

UtilitiesErrorRecovery (Generic Utilities)

ERR_SQL_EXECUTE_ERROR

ERR_XML_PARSING_ERROR

ERR_CSV_LOADING_ERROR

WebErrorRecovery (Web Functional module)

ERR_RESPONSE_TIME_ERROR

ERR_WEBDOM_SOLVE_ERROR

ERR_WAIT_FOR_PAGE_TIMEOUT_ERROR

3.3.10.3 Actions

The following are the possible values for action in the Java code statements:

Fail

Ignore

Warn

3.3.11 Verifying Script Actions

You can verify script actions to check the result of a script action and adjust the behavior of the script based on the result of the action.

The basic process to use verify script actions is as follows:

  1. Add an Error Recovery Action before the script node where you want to verify the result code. You can add the Error Recovery Action from the script Add sub menu or in the Java Code view. Set the error recovery action to Warn or Ignore to ensure that the Has Error block gets executed. This allows script execution to continue past the code where an exception occurred to the next statement in the script code.

  2. Add a 'Has Error' Control Statement after the script node where you want to verify the result code. You can add the Has Error Control Statement from the script Add sub menu or in the Java Code view. The if(hasLastError()) block is added to the script code directly after the script node where you want to verify the result code.

  3. Add your custom code into the if(hasLastError()) block in the Java Code view.

  4. Add Results Object messages to return the result values. The Result Code Verification features provide access to a Results object. The Result Object provides Result Code, Summary, Error Message, and Duration information.

The following sections explain the steps in more detail.

3.3.11.1 Adding an Error Recovery Action

To add an Error Recovery Action:

  1. Select the script node before the script node where you want to verify the result code.

  2. Select the Script menu and then select Other from the Add sub menu.

  3. Expand the General node.

  4. Select Error Recovery Action and click OK.

  5. Select the Exception type. See Section 3.3.10, "Adding Error Recovery to a Script" for additional information.

  6. Select Warn or Ignore as the Action type and click OK.

  7. Add the Has Error condition to the script. See Section 3.3.11.2, "Adding a Has Error Control Statement" for additional information.

3.3.11.2 Adding a Has Error Control Statement

The Has Error Control Statement can be added to the script using the Tree view. However, the conditional behavior must be specified in the Java Code view.

To add a Has Error condition:

  1. Select the script node after the script node where you want to verify the result code.

  2. Select the Script menu and then select Other from the Add sub menu.

  3. Expand the Control Statements node.

  4. Select Has Error? and click OK. The if (hasLastError()) node is added to the script tree.

  5. Add a Result Object or add your custom code in the if (hasLastError()) block in the Java Code view. See Section 3.3.11.3, "Adding a Result Object Message" for additional information.

3.3.11.3 Adding a Result Object Message

The Result Object can be used to return result values.

To add a Result Object message:

  1. Select the if (hasLastError()) node in the script tree.

  2. Right-click the if (hasLastError()) node and then select Other from the Add sub menu.

  3. Expand the General node.

  4. Select Message and click OK.

  5. Select Info or Warn as the Message Type.

  6. Click Substitute Variable.

  7. Expand Last Result.

  8. Expand All Actions or assertions and Verifications.

  9. Select the Result to add to the message and click Finish.

  10. Click OK to add the message to the script.

    In the Java Code view, the message code with the result type is added to the if (hasLastError()) block:

    info("{{result.summary}}");
    
    

    You can customize the message string in the Java Code view. For example:

    info("Summary of last action: {{result.summary}}");
    
  11. If necessary drag the message node into the if (hasLastError()) node so the message is a child node of the if (hasLastError()) block. For example:

    if (hasLastError()) {
    
        info("Summary of last action: {{result.summary}}");
    
    }
    
    

3.3.11.4 Actions That Can Be Verified

Only specific OpenScript actions provide the ability to verify their results. In general, all actions that are available for adding from the tree view UI, including all verifications and assertions, support verification.

The following types of actions typically do not support verification:

  • Java methods that are only available from code and not from the UI

  • Deprecated methods

  • "Get" methods

  • Methods that interact with OpenScript internal code such as Logger, VUDisplay, Settings, Counters

  • Methods that don't throw any exceptions, such as http.removeCookie

3.3.12 Chaining Multiple Scripts

You can run multiple scripts from within a single script to chain playback of scripts together.

The procedure involves the following major steps:

  • Setting the browser preferences

  • Recording scripts

  • Creating a shell script

3.3.12.1 Setting the Browser Preferences

The browser preferences specify if a new browser will launch when recording a different script. Because the navigation sequence between multiple scripts is important, the same instance of the browser should run all scripts if the scripts are a continuation of each other. If each script is self-contained and there is no navigation between scripts, each script can launch its own browser and you can skip the Browser Preferences steps.

  1. Select Preferences from the View menu.

  2. Expand the General category and select Browsers.

  3. Clear the Always launch a new browser when recording a different script option.

  4. Click OK.

3.3.12.2 Recording Scripts

When recording scripts for chained playback, it is important to plan the start and stop points between scripts. This is especially true if session state needs to be maintained between scripts. All of the scripts must be of the same type.

  1. Create and record the first script, for example a Web Functional test log in script.

  2. Stop the recording but do not close the browser.

  3. Save the script.

  4. Create and record the next script. The navigation in this script should start from the point in the browser where the first script stopped.

  5. Stop the recording and save the script.

  6. Create and record any additional scripts to chain. The navigation in these script should start from the point in the browser where the previous script stopped.

3.3.12.3 Creating a Shell Script

The shell script is used to run the previously recorded scripts in sequence.

  1. Create a new script to use as the shell script.

  2. Select the script node where you want to add the first script. This could be either the Initialize or Run nodes.

  3. Select the Script menu and then select Other from the Add sub menu.

  4. Expand the General node and select Run Script.

  5. Click OK.

  6. Click New.

  7. Select the script to run from the available script assets in the Script properties. Use the Add button to add scripts to the script assets properties.

  8. Click OK.

  9. Select or clear the script sections to run and the iteration count.

  10. Click OK.

  11. Select the script node where you want to add the next script. This could be either the Initialize, Run, or Finish nodes.

  12. Select the Script menu and then select Other from the Add sub menu.

  13. Expand the General node and select Run Script.

  14. Click OK.

  15. Click New.

  16. Select the next script to run from the available script assets in the Script properties. Use the Add button to add scripts to the script assets properties.

  17. Click OK.

  18. Select or clear the script sections to run and the iteration count.

  19. Click OK.

  20. Repeat the Add script steps for each additional script to run.

  21. Save and playback the shell script to verify the script navigations work together correctly.

  22. In the Java Code view, the getScript().run() methods will be added to the script code:

    getScript("Web1").run(1, true, true, true);
    
    getScript("Web2").run(1, true, true, true);
    
    

3.3.13 Moving Nodes in a Script

You can click and drag a node in the script tree view to move the node to another location in the script tree. For example, you move a step group node from the Run section to the Initialize section or move a navigation node.

To move script nodes in the script tree:

  1. Open or create a script project.

  2. Select the script node to move in the Tree View tab of the Script View.

  3. Click and drag the mouse to move the node in the script tree. The script tree shows an indicator line that points to the location in the script tree where the node will be moved.

  4. Release the mouse button when the indicator line is at the location where you want to move the script node.

When moving Step Groups between script sections (i.e. between Run and Initialize, etc.) you may need to move the node to the section node.

You can also switch to the code view and move lines of code manually.

3.4 Changing Text File Encoding

Before recording sites with international characters on an English OS, users should change the default character set encoding to a character set that supports the desired character set.

To change the text file encoding:

  1. Start OpenScript and select Developer Perspective from the View menu.

  2. Select Preferences from the Windows menu.

  3. Expand the General node.

  4. Select the Workspace node.

  5. Select the Other option under Text file encoding.

  6. Select desired text file encoding (i.e. UTF-8 for Japanese language Web sites, etc.).

  7. Click Close when finished.

3.5 Debugging Scripts

You can use features of the Eclipse IDE to debug scripts. For debugging purposes, it is not always necessary to switch to the Debug Perspective to debug a script. You can add views to the Tester Perspective, such as Breakpoints, Debug, and Expressions views. In most cases, you do not need to use the Outline, Variables, and Tasks views. This section provides tips for basic script debugging techniques.

3.5.1 Adding Views to the Tester Perspective

In some cases, you may want to add additional views to the Tester Perspective for debugging purposes. You select the view to open using the shortcut keys to get to the Show View window.

To open the Show View window:

  1. Press and hold the Shift and Alt keys, then press the Q key (Shift+Alt+Q).

  2. Press the Q key again. The Show View window opens.

  3. If necessary, expand the Debug tree.

  4. Select the View(s) you want to open:

    • Press and hold the Shift key and click to select multiple contiguous view names.

    • Press and hold the Ctrl key and click to select multiple non-contiguous view names.

  5. Click OK.

The selected views open in the Tester Perspective.

Note:

If you are in the Developer Perspective, you can add a view by selecting Show View from the Window menu and then selecting Other.

3.5.2 Adding Breakpoints to a Script

You can add breakpoints to the script tree view or in the Java Code to halt script execution at a specific line of code in the script.

To add a breakpoint to the script tree view:

  1. Create a script project.

  2. Record the script.

  3. In the Script view, click the Tree View tab.

  4. Expand the script tree and select the node where you want to add a breakpoint.

  5. Click the right mouse button and select Add Breakpoint from the shortcut menu. The "[Breakpoint]" indicator appears at the end of the script node text.

  6. Play back the script.

    When you play back the script, code execution will stop at the breakpoint. The Confirm Perspective Switch message appears the when the code execution arrives at a breakpoint. Select the Remember my decision option if you do not want the message to appear again during future script playback.

  7. Click No to stay in the Tester perspective or Yes to switch to the Debug Perspective. You can use the following Script menu options to debug scripts:

    • Step - runs the currently selected node and moves the execution pointer to the next sibling node. If the selected node has a child node, the execution pointer is moved to the first child node. This option is only active during script playback and script execution is suspended while stepping through the script code.

    • Step Into - steps into the function or sub procedure. This option is only active during script playback and script execution is suspended while stepping through the script code. The execution pointer is moved into the beginning of the function.

    • Pause/Resume - pauses and resumes script playback. These options are only active during script playback.

  8. You can use the following right-click shortcut menu options to debug scripts

    • Skip/Unskip - set the code to skip or unskip.

    • Playback to Here - starts playback from the beginning of the script and halts playback at selected node in the script tree.

    • Playback from Here - starts playback from the selected node in the script tree and plays to the end or the next breakpoint.

    • Add Breakpoint/Remove Breakpoint - adds or removes a breakpoint in the script tree view. Script tree nodes with a breakpoint set show the "[Breakpoint]" indicator at the end of the script node text.

    • Execute - executes the code for the selected node in the script tree. This option is only active during script playback and the script is paused. Execute compiles the highlighted code in the editor or tree view and runs it in the currently paused thread. However, the original running program code isn't changed and the current execution pointer does not move when using Execute. You can use Execute to test changes to a script while debugging. For changes to be permanent, you must save the script which recompiles the code and returns the execution pointer back to the beginning of the run() section.

    • Step - runs the currently selected node and moves the execution pointer to the next sibling node. If the selected node has a child node, the execution pointer is moved to the first child node. This option is only active during script playback and script execution is suspended while stepping through the script code.

    • Step Into - steps into the function or sub procedure. This option is only active during script playback and script execution is suspended while stepping through the script code. The execution pointer is moved into the beginning of the function.

To add a breakpoint to the script code:

  1. Create a script project.

  2. Record the script.

  3. In the Script view, click the Java Code tab.

  4. Double-click in the right-most column of the code view frame next to the code line where you want to add a breakpoint. The breakpoint indicator appears as a round dot in the frame. You can add as many breakpoints as needed.

  5. Play back the script.

    When you play back the script, code execution will stop at the breakpoint. The Confirm Perspective Switch message appears the when the code execution arrives at a breakpoint. Select the Remember my decision option if you do not want the message to appear again during future script playback.

  6. Click No to stay in the Tester perspective or Yes to switch to the Debug Perspective. You can use the following keyboard debug features to execute code while in debugging mode:

    • Single-step (F6) - executes the next line of code.

    • Step-into (F5) - opens the method/function class file.

      Note:

      Source code for the JRE or for the Eclipse IDE is not included with the product. When stepping into code, an editor may appear that does not contain source code. In this case, close the editor and resume script playback. You can use the Step-into feature to step into your own custom functions that you have added to a script.
    • Resume (F8) - resumes code execution to the script end or to the next breakpoint.

3.5.3 Adding a Java Exception Breakpoint

You can pause a script when any error occurs by adding a "Java Exception Breakpoint" to the Breakpoints list.

To add a Java Exception Breakpoint:

  1. Create a script project.

  2. Record the script.

  3. Open the Breakpoints view.

  4. Click the Add Java Exception Breakpoint icon on the Breakpoints View toolbar.

  5. Type "AbstractScriptException" and click OK to add this exception to the breakpoint list.

  6. Right-click on the breakpoint in the Breakpoints view and select Breakpoint Properties.

  7. Select the Suspend on Subclasses of this Exception option in the breakpoint properties and click OK.

During script playback, if an exception occurs, you can correct the problem and then continue script playback.

3.5.4 Pausing and Resuming Script Playback in Debug Mode

You can pause and resume script playback using the Tree view or the Debug view.

To pause and resume play back in the Tree view:

  1. Create a script project.

  2. Record the script.

  3. Play back the script.

  4. Click the Pause toolbar button to pause playback.

  5. Click the Resume toolbar button to resume playback of a paused script.

To pause and resume play back in Debug mode:

  1. Create a script project.

  2. Record the script.

  3. In the Script view, click the Java code tab.

  4. If necessary, add a Debug view to the Tester Perspective. If the Developer Perspective is open the Debug view should already be open.

  5. Play back the script.

  6. In the Debug view tree, select the Thread [Iterating Agent 1] thread and click the Pause toolbar button. The Thread [Iterating Agent 1] thread is the Virtual User's thread. You can ignore the others.

  7. In the Debug view tree, select script.run() and click the Resume toolbar button to resume playback.

    If you want to resume from a specific point in a script, comment out all lines before the current one, save the script, and then resume.

You can also execute portions of the script without having to comment out lines and restart the playback.

  1. Insert a breakpoint at the first line of the run() section.

  2. Playback the script. You can execute or inspect any line when playback halts a the breakpoint.

  3. Select the specific line(s) of code you want to playback, right-click and select Execute. You can modify the code and re-execute without having to save the script.

  4. Repeat the select code, right-click, Execute process until the script works the way you want it to work.

  5. Stop playback, or select the Resume button on the Debug view to replay from the breakpoint.

3.5.5 Inspecting and Changing Script Variable Values

You can inspect or watch script variable values to debug scripts. The script must be running or stopped at a breakpoint.

There is a difference between Java local variables and script variables. Java local variables are declared using standard Java syntax, such as String x or int i. Script variables are set using the OpenScript API methods, such as getVariables().set("someVariable", "123" or http.solve().

To inspect the value of a script variable:

  1. Create a script project.

  2. Record the script.

  3. Add a breakpoint to the script.

  4. Play back the script.

  5. At the breakpoint highlight the script code containing the variable or type the following code and highlight the code:

    getVariables().get("someVariable")
    
  6. Right-click and select Inspect or Watch.

    • Inspect opens a pane that shows the variable (Shift-Alt-I adds the variable to the Expressions view).

    • Watch copies the variable to the Expressions view.

  7. To change the value of a script variable, type the following code:

    getVariables().set("someVariable", "newValue")
    
  8. Highlight the code.

  9. Right-click and select Execute.

    Note:

    You can also test individual web actions by pausing the script, selecting the code for the action to test, then right-clicking and selecting Execute (or pressing Ctrl+U).

3.6 Enabling Debug Logging

OpenScript provides debug logging capability using Jakarta Log4j.

To enable debug logging:

  1. Close OpenScript.

  2. Open the file log4j.xml located in C:\OracleATS\OpenScript.

  3. Locate the following section at the end of the file:

  4. <!-- ======================= -->
    
      <!-- Setup the Root category -->
    
      <!-- ======================= -->
    
    
            <!-- For production  -->
    
      <root>
    
       <priority value="WARN"/>
    
       <appender-ref ref="AGENTFILE" />
    
      </root>
    
            
    
            <!-- For debugging
    
      <root>
    
       <priority value="DEBUG"/>
    
       <appender-ref ref="AGENTFILE" />
    
       <appender-ref ref="CONSOLE" />
    
      </root>
    
            -->
    
  5. Move the ending comment brackets from:

  6. <!-- For production  -->
    
      <root>
    
       <priority value="WARN"/>
    
       <appender-ref ref="AGENTFILE" />
    
      </root>
    
            
    
            <!-- For debugging
    
      <root>
    
       <priority value="DEBUG"/>
    
       <appender-ref ref="AGENTFILE" />
    
       <appender-ref ref="CONSOLE" />
    
      </root>
    
            -->
    

    to:

    <!-- For production
    
      <root>
    
       <priority value="WARN"/>
    
       <appender-ref ref="AGENTFILE" />
    
      </root>
    
            -->
    
            
    
            <!-- For debugging -->
    
      <root>
    
       <priority value="DEBUG"/>
    
       <appender-ref ref="AGENTFILE" />
    
       <appender-ref ref="CONSOLE" />
    
      </root>
    
            
    
  7. Save the file log4j.xml and restart OpenScript.

  8. Run scripts.

The debug messages are stored in the file OpenScript.log located in <installdir>\OpenScript.

To turn off debugging, move the ending comment braces back to the original locations.