Multiple Actions run for a different number of iterations

The user has multiple Actions in the test which he would like to have run for different numbers of iterations.

Example:

Action1 should run for 1 iteration

Action2 should run for 4 iterations

Action3 should run for 2 iterations

Put values into the Action data tables not the global data table

1. Put the values into the local (Action) data tables.

2. Modify the statement in the script so that it reads the values from the local data table.

Example:

value = DataTable.Value ("value", dtlocalSheet)

3. Right-click on the Action and choose "Action Call Properties."

4. Select the Run tab.

5. Choose the "Run on all rows" option. You can also specify certain rows to replay by choosing the "Run from row … to row …" option.

Note:

If you are using QuickTest Professional 9.0, the "Run from row … to row …" option does not behave as expected. Instead of executing the specified row(s), QuickTest Professional uses the values in row 1.

When replaying the script, QuickTest Professional or QuickTest Professional will replay all iterations on an Action before moving on to the next Action.

Newly learned objects not added to the shared object repository file (QTP 9.x)

Newly learned objects will be added to the local repository

From the QuickTest Professional User’s Guide:

QuickTest does not add an object to the shared object repository as you record operations on it. Instead, it adds new objects to the local object repository (not the shared object repository) as you learn objects or record steps on them (unless those same objects already exist in an associated shared object repository).

You can find additional information on the local object repository versus the shared object repository in the User’s Guide (Help -> QuickTest Professional Help -> QuickTest Professional User’s Guide -> Creating Tests -> Working with Test Objects -> Understanding Object Repository Types -> Deciding Whether to Use Local or Shared Object Repositories).

This is done by design to prevent confusion and corruption. Since shared repositories are shared across multiple tests, an unfamiliar user can unknowingly corrupt the shared repository by recording new objects over existing object descriptions. Also, QuickTest Professional 9.0 and above allows you to associate multiple shared object repository files with each action. QuickTest Professional would not know which shared object repository file the new objects should be learned into.

To avoid these scenarios, the objects are added to the local repository and you can then merge them into the shared repository of your choice.

Working with objects in multiple associated repositories with the same name (QTP 9.0)

Working with objects in multiple associated repositories

If an object with the same name and description is located in both the local object repository and in a shared object repository associated with the same action, the action uses the local object definition. If an object with the same name and description is located in more than one shared object repository associated with the same action, the object definition is used from the first occurrence of the object, according to the order in which the shared object repositories are associated with the action.

Note:
QuickTest Professional will not generate an error when multiple repositories containing objects with the same name are associated with the action.

Example:
You have the following webpage:

<html>
<body>
<table>
<tr>
<td><a href="http://www.google.com">Google</a></td>
<td><a href="http://www.google.com">Google</a></td>
<td><a href="http://www.google.com">Google</a></td>
</tr>
</table>
</body>
</html>

1. Learn the first link into one shared repository, shared1.tsr.
2. Learn the second link into a different shared repository, shared2.tsr.
3. Learn the third link into the action’s local repository.

Each repository should now contain a Google object. The object hierarchy and name for each link will be the same (the objects are uniquely identified by the index identifier property).

4. Associate the shared1.tsr repository, then the shared2.tsr repository to the action. The associated repository list should look like the following:

<local>
shared1.tsr
shared2.tsr

5. In your script, enter the following line:

Browser("Browser").Page("Page").Link("Google").Highlight

6. Run the script. The third Google link will highlight. This is the link in the Local repository.
7. Remove the Google link from the local repository.
8. Run the script. The first Google link will highlight. This is the link in the shared1.tsr repository.
9. In the Keyword View, right-click on the Action and select "Action Properties".
10. Select the Associated Repositories tab.
11. Select the shared1.tsr file in the list, then click the down arrow button. The associated repository list should now look like the following:

<local>
shared2.tsr
shared1.tsr

12. Click <OK> to close the Action Properties window.
13. Run the script. The second Google link will highlight. This is the link in the shared2.tsr repository.

Delete objects from the object repository (QTP 9.0)

Deleting objects in the object repository (QTP 9.0)

Removing objects from a local object repository:
1. Go to Resources -> Object Repository.
2. In the Filter combo box, select "Local Objects."
3. In the object tree, select the object to be removed.
4. Click the delete toolbar button.
5. Click <Yes> to confirm the deletion.
6. Save the test to save the updated local repository.

The object, and any children it may have, will be removed.

Removing objects from a shared object repository:
1. Go to Resources -> Object Repository Manager.
2. Go to File -> Open. Navigate to the desired Shared Object Repository file.
3. By default, the repository will open in read-only mode. Go to File -> Enable Editing.
4. In the object tree, select the object to be removed.
5. Click the delete toolbar button.
6. Click <Yes> to confirm the deletion.
7. Save the updated shared repository.

The object, and any children it may have, will be removed.

