Debug scripts
This topic describes different options to help debug your TruClient 2.0 - Web script.
View replay errors
If any steps failed during replay, they are marked with an error
icon in the Development window. Hover over the icon to view a description of the error.
Run the script step by step
You can run your script step by step, to view the replay more slowly and in a controlled manner. Open the dropdown menu for the Replay button and select Replay step by step. Repeat this for each step as required.
View the replay logs
The log files record various operations performed when you replay a script in interactive mode, and when you replay the script from VuGen. These log files can be useful when debugging the script.
You can view details of your script's replay in the VuGen Output Pane. Select Output Pane > <Browser name> - Interactive Replay.
The log files are stored in the script folder:
interactive_replay_TruClient2Web_<Browser type>.txt |
Log file that records various operations performed when running a script in interactive mode. Example:interactive_replay_TruClient2Web_Chrome.txt |
mdrv.log |
Log file that records various operations performed when running a script from VuGen. |
Inspector panel
During replay, you can use the Inspector panel to inspect the values of variables at pre-determined points. The Inspector panel displays all parameters and user-defined variables, and can be used to help debug your script.
The Inspector panel is displayed when the script encounters a breakpoint during replay in interactive mode. Breakpoints pause the run of the script run at the specified step.
You can configure Inspector panel settings in General settings > Interactive options > Debug. For details, see Interactive options.
To use breakpoints and display the Inspector panel:
-
To insert and remove breakpoints in your script:
-
Click to the left of the step number. A breakpoint is added, indicated by a circle icon
to the left of the step number. Click on the breakpoint icon to remove it.
-
You can also right-click the relevant step and select Toggle breakpoint. Select the option again to remove the breakpoint.
-
-
Replay the script or the step. When the replay reaches a step with a breakpoint, the Inspector panel is displayed.
-
You can manually add a variable expression in the box at the top of the Inspector panel, and then click Add an expression
. This displays the value for the variable at the current breakpoint in the Inspector panel, and the expression is included every time the Inspector panel is displayed.
In general, it is only necessary to add expressions manually if automatic display of variables is disabled.
Debug scripts using snapshots
Snapshots are generated according to the snapshot generation settings. You can use the snapshots generated during replay to debug scripts, by viewing snapshots for failed steps.
To view snapshots for failed steps:
-
In the General settings dialog box, open the Interactive options tab.
-
Set the Replay snapshots generation to On error.
-
Replay the script from the Development window.
-
Open the Snapshots viewer. You now have a group of snapshots that displays the errors that occurred during replay.
For UI details, see Snapshots for scripts.
Step levels
The step level defines the importance of the step to the recorded business process. TruClient assigns step levels from 1-3. For example, a step is assigned level 2 if it occurs in an area of the application that has no effect on the process.
The step level is indicated by an icon displayed in the step. Lower numbers represent higher levels:
Step level | Icon | Description |
---|---|---|
Level 1 |
![]() |
|
Level 2 |
![]() |
|
Level 3 |
![]() |
Steps that have no apparent effect on the application. |
Recording all step levels
To include all step levels in your script: Before recording, on the General settings > Interactive options tab, enable Create level 2 or level 3 steps during recording.
If this option is not enabled, TruClient records level 1 steps only.
For details, see Configure general settings.
Filtering steps by step level
You control the steps that are displayed in the Development window using the Script level dropdown in the menu bar:
The default displays level 1 steps only. Select the second option to display level 1 and 2 steps, and the last option to display steps from all levels. The filtered out steps are hidden in the step editing area.
The numbering of the steps always reflects all of the recorded steps, including those that are hidden. So if the first four recorded steps are assigned level 3, and level 3 is hidden, then the displayed steps will start from step 5.
Note: During interactive replay, all hidden steps are ignored.
Example:
The following screen shot displays a small script. Note that the step numbers skip from 3 to 5; step 4 is hidden in a different level.
After changing the display settings to level 3, all steps are now displayed, and will all run if replayed in interactive mode.
Modifying the level of a step
You can override the automatic step level assignment, so that the step is included or excluded at the level at which you replay.
Example:
Mouse over steps are generally assigned level 3, since they represent user cursor movement that does not affect the application state.
However, if a mouse over opens a list to click an option, the action fails if the mouse over is not replayed first.
To fix this, lower the script level to 3 to display all steps. Open the relevant step and change the step level to level 1. (If the step is part of a group step, both the group step and the individual step must be modified.)
The step is now included when the script level is returned to level 1.
Tip: If the necessary mouse over was not recorded at all, add a Generic object action from the Steps box, and perform a click or mouse over action on the list.
Automatic leveling during replay
The level of a step is normally set during recording. If the level is set too low, the replay may fail, for example, generating an object not found error.
During replay, the step level is checked. If there are steps at a level lower than the current script replay level, and they can affect the outcome of the current step, then the meaningful steps are automatically moved to a higher level.
Handling short events
Sometimes during replay, an event ends too soon for the next action to occur.
For example, a mouse over opens a list box. The object must be open before an option is selected.
During replay, the list closes when the mouse over event ends. The next action to click on an option fails, because the list is not open.
There are two ways to handle this situation:
- Change the Mouse over step end event to Action completed.
- Remove both the Mouse over and the Click steps, and replace them with an Evaluate JavaScript step which performs both actions in the same step.
Insert Wait steps
Sometimes a script fails to replay because an object required by a step is not available immediately after the End event of the previous step. In this case, it is recommended to "slow down" the script, so there is enough time for the object to load.
You can do this by inserting Wait-type steps from the Steps box Functions tab. These ensure that the next step does not start until the wait condition is true.
There are two types of Wait steps:
Type | Description | After insertion: |
---|---|---|
Wait | Delays the next step for the specified time. |
Configure the interval in the argument section of the step. |
Wait for object |
Delays the next step until:
|
Select Choose an object, and select the target object in the application. Set the Exists argument to true or false, as required. |
You can run a script without the Wait steps, by selecting the Ignore wait steps option on the General settings > Interactive options tab.
Another option to resolve pacing issues is to change the Object timeout of the failing step in the step properties.
Note: Wait steps differ from Think time steps in other VuGen protocols.
- Think time is the time the script waits between actions, to emulate user reaction time.
-
Wait steps pause a script replay until a condition is met. In a Wait step, you can set the Think time argument to true, to include the wait time in the think time calculation.
Resolve step timeouts
Steps may time out for several reasons:
-
The application is responding slowly, possibly under load. This is actually an important test result and indicates a performance issue.
-
Step timeout is incorrect and should be modified in the step properties.
-
The end event of the step is incorrect, and the step is waiting for an event that does not occur. Change the end event in the step properties.
Resolve object identification issues
If an error is discovered during replay, you can highlight the object that failed, and the selected step is automatically recognized. For details, see Object identification.
You can also use the Descriptors editor to improve or control object identification in your scripts, by adding or editing conditions. For details, see Descriptors for scripts.
Selecting items in dynamic lists
If the names of the items in a list are dynamic, then the selection of an item on the list may fail during replay.
For example, the list may include cities based on the text entered so far (auto-complete). Based on the text typed in, the list constantly changes.
There are two ways to solve this issue:
-
Use an alternative step that selects an item from the list using the ordinal identifier, instead of the text of the actual item.
-
If the text is only partially dynamic, you can use a regular expression to locate the required item, based on partial text matching.
See also: