updates xtc 80 - 84 and xlt 8.0 - 8.2 (#237)

changes to monitoring, undo delete, and several smaller changes

content/en/xlt/load-testing/Advanced/200-maven-builds.md

@@ -73,7 +73,7 @@ To automatically copy all non-provided dependencies to `target/dependency` at co
 
 This ensures that all dependencies are present when the test suite is about to be uploaded to the agent machines.
 
-### Maven Build Steps
+## Maven Build Steps
 
 If you run a load test for your Maven test suite in [**XTC**]({{< relref "../../../xtc/loadtesting/120-load-project-configuration/#build" >}}), the following build steps will be executed:
 

content/en/xlt/load-testing/Advanced/210-gradle-builds.md

@@ -8,10 +8,10 @@ description: >
     How to build and run using Gradle.
 ---
 
-XLT supports using Gradle as a build tool for your test suite. You need the following entries in your `build.gradle` file:
-
 ## Integrating XLT into a Gradle project
 
+XLT supports using Gradle as a build tool for your test suite. You need the following entries in your `build.gradle` file:
+
 ### Plugins
 Include the following in your `build.gradle` file to use Gradle's Java plugin that adds basic compilation, testing and bundling capabilities for Java projects:
 
@@ -91,7 +91,7 @@ tasks.withType(JavaCompile) {
 
 This ensures that all dependencies are present when the test suite is about to be uploaded to the agent machines.
 
-### Gradle Build Steps
+## Gradle Build Steps
 If you run a load test for your Gradle test suite in [**XTC**]({{< relref "../../../xtc/loadtesting/120-load-project-configuration/#build" >}}), the following build steps will be executed:
 
 `gradle classes testClasses`

content/en/xlt/load-testing/How-Tos/mTLS.md

@@ -0,0 +1,44 @@
+---
+title: "Configuring mTLS for your XLT Test Suite"
+linkTitle: "mTLS"
+
+weight: 640
+type: docs
+
+
+description: >
+    How to set up your XLT test suite for using mTLS.  
+---
+
+In a zero-trust environment, not only must the client verify the server's identity, but the server must also verify the client's identity. This is known as [Mutual Transport Layer Security (mTLS)](https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/).
+
+XLT has always supported mTLS, and starting with XLT 8.2.0, it provides configuration options to set this up more conveniently and especially independent of your scenarios.
+
+To run tests with XLT in such environments, the underlying HtmlUnit WebClient must be configured with
+
+* a key store containing the client's private key, and
+* a trust store containing the certificate of the CA that signed the server key.
+
+The trust store setup is only needed if the server key was not signed by one of the well-known CAs that the JVM trusts out of the box.
+
+The key store containing the client key can be configured as follows:
+
+```
+com.xceptance.xlt.tls.keyStore.file = config/keystore.p12
+com.xceptance.xlt.tls.keyStore.password = <store-pw>
+```
+
+Note that the path to the key store must be relative to the root directory of your test suite. Also, if you want to password-protect the store, make sure that the key in the store is protected with the same password.
+
+The trust store with the CA certificate is set up this way:
+
+```
+com.xceptance.xlt.tls.trustStore.file = config/truststore.p12
+com.xceptance.xlt.tls.trustStore.password = <store-pw>
+```
+
+Typically, trust stores don't need to be password-protected.
+
+To create or modify the necessary keys, key store, and trust store, use Java's [keytool](https://docs.oracle.com/en/java/javase/11/tools/keytool.html) or [KeyStore Explorer](https://keystore-explorer.org/). Both provide ways to import existing keys and certificates in various formats, such as PEM. Make sure that the store format you choose matches the extension of the store file name (JKS -> `.jks`, PKCS#12 -> `.p12`, etc.).
+
+The last step is to configure the server with the client certificate or the appropriate CA certificate. Refer to your server software documentation for more information on how to do this.

content/en/xlt/load-testing/Manual/320-test-evaluation.md

@@ -151,6 +151,10 @@ The Page Load Timings section offers deeper insight into the page loading perfor
 
 The custom timers includes all timers that have been placed individually within the test code. The chart and data description is identical to the request section. In case custom samplers have been run during the test, the collected data is shown in the *Custom Values* section.
 
+### Web Vitals 
+
+If the load test was run as an [automated client performance test]({{< relref "600-client-performance/#measuring-client-performance-with-xlt" >}}) with Chromium browsers, this page displays the scores for all supported Web Vitals for each action in your scenarios. The score value is the 75th percentile of all observations and is rated as _good_, _needs improvement_, and _poor_ using the colors green, yellow, and red according to Web Vital-specific thresholds.
+
 ### External Data
 
 All external data gathered by other tools during the test run is shown here according to the configuration. See [Custom Data]({{< relref "../advanced/050-custom-data/" >}}) for details on how to include external data in the report.
@@ -161,6 +165,8 @@ This section consists of a table that contains all errors thrown by the test cas
 
 The Overview section lists the error message and the count. It ignores the stack trace to sum up common problems without relating them to the test case. The Details section beneath lists the full stack trace next to the test case and the directory in which you can find the data dump for further analysis.
 
+(The maximum number of paths to result browser directories for each different error entry is limited to 10 by default. Also, the number of errors for which stack traces are displayed is limited in order to prevent the report generator from running out of memory if there are numerous errors with different stack traces or exception messages. By default, a maximum of 500 stack traces are kept in memory. Both limits can be reconfigured in the report generator settings.)
+
 ### Events
 
 Events are used to indicate that the test has encountered a special situation that is not an error but too important to ignore or simply to write to the log. This section consists of a single table that lists all events that occurred during the test run including their name, amount, detail message and the name of the test case that produced this event.

content/en/xlt/load-testing/Manual/470-load-configuration.md

@@ -183,6 +183,10 @@ To ensure that a test scenario runs to completion even if the measurement period
 
 The **ramp-up period** (`rampUpPeriod`, as defined above as part of the load profile) is commonly put into the warm-up period to ensure the system under test is working at an optimal level before any measurements are taken. That's up to you though - it might as well be interesting to measure the system performance during the ramp-up phase. In that case, a warm-up period mustn't be defined.
 
+{{% warning title="Ramp-Up is Overwritten by Load Functions" %}}
+If a load test scenario defines a function instead of a constant value for either users, arrival rate, or load factor, that function alone defines the shape of the load curve. Any ramp-up parameters specified for this scenario are ignored in this case, and the ramp-up period will not be displayed in the _Load Profile_ section of the test report created for a run with this setting.
+{{% /warning %}}
+
 The following figure displays the phases in relation to the total test time:
 
 {{< image src="user-manual/chart_testprofile.svg" max-width="80%" >}}Load Test Profile Configuration

content/en/xlt/load-testing/Manual/530-reports.md

@@ -65,12 +65,29 @@ The overview section shows general information about both load tests. It lets yo
 * Errors
 * Events
 * Runtime
+* Runtime Percentiles
 
 #### Actions, Requests, Custom Timers
 
 * Count
 * Errors
 * Runtime
+* Runtime Percentiles
+
+#### Web Vitals
+
+* First Contentful Paint
+* Largest Contentful Paint
+* Cumulative Layout Shift
+* First Input Delay
+* Interaction to Next Paint
+* Time to First Byte
+
+#### Custom Values 
+
+* Count
+* Stats 
+* Percentiles
 
 ### Create a Performance Comparison Report
 

content/en/xlt/load-testing/Manual/550-report-configuration.md

@@ -284,7 +284,7 @@ com.xceptance.xlt.reportgenerator.maskPropertiesRegex = (?i)(password|passphrase
 By default, any property with the substring *password* in the name will
 be masked.
 
-## Limiting Error Charts
+## Limiting Error Charts and Information
 
 When analyzing and communicating the results of a load test, the
 *Errors* section is always of special interest. It does not only list
@@ -326,6 +326,21 @@ With these settings the report generator will create as many transaction
 error overview charts as needed, but only 10 transaction error detail
 charts and no request error charts at all.
 
+The _Errors_ page lists some paths to result browser directories for each different error entry. The maximum number of paths now limited to 10 by default, but this can be reconfigured as follows: 
+
+```bash
+com.xceptance.xlt.reportgenerator.errors.directoryLimitPerError = 10
+com.xceptance.xlt.reportgenerator.errors.directoryReplacementChance = 0.1
+```
+
+The latter setting defines the chance to replace directories when the maximum number of directories is reached ([0..1], default: 0.1, i.e. 10%). This ensures that directories processed earlier might also be replaced with directories processed later, resulting in a better sampling of directories across both agents and load test duration in the report.
+
+The report generator limits the number of errors for which stack traces are displayed in the load test report. This is to prevent the report generator from running out of memory if there are numerous errors with different stack traces or exception messages. By default, only 500 stack traces are kept in memory, but this limit can be reconfigured with this report generator property:
+
+```bash
+com.xceptance.xlt.reportgenerator.errors.stackTracesLimit = 500
+```
+
 ## Turning off Event Grouping by Test Case
 
 Events shown in the Event Details table are usually grouped by test case. In cases where you don’t need this grouping, you can turn it off via configuration in

content/en/xtc/basics/070-audit-log.md

@@ -12,15 +12,31 @@ description: >
 
 {{% permission type="project" least="true" role="project administrator" action="view the audit log for a project" %}}
 
-XTC comes with an Audit Log. Use this feature to learn which activity has been performed by which user at which time. This can be useful to check whether another user or the system triggered a change, and what exactly has been changed.
+XTC comes with an Audit Log. Use this feature to learn which activity has been performed by which user, or which API calls have been performed by which client ID at which time. This can be useful to check whether another user or the system triggered a change, and what exactly has been changed.
 
-The _Audit Log_ page in your **organization** shows just organization-related activities while the _Audit Log_ page in a **project** lists activities for that project only. 
+The _Audit Log_ page in your **organization** shows just organization-related activities while the _Audit Log_ page in a **project** lists activities for that project only. Both pages show the **User Audit Log** and the **API Audit Log** on separate tabs.
+
+**Entries in the audit log expire automatically after 180 days.**
+
+### User Audit Log
+
+In the user audit log, a table displays the most important details for organization- or project-related activities, such as time, activity type, user name and email. Each log entry can be expanded to show additional details, such as activity data where applicable.
 
 {{< image src="xtc/auditlog.png" >}}
-The audit log table of a load testing project.
+The user audit log table of a load testing project.
 {{< /image >}}
 
-Entries in the audit log expire automatically after 180 days.
+### API Audit Log
+
+The API audit log is conceptually similar to the user audit log, but contains different information. A table displays the most important details for an API call, such as time, activity type, request method, and URL. Each log entry can be expanded to show additional details, such as the client ID used, the user agent string, and additional input/output data where applicable.
+
+{{< image src="xtc/audit_log_api.png" >}}
+The API audit log table of a load testing project.
+{{< /image >}}
+
+{{% note notitle %}}
+Note that only API v2 endpoints are fully instrumented. The API v1 endpoints generate certain audit events, especially on error, but lack full coverage.
+{{% /note %}}
 
 ### Filtering the Audit Log
 

content/en/xtc/loadtesting/140-overview.md

@@ -62,4 +62,6 @@ To delete several load tests at once, select the load tests in question using th
 {{< image src="xtc/loadtest_bulkDelete.png" >}}
 {{< /image >}} 
 
-This action cannot be undone. It will permanently delete all data that was collected by the tests. To prevent an accidental deletion, you will be prompted to check the list of selected tests and confirm.
+To prevent an accidental deletion, you will be prompted to check the list of selected tests and confirm. 
+
+In case you still accidentally deleted a load test, XTC allows you to **restore** it within 30 days after deletion. Click the _Show Deleted Items_ entry in the 3-dot load tests table menu to list the tests that can be restored. To restore a particular test, click _Undo Deletion_ in the context menu of that test. To switch the view back to the live items, click _Hide Deleted Items_ in the table menu.

content/en/xtc/loadtesting/155-lt-settings.md

@@ -27,6 +27,12 @@ Under _Load Profile_ you can override the settings in your test suite for the [t
 
 The load profile settings are only needed if you want to override your test suite settings for some reason, e.g. quickly changing the test duration or load factor without pushing changes to the repository, or switching between your prepared test property files. If the fields are left empty, the settings in the test suite will be used.
 
+When overriding the load profile settings for a particular load test, you must specify a value for each parameter, including the ramp-up and shutdown times. Load Factor formulas are only allowed if ramp up time equals zero. The resulting load curve is shown in a graph next to the settings then:
+
+{{< image src="xtc/load_profile_overwrite.png" >}}
+Overwriting the Load Profile with a Load Function
+{{< /image >}}
+
 Learn more in our _Load Testing_ section about [configuring load profiles]({{< relref "/xlt/load-testing/manual/470-load-configuration" >}}) for your test run.
 
 ### Machine Configuration

content/en/xtc/loadtesting/160-start-lt.md

@@ -28,7 +28,7 @@ Start or schedule the configured load test on the test page.
 
 You will be prompted to confirm that you want to start the load test with the given settings now. If you click _Start Load Test_ XTC will start the load test by 
  * downloading the current state of the test suite project from the repository
- * building the project (in case a technical error occurred when building the load test suite, the whole build process, including any preparative steps, is being retried),
+ * building the project (in case a technical error occurred when building the load test suite, the whole build process, including any preparative steps, is being retried - this also applies when XTC detects an integrity issue for the cached local Maven repository of the load testing project, so the build will fetch all required dependencies anew and update the cache such that subsequent builds can profit from it again),
  * provisioning the requested agents and, if this was successful, 
  * run the provided test scenarios for the configured time.
 

content/en/xtc/loadtesting/175-results.md

@@ -58,6 +58,4 @@ In fact, creating a new custom report in the _Reports_ tab does the same thing a
 
 Finally, if you don't need a generated result set any longer, you may want to delete it to save storage space. To do this, just click _Delete_ in the result set's context menu. You will be prompted to confirm that you really want to delete the results. 
 
-{{% warning notitle %}}
-Please note that when deleting load test results from XTC, they are truly deleted from the backing file storage, so this process **cannot be undone**.
-{{% /warning %}}
+In case you accidentally deleted some test results, XTC allows you to **restore** them within 30 days after deletion. Click the _Show Deleted Items_ entry in the 3-dot results table menu to list the items that can be restored. To restore a particular item, click _Undo Deletion_ in the context menu of that item. To switch the view back to the live items, click _Hide Deleted Items_ in the table menu.

content/en/xtc/loadtesting/180-reports.md

@@ -164,9 +164,7 @@ Even if a load test report can already be viewed, the corresponding report archi
 
 Finally, if you don't need a generated report any longer, you may want to delete it to save storage space. To do this, just click _Delete_ in the report's context menu. You will be prompted to confirm that you really want to delete the report. 
 
-{{% warning notitle %}}
-Please note that when deleting load test reports from XTC, they are truly deleted from the backing file storage, so this process **cannot be undone**.
-{{% /warning %}}
+In case you accidentally deleted some test report, XTC allows you to **restore** it within 30 days after deletion. Click the _Show Deleted Items_ entry in the 3-dot reports table menu to list the items that can be restored. To restore a particular item, click _Undo Deletion_ in the context menu of that item. To switch the view back to the live items, click _Hide Deleted Items_ in the table menu. Please note that load test reports that were publicly shared must be re-shared after restoring.
 
 ## Errors on Report Creation
 

content/en/xtc/monitoring/420-monitoring-configuration.md

@@ -25,10 +25,19 @@ The _Configuration_ of a monitoring project is very similar to the basic [projec
 
 Another specialty for _Repository Configuration_ is that you can define the branch to use by either specifying its name (static branch) or by defining a URL of a resource from which the branch name can be extracted dynamically using a regular expression. (This may be useful if you want to make the used test scenario code dependent on your currently deployed app version.)
 
-### Quiet Periods
+### Defining Scenario Defaults
+
+On the _Scenario Defaults_ tab in _Configuration_ you can define [default settings]({{< relref "440-scenario-setup/#scenario-settings" >}}) and [manage notification settings]({{< relref "440-scenario-setup/#notifications" >}}) to be used for all monitoring scenarios. These defaults can be overwritten for each individual scenario. To view or edit scenario defaults, use the toggle on the right to expand the default section, where you will find one or more editing buttons next to the settings:
+
+{{< image src="xtc/monitoring_scenario_defaults.png" >}}
+The scenario defaults tab with expand toggle and editing button.
+{{< /image >}}
+
+## Quiet Periods
 
 {{% permission type="project" least="true" role="test manager" action="configure the quiet periods" %}}
 
 You can define _Quiet Periods_ for your monitoring projects. These are time spans in which no [notifications]({{< relref "440-scenario-setup#notifications" >}}) will be sent (and, if you configure this, no scenarios will run). 
 
-To add a new quiet period, click the `+` symbol at the top of the Quiet Periods list. You may then define a label, a start time and an end time, and configure whether or not scenarios should be executed in this period. The newly created quiet period will then show up in the list. All periods in the list can be edited, disabled or removed, no matter whether they are in the future, in the past or currently active. 
+To add a new quiet period, click the `+` symbol at the top of the Quiet Periods list. You may then define a label, a start time and an end time, and configure whether or not scenarios should be executed in this period. The newly created quiet period will then show up in the list. All periods in the list can be edited, disabled or removed, no matter whether they are in the future, in the past or currently active. 
+