6.2.x

Use request method in merge rules.

XLT 6.2.5

See here for a complete list of all changes.

Test Framework

Wrong request method recorded with Firefox

When running tests with Firefox (via XltFirefoxDriver), the recorded request method was not always correct. This happened when redirects are involved, such as a POST request redirecting to a GET. In this situation, XLT recorded request method POST for both requests.

The root cause seems to be a bug in Firefox. We implemented a workaround in the timer recorder extension for Firefox that records

  • method GET for requests following redirects with status codes 301, 302 and 303, and
  • the method of the previous request for requests following redirects with status codes 307 and 308.

Some redirect requests not shown dimmed

In the left-side menu of the result browser, requests that are redirects are typically displayed in gray. This was not the case for requests with redirect status codes 303, 307, and 308. Fixed.

XLT 6.2.4

See here for a complete list of all changes.

Test Framework

Result Browser

Remove auto-refresh tags from page snapshots

When dumping snapshots of the visited pages for later display in the result browser, any piece of the page that may alter this page (e.g. Javascript code) is removed. Auto-refresh tags, such as <meta http-equiv="refresh" content="10; url=/">, are now removed as well.

Request body not shown on the Request Information tab

For POST requests, the result browser shows the post data either as a table (in case of form data) or as a text area (in case of JSON, etc.) right on the Request/Response Information tab. The latter will now work again.

Other fixes
  • Ensure the actions/requests menu to the left and the content area to the right scroll independently.
  • Ensure the View as HAR link is shown only if there is indeed a HAR file available.

Load Testing

ec2_admin: List x86_64 images only

When listing the available AMIs in ec2_admin, images that target an architecture other than x86_64 (for example arm64) will now be filtered out.

XLT 6.2.3

See here for a complete list of all changes.

General

Many 3rd-party libraries have been updated. This also fixes certain vulnerabilities that have been detected recently.

Test Framework

Reduce Footprint of Result Browser

The XLT result browser lists the details of all requests made during the execution of a test scenario. The result browser itself is a small web application that uses several JS, CSS, and image resources. We made some effort to replace certain 3rd-party JS libraries and optimized the remaining resources. This way the result browser consumes significantly less space on disk and is loaded faster.

Guava Version Clash Fixed

XLT depends on certain 3rd-party libraries which themselves depend on different versions of guava. In Eclipse, the conflict was (wrongly) resolved to use an older version of guava, which broke Selenium-based tests because of missing methods. XLT now ensures the correct version is used.

Load Testing

Support XML for Logging Framework Configuration

The Log4j2 framework can be configured with configuration files in certain formats. When looking for such a configuration file in the test suite, an XLT agent now tries not only config/log4j2.properties, but also config/log4j2.xml. The logger configuration in the alternative format XML is sometimes easier to read and understand.

Note that if both log4j2.properties and log4j2.xml exist, both files will be loaded and their configuration merged. In order to avoid unexpected results, decide on the file format to use and delete the respective other file.

XLT 6.2.2

See here for a complete list of all changes.

Test Framework

The XLT result browser lists the details of all requests made during the execution of a test scenario. The result browser itself is a small web application that uses several JS, CSS, and image files. All these resources are now minified and bundled into the index.html (for the result browser) and harviewer.html (for the optional HAR support). This way the result browser consumes less space on disk and is loaded faster.

XLT 6.2.1

See here for a complete list of all changes.

Test Framework

  • XLT comes with some small optimizations regarding CPU and memory usage.
  • When building the class path from the test suite files uploaded to the load agents, XLT now also searches directory build/dependency for additional JAR files. This new directory better fits the directory structure that is typical for Gradle-based test suites.

XLT Jenkins Plug-In

XLT now ships with the latest version 2.0.1 of the XLT Jenkins plug-in. This version fixes an issue when executing the same Jenkins project/job multiple times in parallel.

XLT 6.2.0

See here for a complete list of all changes.

Test Framework

Incorrect response size reported in real-browser tests

Previously, our timer recorder extensions for Chrome and Firefox might report an incorrect value for the size of a response. The reason is that this value relied on the received Content-Length header which, however, might not be present at all. Now the extensions use the transferSize metric obtained from the browser and fall back to the content length only if this metric is not available.

UnknownHostException with dnsjava-based host name resolver

XLT may use dnsjava as an alternative DNS resolver. The dnsjava-based implementation queries either one of the configured name servers or the system’s default name server if no specific server was configured. The latter did not work reliably on Windows so dnsjava might end up with no name server, resulting in an UnknownHostException. Fixed now.

Load Testing

Use request method in merge rules

Especially when load-testing REST-based APIs, XLT may record requests which have the same URL, but differ in the HTTP request method only. Since the runtime behavior may be very different for each method, it is essential to evaluate these requests not as a whole, but per request method.

To this end, the request processing framework in the report generator has been extended by a new filter (type code m) that filters requests by HTTP method. Use this filter in request processing rules to split requests into different buckets by qualifying the request name with the respective request method.

See below for how some typical request processing rules would look like:

# append HTTP method to request name
com.xceptance.xlt.reportgenerator.requestMergeRules.11.newName = {n} [{m}]
com.xceptance.xlt.reportgenerator.requestMergeRules.11.stopOnMatch = false

# append HTTP method to request name for OPTIONS requests only
com.xceptance.xlt.reportgenerator.requestMergeRules.11.newName = {n} [{m}]
com.xceptance.xlt.reportgenerator.requestMergeRules.11.methodPattern = OPTIONS
com.xceptance.xlt.reportgenerator.requestMergeRules.11.stopOnMatch = false

To enable filtering requests by HTTP method, XLT will always record the request method to timers.csv from now on. Previously, it was recorded only if the property com.xceptance.xlt.results.data.request.collectAdditionalRequestInfo = true was set.

Run start command independently from upload command

The XLT master controller supports a command line interface to trigger the various stages of a load test (upload, start, abort, download, report) via scripts.

Previously, start did not work without upload, i.e. the two commands had to be combined:

mastercontroller.sh -c upload,start

However, sometimes it would be nice if we could prepare everything beforehand (uploads may take a while) and later just start the load test, for example to begin load testing exactly at a certain time:

mastercontroller.sh -c upload
mastercontroller.sh -c start

The start command can now be run separately in non-interactive mode. Please ensure that you have uploaded the test suite before or otherwise the load test will finish immediately.

Note that in interactive mode you still have to upload a test suite before you can start the load test.

Last modified October 7, 2022