- Shows actions and requests of a transaction
- Includes all HTTP headers
- Shows real full unaltered response
- Displays approximate rendering
- Displays test settings
- Helps to find errors
- Is great for test documentation
Result Browser Properties
When running test cases, you can save the page output to disk. The relevant property is
com.xceptance.xlt.output2disk. By default, it is set to
always in development mode). If you want to enable page output to disk, copy the following lines to
test.properties or set the already existing property accordingly:
## Enables page output to disk. Possible values are: ## - never ..... pages are never logged ## - onError ... pages are logged only if the transaction had errors ## - always .... pages are logged always com.xceptance.xlt.output2disk = always
By enabling page output to disk, a lot of data will be aggregated. To minimize this in load test mode, the property may be set to
onError so that only the page output that resulted in an error is saved to disk. Since this single page on its own is not always enough to determine what generated the error, we can also set the number of actions previous to the error that should be kept as part of the record (this is set to 3 by default and to
all in development mode):
#com.xceptance.xlt.output2disk.size = all com.xceptance.xlt.output2disk.size = 3
Also, the dump mode (whether modified or only final pages are saved) may be defined:
#com.xceptance.xlt.output2disk.onError.dumpMode = modifiedAndFinalPages com.xceptance.xlt.output2disk.onError.dumpMode = finalPagesOnly
So if an error occurs during a transaction in a load test,
output2disk is set to
onError and the size is set to
3, a result browser with the last 3 pages is written to disk. If the error condition is permanent (or present for a longer period of time), we might end up with thousands of (rather similar) result browsers. This tremendously increases the volume of data to be downloaded after the test, but does not provide any new information. That’s why you can limit the number of result browsers per type of error and agent.
For each type of error, which is identified by its message and stacktrace, XLT tracks the current number of stored result browsers and stops writing down any new result browser once the configured maximum number is reached. However, you may also configure a time period to periodically clear the counter. Use this setting to limit the maximum number of result browsers for a given time period instead of the whole test runtime.
# maximum number of different error types per agent com.xceptance.xlt.output2disk.onError.limiter.maxDifferentErrors = 1000 # number of result browsers per agent and type of error com.xceptance.xlt.output2disk.onError.limiter.maxDumps = 10 # period after which the result dump counter is reset to 0 com.xceptance.xlt.output2disk.onError.limiter.resetInterval = 1h 30m
When saving request data to disk for the result browser, the request body of POST requests is currently limited to 8K by default and will be cropped when exceeding this value. If this is still too low for your most complex requests, for instance Web service requests with large JSON bodies, you can also tailor this limit to your needs (in bytes):
com.xceptance.xlt.output2disk.maxRequestBodySize = 12345
If you have saved the page output to disk and want links from the error entries in the load test report to the corresponding result browsers in the results directory in your report, make sure the property is set accordingly in
com.xceptance.xlt.reportgenerator.linkToResultBrowsers = true
Using the Result Browser
The result browser contains the record of a test user session. It lists actions, request, and response details and supports error diagnosis.
The easiest way to open the result browser is by opening the link at the bottom of the console output after you ran a single test from your IDE:
This is handy during test development, but these results (result browsers) will also be available (depending on your test settings, see above) in your load test setups. All saved results can be found in the
<testsuite>/results directory. The subdirectory structure is as follows:
---+ results `---+ [testcase] `---+ [virtual-user] `---+ output `---+ [transaction-ID] |---- css |---- images |---+ pages | `--- cache `---- responses
The saved page output is held in a folder that represents a specific execution of a test (
results/[testcase]/[virtual-user]/output/[transaction-ID]). There you will find an
index.html containing the XLT Result Browser. The result browser comes with an integrated navigation side bar to facilitate browsing the complete page output of the transaction and looking at every single request in detail. The file
last.html in the output folder
results/[testcase]/[virtual-user]/output references the result browser for the last executed transaction of this virtual user.
The result browser navigation will only permit access to the pages of a transaction if they are directly related to actions. Therefore, defining actions correctly is very important to make the most effective use of the result browser. For details on how to structure test cases and create actions, see Basic Concepts and Code Structuring Recommendations.
Navigation, Color Coding and Filtering
The result browser contains two panels: the area on the left-hand side can be used to navigate the ‘steps’ - actions and requests - of your test case. The right side presents the output of your object under test (the site you are testing) or more detailed request information.
When you double-click an action (or click the little arrow left of it), the navigation will expand to list all related requests. The listed requests are color-coded as follows:
- Requests that return with status code 301 or 302 are redirects and will appear grey .
- Requests that return with status code 0, 400 or anything greater than 400 are errors and will appear red .
- All other requests will appear
unless the value of their content type meets one of the following conditions:
- If the content type contains the string
application/json, the request will appear purple .
- If the content type starts with the string
image, the request will appear green .
- If the content type is
text/css, the request will appear blue .
- If the content type contains the string
text/plain then this request will be color-coded black.
A small menu at the top will give you the possibility of filtering your output for certain content types (you can look up the color coding there too), request methods and employed protocols. To enable or disable a certain filter, simply toggle its checkbox.
Clicking on one of the requests will display its details.
Request and Response Information
When you select one of the requests from the navigation, the page content will be replaced by detailed information about the request and the related response. Four tabs at the top of the page will display the following information:
- Request/Response Information
- General Information
- Request and Response Headers
- URL Query and POST Parameters (if any)
- for POST requests: either the form data or (a part of) the raw request body
- for PUT and PATCH requests: (a part of) the raw request body
- Request Body (Raw)
- Response Content
Response Content Tools
Use the tabs at the top of the right-hand side output area to see the (raw) request body and response content. If you opened the report as a file from a local disk, most browser will warn you that the content can not be displayed. This is caused by a security measure in place to prevent exposing local data. Please use a local webserver instead to open the report from a local disk. Recommended applications are Node.JS - serve, Python SimpleHTTPServer, or the PHP Built-In Web Server.
This can be a lot of data that might not be structured at all, so the result browser provides two handy tools to enhance readability:
- by clicking Beautify the indentations are corrected (or added, if there were none),
- and by clicking Highlight, syntax highlighting will be added to the code.
Furthermore, there is a Select All button, which enables you to easily copy and paste the response content.
If the response is in JSON format, the result browser also features a tab where JSON responses are displayed in a tree-like view with expandable/collapsible sections that can also be searched and filtered.
Since the right-hand side output of an action represents the state of its associated page, you can use the output to inspect the page elements and their state. Simply use the inspection tool of your browser (e.g. Chrome Developer Tools) or plugin to analyze the page and its elements.
As described earlier, the output of an action shows the state of the page after a user interaction (with all the associated requests) was executed. The page output of an action does not include
<script> commands. These have been removed by XLT to avoid script execution while you are reviewing the output in your browser.
In order to let you inspect the temporal sequence and duration of requests in a graphical timeline view, XLT may generate an HTTP Archive (HAR) file along with an appropriate viewer as part of the result browser. The HAR file contains information about all requests/responses grouped by their corresponding action, including headers, sizes, and network timings. For client-performance tests, page load event timings are included as well. In order to save valuable disk space, the response content is NOT included in the generated HAR files.
To enable this feature, add the following line to your test configuration:
com.xceptance.xlt.output2disk.writeHarFile = true
The HAR viewer can be opened either by clicking the View as HAR link
in the result browser or directly by opening the
in the root directory of the result browser.