Project Configuration

Special configuration settings for load test projects in XTC.

The Configuration of a load test project is very similar to the basic project configuration, but there are a few special settings for this project type:

Repository

To view repository settings, your account must at least have the role of a tester within the project.

To edit repository settings, your account must at least have the role of a test manager within the project.

In addition to the basic repository settings which can be defined for load test projects and monitoring projects alike, there are a few additional options for load test projects concerning the compiling of the test suite:

Build

Build Tool

Before a load test can be started, XTC needs to compile your load test suite. If you don’t configure a build tool, Maven will be used by default, but XTC also supports Gradle as an alternative. In any case, please make sure that your load test project contains the respective build files and verify locally that the build produces the expected results.

To configure your preferred build tool, click the editing button, select a build tool and enter additional arguments for this tool if needed. Click Save Changes to confirm.

Build Dependency Cache

Building the load test suite before the actual start of the test may take several minutes to complete. Most of that time can be attributed to the download of dependencies (XLT and other required libraries).

XTC caches the downloaded dependencies of a load test project so subsequent builds should run much faster. The cache expires automatically 14 days after the last load test was run.

If you need to discard the cache (for example due to currupted or compromised artifacts), you can do so by going to this section and clicking Discard Cache.

Default Sharing Settings

To view default sharing settings, your account must at least have the role of a tester within the project.

To edit default sharing settings, your account must at least have the role of a test manager within the project.

In Sharing, you can define a default for the share expiration time of load test results and load test reports for easier project management. Each result or report sharing will offer this time as a default (but individual expiration times may still be configured if needed). Later on, all shares that use these defaults can be either deactivated, extended, or reactivated at once when required.

We recommend using the default because if the share expiration time needs to be adjusted/prolonged, you can set the new default and it will apply to all existing shares alike. This also includes disabling these shares.

The maximum lifetime of shares is limited to 180 days.

To use this feature, your account must at least have the role of a test manager within the project.

It is still possible to set individual expiration times per result and reports instead of referring to the global preset. These shares won’t be affected in any way when changing/disabling the project-wide default expiration date. To remove all custom links to reports or results, you can use the buttons Remove Custom Report Shares and Remove Custom Result Shares which you find below the default sharing settings. Both will prompt you to confirm this action, as it cannot be undone.

Properties

To view properties, your account must at least have the role of a tester within the project.

To edit properties, your account must at least have the role of a test manager within the project.

In Properties, you can globally define properties or secret properties to use for test execution.

Secret properties behave the same as regular properties. However, their values will be masked with ****** both in the load test report and in the result data set. When editing an existing secret property in the UI, its current value will be shown as ***. To redefine that setting, simply overwrite *** with the new value.

Properties configured at project level apply to all new load tests alike, while properties defined at a certain load test apply to that load test only. Load-test-level properties will overwrite project-level properties. Properties that are not set in XTC will be read from the project data.

Environment

Load tests are executed with XLT, Xceptance’s tool to drive load and performance tests. XLT is developed independently from XTC. New releases may come with improvements and also new features. New features may introduce incompatible changes, so from time to time we will need to release a new major version of XLT.

Incompatible changes in XLT may break your existing load test suites so XTC lets you choose between the previous and the new XLT execution environment. However, this choice is available for a limited time only.

The XLT support and deprecation policy is as follows: whenever a new major version of XLT is available, the previous major version is marked as deprecated, but remains available for another 8 weeks. This means while you can continue your current load testing activities uninterrupted, you should also plan and perform the migration of your test suite to the new XLT version in time. After the migration period of 8 weeks, the previous XLT version will be removed and the new version will be the only one available.

XTC helps to manage that transition. Project admins can define in the project settings which version of XLT should be the default one. Go to Project > Configuration > Execution > Execution Environment and choose an XLT version. You will want to adjust this setting when you start a new project or when you are done migrating your test suite. The default version will be effective when creating a new load test, but not when duplicating an existing one.

Testers may override this default for a particular load test in the settings of that load test. Open Load Test > Settings > Common Machine Configuration and choose the wanted version of the execution environment. Use this to test your migrated code (probably on another Git repository branch) with the new version, before switching to this version in general.

Last modified March 1, 2024