Help

JBlitz Professional ships with a debugger that lets you step between the pages as they are downloaded and that can help you analyze the HTTP messages sent to and from your website or web application. The JBlitz debugger gives you a head start when you're trying to pinpoint bugs, defects and potential problems.

To work with the debugger, click on the 'Debug' button at the bottom of the right hand gutter. The debug panel is shown. You are presented with a combo-box at the top left that allows you to select a test case of interest. Below this is listed the web pages that make up this test case. To the right is a panel that shows, toward the top, the steps taken to download any given web page, and toward the bottom, a tabbed pane that holds information relevant to the HTTP request / response that is currently active.

The panel to the right becomes activated once a breakpoint has been hit, whilst stepping through a test case, when you have paused execution, or when an error has occurred and you have specified as part of the error handling to break to the debugger (see the error handling section).

There are several ways to begin a debug test run. You can debug either:

• all test cases together, or

• any given single test case individually

To debug all test cases together, simply select the main menu option Run->Debugger->Start Debug or hit Ctrl+F8. A toolbar button - the orange arrow with a 'bug' on it - is also provided as a convenient shortcut.

In this mode, all virtual user for all your test cases are run as normal and any breakpoints you have set will be active. If an error occurs in any of the test cases and you have selected the error handling action 'break to debugger', the run will be paused and offending test case will be highlighted in the debugger.

To debug any given single test case, switch to the 'Debug' panel (click the bottom button in the right hand gutter), select the test case of interest from the combo-box in the top left corner and either click the second orange arrow on the debug toolbar to the right, or, to step into the test case, click the fourth icon (an orange arrow with a footprint on).

In this mode, all virtual users for your selected test case are run. Any breakpoints in that test case will be active, but any others in other test cases will not have any effect. This mode is good for pinpointing trouble-spots with particular queries quickly.

A popup menu also provides options to begin debug test runs, either together or singly. Click the right mouse button on the web page list below the test case combo-box.

To stop a debug test run, click the 'red square' toolbar button, hit F9 or Ctrl+F9 or select the option from the main menu Run->Stop.

JBlitz allows you to set a breakpoint on any given web page within any of the test cases. Switch to the 'Debug' panel (click the bottom button in the right hand gutter), select the test case of interest from the combo-box in the top left corner and either click on the area immediately to the left of the web page of interest, or use the right mouse popup menu on the web page list and select 'Toggle Breakpoint'. A red circle is shown against the web page. When a breakpoint is set, any virtual user that moves on to that page will cause the debug test run to be paused and control to be passed to the debugger - the breakpoint has been 'hit'. See pausing your debug test run below.

You can clear all breakpoints by using the right mouse popup menu on the web page list to the left of the panel. The breakpoint configuration is part of the test configuration settings (i.e. breakpoints are remembered for each test configuration), so whenever you set or reset a breakpoint, you'll find that the test configuration file will need a save.

You can pause a debug test run in one of the following ways:

• Click the 'pause' icon on the debug toolbar or hit Ctrl+F10.
• Set a breakpoint for one of the web pages in a test case and wait until a virtual user reaches that page.
• Wait until an error occurs and have the error handling action 'break to debugger' specified. See error actions for more.

When a run is paused, a single virtual user will become the current virtual user within the debugger and have its execution state displayed in the right hand panel. All the other virtual users will be suspended and will continue to be suspended whilst you step through the download process until the point at which you resume the run. Which virtual user becomes the current one for the debugger depends on which path led to the pause occurring as described above.

At this point, with the run paused, you can choose to step through the download process for the current virtual user (see below), resume execution (by hitting Ctrl+F12 or selecting the second to last icon on the debug toolbar) or stop the debug test run by hitting F9.

When a run is paused, or, you step into a run by hitting Ctrl+F11 (or by clicking on the 'step' icon on the debug toolbar), the right hand panel becomes activated and you can then step through the download process for the current virtual user within their test case. The affected test case, virtual user and web page are shown toward the top of the panel. Below, the current execution point is shown by the green arrow. Each 'step' takes the current virtual user onto the next execution point. Execution points comprise: Ready to connect. The initial starting position for this web page download before the virtual user tries to connect to the server. Connected. If a connection was established, the execution point moves on to here. A candidate request message is formulated and shown below where it may be modified prior to transmission. Request issued. The request message has been sent to the server. Response received. A full response has been read from the server including HTTP headers and body. The response is shown below. Response processed. The response is analyzed by JBlitz. Response checkers and informers are notified as appropriate and a determination of whether the response represents a hit or an error is made. Disconnected. The virtual user disconnects from the server.

To the right of the execution points area a status line is shown. If an error occurs, it will be highlighted in red on this line.

Towards the bottom, a tabbed pane gives details about the current download:

• The 'Details' tab shows connection, URL and other relevant settings.
• The 'Request' tab shows the request message to be issued / already issued for this page. If the execution point is on 'Connected', the request message is shown in green and may be altered prior to transmission. If the execution point is after this, it is shown in black.
• The 'Response' tab shows the response body and headers received (if any). If the execution point is on 'Response received', the response message is shown in green and may be altered before being processed within the application. If the execution point is after this, it is shown in black.

A check-box is provided to allow you to have JBlitz select the relevant tab as you step. A search box is also provided for the request and response tabs.

Whist stepping through a test case, you may dynamically modify either the request message to be sent to the server or the response that is received from it.

• To modify the request message for a web page, step onto the execution point Connected. Select the 'Request' tab below and you should see a candidate message in green. Type in any alterations you wish. Step onto the next execution point Request issued to have the modified message issued. If you want to undo any of your modifications, click the 'Undo Changes' button below.

  Note: modifications to the request message may easily make it an invalid HTTP request and result in unexpected errors.

• To modify the response headers or body received, step onto the execution point Response received. Select the Response tab below and you should see the response headers and body in green. Type in any alterations you wish. Step onto the next execution point Response processed to have the modified response headers or body processed by JBlitz. If you want to undo any of your modifications, click the 'Undo Changes' button below.

  Modifications you make to the response headers or body will be passed onto registered response checkers and response informers, to the Error Inspector and Response Recorder as appropriate, and should be visible when viewing the downloaded web page content or headers.

  Some modifications will affect whether or not the response is deemed an error. For instance, modifying the HTTP response code from 200 to 404 (say) will likely mean the response is treated as an error and recorded by the Error Inspector when it would not have otherwise been.