Merge object repository files (QTP 9.0)

Merging object repository files (QTP 9.0)

Merging a local object repository with a shared object repository:
To merge the contents of a local repository into a shared repository, the shared repository must be associated with the action containing the local repository. In the Object Repository Manager, select the "Update from Local Repository" option.

Merging shared object repositories:
1. Open the Object Repository Manager.
2. Go to Tools -> Object Repository Merge Tool.
3. In the New Merge window, browse to the primary repository file. Mercury recommends selecting the repository file you have invested the most time into as the primary repository file.
4. Select the secondary repository file.
5. Click <OK>.
6. Review the merge statistics, as described in Viewing Merge Statistics, and click <Close>.
7. Resolve any merge conflicts that were reported.

Resolving object conflicts:
Conflicts between objects in the primary and secondary object repositories are resolved automatically by the Object Repository Merge Tool using default resolution settings. For information on defining the default settings, refer to the QuickTest Professional User’s Guide (Help -> QuickTest Professional Help -> QuickTest Professional User’s Guide -> Managing and Merging Object Repositories -> Merging Shared Object Repositories -> Defining Default Settings).

The Object Repository Merge Tool also allows you to change the way the merge was performed for each individual object that causes a conflict.

1. In the object repository tree, select an object that has a conflict (there will be an icon to the left of the object name). The conflicting objects are highlighted in the source repositories. A description of the conflict and the resolution method used by the Object Repository Merge Tool is described in the Resolution Options pane.
2. In the Resolution Options pane, select a radio button to choose a resolution method. The target object repository is updated according to your selection and redisplayed.

Note:
The resolution method the Merge Tool used is selected by default.

3. Click <Previous Conflict> or <Next Conflict> to jump directly to the next or previous conflict in the target object repository hierarchy.
4. Repeat steps 1 through 3, as needed.
5. Save the merged object repository file.

Move objects from the Local Repository to a Shared Object Repository (QTP 9.0)

Use the "Update from Local Repository" option in the Object Repository Manager

Note:
Updating the Shared Object Repository with the objects in the Local Repository will merge all objects from the Local Repository into the Shared Repository. All objects will be removed from the Local Repository.

1. Save the script containing the Local Repository. Open a new test.
2. Go to Resources -> Object Repository Manager.
3. In the Object Repository Manager window, go to File -> Open, and select the Shared Object Repository file. Clear the "Open in read-only mode" checkbox.
4. If the repository file opened in read-only mode, go to File -> Enable Editing.
5. Go to Tools -> Update from Local Repository.
6. Click the "Add Tests" icon button. If you are connected to a TestDirector for Quality Center with Business Process Testing, you will have the option to browse for a test or a component. Select the appropriate choice.
7. Navigate to the test or component containing the Local Repository.

Note:
You can only add a test containing actions that are associated with the Shared Object Repository you are updating whose Local Object Repositories contain objects.

8. In the Update from Local Repository dialog, select the desired action.
9. Repeat steps 6 through 8 as needed.
10. Click <Update All>.

Note:
If the test using the Shared and Local Repositories is currently open, you may receive an error similar to the following:

"You cannot update this shared object repository from the <path> test’s local object repository because the test is currently locked by ‘<username> on machine ‘<machine name>’. Wait for the test to be unlocked and then try to perform the update operation for this test again.

If so, open a new test in QuickTest Professional to release (unlock) the test and repeat step 10.

11. Perform any steps needed to resolve conflicts.
12. If you are performing multiple merges, go to File -> Save and Merge Next to perform the next merge (the Local Object Repository of the next action being merged into the Shared Object Repository).
13. Click <Yes> to save your changes between merges. If you click <No>, the current merge (objects merged from the last action) will not be saved.
14. Repeat steps 11 through 13 to complete the multiple merges.
15. Choose File -> Exit, then click <Yes> to save the updated Object Repository.

Modify the value of a property in the Object Repository

  • Opening a Local Repository:

1. Go to Resources -> Object Repository.

2. In the left panel, select the object whose property value you would like to modify. This will show all the properties associated with this object in the list in the right panel.

  • Opening a Shared Repository:

1. Go to Resources -> Object Repository Manager. The Object Repository Manager window will open.

2. Go to File -> Open. Navigate to the desired Shared Object Repository file.

3. By default, the file will open in read-only mode. Go to File -> Enable Editing.

4. In the left panel, select the object whose property value you would like to modify. This will show all the properties associated with this object in the list in the right panel.

  • To modify an the value of a property:

1. Open the Object Repository file, and select the desired object.

2. Select the field in the Value column for the desired property from the Test object details list.

3. Click the "Configure the value" button (appears at the right of the value edit field).

4. Make the required modification to the property value in the "Constant" edit field.

