Debugging Scriptless GUI Functional Tests

The Scriptless editor has a built-in local debugger, separate from the GUI Functional Test Debugger. Developers use debuggers to step through and troubleshoot broken tests.

Tip: If you are using synthetic Test Data or Test Data Orchestration, the local debugger doesn’t take into account data iterations; it always takes the first row of data. If you want to debug data iterations or test data orchestration, use the GUI Functional Test Debugger, which is integrated with test data and uses the provided parameter values, just as the standard test execution would.

How to Interactively Debug a Scriptless Scenario Locally

1. Go to the Functional Tab, open the broken Test and go to its Configuration tab.
2. Turn the local debugger on.

   

   Now the Play button is enabled.
3. (Optional) Click Toggle Breakpoint on steps where you want to pause execution to troubleshoot.
   
   
4. Click the Play button to start the debugger.
   The Play button turns into a Pause button.
5. Wait for the debugger to open in a new browser window.
6. Resize or move the BlazeMeter window and the Debugger window, so you can see both.
7. Watch how BlazeMeter executes the test scenario and color-codes the debug results.
   • A green checkbox marks a step that has been executed.
   • A yellow edge marks a step that is being executed.
   • A green edge marks a step that has completed.
   • A red edge and red exclamation mark marks a step that has failed.
   • The colored marks are reset when you click Play or Stop.
   • Hover over Info symbols to read warnings and informational messages, for example, if the first locator was not found, and secondary etc. locator was used instead.
8. Click Stop to close the debugger.

The following screenshot shows how you can interactively edit variable values while the local debugger is running. Left-click the blue highlighted variable name to open the inline editor:

The following screenshot shows a successfully completed Go Step, and a running For Loop step with a breakpoint. You can tell by the green checkmark that the action inside the running step has completed.

The following screenshot shows a failed step. Hover over the exclamation mark to see error details:

How to Use Breakpoints

If you have set a breakpoint on a step, it means that execution pauses there, so you can investigate.

In your investigation, you can modify steps while the debugger is running. When you reach a breakpoint, you can modify the executed step, or any step after it. You can also modify steps before the breakpoint, but that won't affect this run of the debugger.

Click Play anytime to continue execution after pausing at a breakpoint; or click Stop to close the debugger.

Additionally, you have the following options when pausing at groups, loops, and if/else blocks:

• Step In - Step into the group, loop, or if/else block, and pause again.
• Step Over - Execute the group, loop, or if/else block, and pause again.
• Step Out - Step out of the current group, loop, or if/else block, and pause again.

Tip: Press Disable Scenario Step to skip a step.