zeebe-cluster-testbench:测试平台针对Zeebe集群运行测试

# Zeebe Cluster Testbench Test bench to run tests against a Zeebe cluster. Available Documentation - [Developer handbook](docs/developer-handbook.md) - [Release Process](docs/release-process.md) - [Operator handbook](docs/operator-handbook.md) - [Technical documentation](docs/technical-documentation.md) - [Service Task Reference](docs/service-tasks.md) ## User Guide This document describes the different processes that are deployed as part of this project. These processes can either be launched directly - for ad hoc test runs - or they are launched by Zeebe as part of one of the periodic test protocols (e.g _Daily Test_). This document also contains a list of the available workers. Users are encouraged to use these workers and define and deploy additional processes based on these building blocks. ### Onion Principle This document will be easier to understand by learning first about the "onion principle":  This document (and this project) define processes at different levels of detail: - Test - this is the smallest level of detail. A test process performs a given test routine. It assumes that the test environment is already set up for the test, and will be cleaned up afterwards. Thus, it can focus entirely on executing a particular test - Test Process - this is the next level of detail. This layer is responsible for: - Spawning different variations for a test, if needed (e.g. run a test in different cluster plans; run the same test with different parameters) - Preparing the test environment for the test - Calling the test process - Recording test results, sending out notifications in case of test failures - Cleaning up the test environment after the test - Test Protocol - this is the outermost layer. This is comparable to a test suite. Some protocols (e.g. _Daily test_) also include the schedule for running tests. The purpose of the layering is to have reusable building blocks and separation of concerns between layers. The different layers work well together, but can also be called directly. E.g. instead of having the testbench generate a cluster, a user could create a cluster by hand and then call a given test with the needed authentication details for that cluster. ### Tests #### Sequential Test In the sequential test a sequential process is executed several times in succession. There is at most one active process instance at any given time. In other words, there is no parallelism - neither inside the process being tested nor in the test driver that starts process instances. A sequential test has the following parameters: - _steps_ - number of steps within the process - _iterations_ - number of times the process shall be executed - _maxTimeForIteration_ - the maximum duration for one iteration - _maxTimeForCompleteTest_ - the maximum time for the entire test This test will fail, if any of the following conditions occur: - there is an exception during test execution - a single iteration takes longer than _maxTimeForIteration_ - all iterations take longer than _maxTimeForCompleteTest_ In case of backpressure the iteration will be repeated. The time spent making requests that return backpressure responses and repeating those requests is included in the overall execution time, which must be smaller than _maxTimeForCompleteTest_ for the test to pass. ##### Sequential Test Process This process runs the sequential test in a given cluster in Camunda Cloud:  **Process ID:** `sequential-test` | Inputs | Description | Type | | ----------------------- | ----------------------------------------------- | ---------------------------------- | | `testParams` | Settings to parameterize the sequential test | `SequentialTestParameters` | | `authenticationDetails` | Credentials to authenticate against the cluster | `CamundaCloudAutenticationDetails` | | Outputs | Description | Type | | ------------ | ----------- | ------------ | | `testReport` | test report | `TestReport` | | `testResult` | test result | `TestResult` | #### Chaos Test This test runs a repertoire of [chaos experiments](https://github.com/zeebe-io/zeebe-chaos) against a given cluster. Different experiments run in sequence. The set of experiemnts to run depends on the cluster plan. See [inventoriy](https://github.com/zeebe-io/zeebe-chaos/blob/master/inventory.md) for more information on the available tests. ##### Chaos Test Process This process runs the chaos test in a given cluster in Camunda Cloud:  **Process ID:** `chaos-test` | Inputs | Description | Type | | ----------------------- | ------------------------------------------------------------------------------------- | ---------------------------------- | | `clusterPlan` | name of the cluster plan for the cluster; used to differentiate the chaos experiments | `String` | | `testParams` | Settings to parameterize the chaos test | tbd | | `authenticationDetails` | Credentials to authenticate against the cluster | `CamundaCloudAutenticationDetails` | | Outputs | Description | Type | | ------------ | ----------- | ------------ | | `testReport` | test report | `TestReport` | | `testResult` | test result | `TestResult` | ### Test Processes The testbench deploys several processes to orchestrate the test execution. The work flows reference each other - a higher level process will call a lower level process. However, lower level processes can also be called directly if only a certain test execution is wanted. #### Run All Tests in Camunda Cloud per Cluster Plan This process runs all tests in a fresh cluster in Camunda Cloud in different cluster plans:  **Process ID:** `run-all-tests-in-camunda-cloud-per-cluster-plan` | Inputs | Description | Type | | ---------------------- | -------------------------------------------- | -------------------------- | | `generation` | name of the generation for the cluster | `String` | | `clusterPlans` | names of the cluster plans for the clusters | `List<String>` | | `channel` | name of the channel for the cluster | `String` | | `region` | name of the region for the cluster | `String` | | `sequentialTestParams` | Settings to parameterize the sequential test | `SequentialTestParameters` | | Outputs | Description | Type | | ---------------------- | ------------------------------------------------ | ------------ | | `aggregatedTestResult` | Aggregated test result for all tests/experiments | `TestResult` | #### Run All Tests in Camunda Cloud per Region This process runs all tests in a fresh cluster in Camunda Cloud in different regions:  **Process ID:** `run-all-tests-in-camunda-cloud-per-region` | Inputs | Description | Type | | ---------------------- | -------------------------------------------- | --------------------------