9.1.x

Faster Merge Rules, Auto-Mapping of Test Classes, Relative Load Functions

XLT 9.1.2

Test Framework

  • Resolved a synchronization issue that may cause a test scenario to enter an endless loop.
  • When using OkHttp as the underlying HTTP client, custom cookies may stop working due to stricter requirements regarding certain cookie fields. For example, the “path” field may be affected. If OkHttp encounters an issue, XLT will now add extra context information to help identify the problematic cookie.

Load Test Report

  • When filtering a table in the load test report, some entries that clearly match the filter criteria may still be filtered out. This only occurred with very long entries. This issue has been resolved.

XLT 9.1.1

This version is just a re-release of XLT 9.1.0 because the xlt.jar file of XLT 9.1.0 was not uploaded correctly to Maven Central. Make sure to use XLT version 9.1.1 or higher in your build files.

XLT 9.1.0

Load Testing

Relative Load Functions

For variable load profiles, load factors, users, or arrival rates can also be given as a load function. To reduce recalculation mistakes in case of changes, load function elements can now be specified relative to their previous value:

com.xceptance.xlt.loadtests.default.loadFactor = 0/1.0, +1h/+0.5, +30m/-1.0

See the online documentation for more information.

Auto-Mapping of Test Classes

Previously, each test scenario had to be mapped to a Java class in the configuration of your test suite:

com.xceptance.xlt.loadtests.TOrder_US.class = posters.tests.TOrder

However, this is no longer necessary for simple projects. If no explicit mapping is present, XLT will now try to find a Java class whose simple name matches the scenario name. For instance, the scenario TBrowse could be automatically mapped to the Java class posters.tests.TBrowse.

If there is no matching Java class (or more than one), XLT will complain, and you will have to explicitly map the scenario to a class.

Load Test Report

Merge Rules Support Jumps

Request processing rules (a.k.a. merge rules) are a powerful way to group requests into dynamically named buckets, for which individual statistics and charts will be created.

However, these rules rely heavily on regular expressions to decide whether they apply for a certain request. For larger rule sets and high volumes of requests, processing all the requests can be time-consuming.

By default, rules are evaluated one after the other. However, if you already know that susequent rule(s) are not applicable, you can now jump forward and continue with a later rule, thereby skipping the evaluation of intermediate rules altogether:

com.xceptance.xlt.reportgenerator.requestMergeRules.5.newName = {n} CSS
com.xceptance.xlt.reportgenerator.requestMergeRules.5.namePattern =
com.xceptance.xlt.reportgenerator.requestMergeRules.5.urlPattern = \\.css$
com.xceptance.xlt.reportgenerator.requestMergeRules.5.stopOnMatch = false
com.xceptance.xlt.reportgenerator.requestMergeRules.5.continueOnMatchAtId = 10

This lets you skip ahead if the current rule matches. You can also use the continueOnNoMatchAtId variant, which lets you jump forward if the current rule does not match.

Note that the specified target rule index:

  • Must be higher than the current rule index (i.e., forward jumps only).
  • Does not need to exist, in which case the rule with the next larger index will be next.

If you have a complex set of rules, we encourage you to experiment with jumps. Use your knowledge of the requests to regroup rules, insert jumps, and enjoy shorter report generation times.

Custom Logs as a Single File

Test data items used during a load test can be recorded as custom logs. These logs are made available for download as ZIP files directly from the load test report.

Previously, the ZIP archive for a test data scope contained multiple test data files, one for each test user. Now, there is an alternative mode that merges all recorded test data into a single test data file per scope.

Whether or not to aggregate the test data can be controlled with a new setting in <xlt>/config/reportgenerator.properties:

com.xceptance.xlt.reportgenerator.customDataLogs.aggregateFileContents = true

Test Framework

Custom Host Name/IP Address Mappings

Typically, XLT resolves host names to IP addresses using a DNS server. However, public DNS servers may not always contain certain host names, for example, private test servers. If you prefer to use host names instead of IP addresses, you can now define static host name/IP address mappings in the configuration of your test suite. Consider this a simple, dynamic alternative to manipulating /etc/hosts on all your load agent machines.

A custom mapping can be defined like this:

xlt.dns.override.www.example.org = 192.0.2.1, 2001:db8::1

The host name to map comes after the xlt.dns.override. prefix in the property key. The value contains a list of IPv4 and IPv6 addresses corresponding to the host name.

Note that these static mappings are valid only for your test suite. They are not published to DNS. Additionally, this approach does not work for real-browser tests because browsers have their own way of resolving host names.

Higher-level features, such as filtering or randomly shuffling the addresses, also work with static mappings.

Last modified December 13, 2025: Full rework of structure, menus and more. Search (0084fce8)