5. After changing the value, click <OK> to close the dialog.

  • To add or remove properties that are used to identify objects in your application.
  • To associate (add) other properties to an object:

1. Open the Object Repository file, and select the desired object.

2. Click the "Add description properties" button (with the + icon). The Add Properties dialog will appear.

3. Select the desired property or properties from the list. To select multiple properties, press the keyboard Ctrl key while selecting the properties.

4. Click <OK>. The selected properties will be added to the object.

5. If needed, set or modify the value of the new property using steps 2-5 above for modifying a property value.

Note:When adding properties to the Object Repository and start recording again, QuickTest Professional will relearn the object into the Object Repository. To prevent this, modify the Object Identification settings for the class.

  • To remove properties associated with an object:

1. Open the Object Repository file, and select the desired object.

2. Select the property or properties to be removed.

3. Click the "Remove selected description properties" button (with the X icon). The property or properties will be removed from the list.

Note:
If you remove a property that is required to uniquely identify the object, QuickTest Professional may generate errors during replay. When removing properties which are used to identify an object, you should replace them with an alternate property.

Using relative paths when calling external / reusable Actions

Using relative paths when calling Actions

1. Go to Tools > Options

2. Select the Folders tab. Note: on UFT, this option is available under "GUI Testing" and only while GUI Test is open.

3. Add the path to the folder to search the tests / components / actions / files on.

Note:If you define folders here, you do not need to designate the full path of a test, component, action, or file in other dialog boxes or call statements. The order of the search paths in the list determines the order in which the mechanism searches for a specified action or file.

4. Click <OK>

5. Go to Insert / Design > Call to Existing Action.

6. In the From test field, select or enter the path to the reusable Action. Use the "Browse" button to navigate to the directory, if necessary.

7. Replace the absolute path with the relative path.

8. Click <OK>.

Note:This recording was created with QTP 9.0, however core steps remain the same on later versions, including Unified Functional Testing.

To verify the path (QuickTest Professional only):

1. Switch to Keyword View.

2. Right-click on the reusable Action.

3. Select Action Properties from the pop-up menu.

The path will be displayed in the Location field. Note: on UFT, the Properties sheet/pane displays the same "Location" property when selecting the action on the Test Flow chart, however shows full path(even if inputted as relative) as sign that it is working fine, however if folder reference is removed or does not exist, "Action is missing…"error appears.

Use an Action from one script in another script

Insert a call to such source action using any of the following methods:

  • QTP Graphical User Interface (GUI):

1. Go to Insert menu, then select "Call to Existing Action" (or "Call to Copy of Action")

Note: A "Call to Existing Action" inserts a link to the Action in the original script. A "Copy of Action" inserts a copy of the Action into the new script.

2. Browse to the first script in the "From test" field.

3. Select the Action(s) you want.

4. Select the location where the Action should be inserted.

5. Click <OK>.

  • Programmatically. Starting with QuickTest Professional 10.0, the statementLoadAndRunActionwas implemented, loading during run-time the dedicated resources of a reusable action to main test.

    LoadAndRunAction "C:\MyTest", "Action1", OneIteration

Considerations:

By design, an Action has dedicated resources used during replay, specifically a script, a local repository (can only be modified directly from source test storing the action) and a Data table sheet (only one denominated as "local sheet", not "global sheet") with same name as action (name of source test script is displayed between brackets).

Action’s Data Table Sheet Notes:

  • Iterations: Action will iterate X amount of times after desired configuration from "Action Call Properties" dialog (right click on action under Test Flow Pane), under "Run" tab. To run action depending how many rows sheet has, setup "Run on all rows" for "Data Table iterations" option.
  • Access to data on sheet: When script is running through an action’s code, this sheet can be accessible by using statements such as

    DataTable.GetSheet(dtlocalsheet).GetCurrentRow

    Or

    DataTable("A", dtlocalsheet) = CSTR(Now)

Files and subfolders of a QuickTest Professional test

The files and folders hold binary and text data that are required for the test to run successfully

The following table provides a description, the type, and comments regarding the files that make up a QuickTest Professional test.

File Name Description Type Comments Regarding File
Test.tsp Test settings Binary Do not edit
Default.xls Data table parameters Excel similar Can be edited using Excel
Parameters.mtr Parameterization information Binary Do not edit
Action<I> Action folder (See other table)
Default.cfg Load test configuration file Text Do not edit
Default.prm Load test configuration file Text Do not edit
Default.usp Load test configuration file Text Do not edit
<testname>.usr Load test configuration file Text Do not edit
Thick_usr.dat Load test configuration file Text Do not edit
Thin_usr.dat Load test configuration file Text Do not edit

Files within Action folder:

File Name Description Type Comments Regarding File
Script.mts Action script Text Edit text preceding the @@ sign only
Resource.mtr Object Repository Binary Do not edit
Snapshots Active screen files Folder Do not edit