企业官网建设流程全解析

Strimzi 系统测试实战指南：Test Phases、并行执行架构、测试分组与性能测试机制

【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator

Strimzi 的系统测试（System Test, 简称 ST）是验证 Cluster Operator 在真实 Kubernetes/OpenShift 集群上行为的最后一道防线。本篇基于仓库内的 development-docs/TESTING.md 完整展开，并深入systemtest模块源码（Environment、TestTags、并行执行类等），带你掌握：如何按 setup/exercise/test/teardown 四阶段组织测试、如何用 JUnit5 并行架构安全地跑多个测试套件、如何用标签（groups）筛选测试、如何用环境变量定制镜像与集群，以及性能测试（capacity/scalability）的报告产出与触发方式。

前置条件与依赖构建

运行任何系统测试前，需要满足两个前提：

1. 一个可用的 Kubernetes 或 OpenShift 集群，并且它必须位于你当前激活的 Kubernetes context 中。可以在本地用 minikube 搭建集群，也可以指向远程集群（远程集群见下文"使用远程集群"一节）。
2. systemtest包依赖的组件必须先构建完成，包括：test、crd-annotations、crd-generator、api、config-model、operator-common、kafka-oauth-client。

可以用如下任一命令完成构建：

mvn clean install -DskipTests # 或只构建 systemtest 及其上游依赖 mvn clean install -am -pl systemtest -DskipTests

之所以需要这些依赖，是因为测试代码中使用了test包里的工具方法以及api包中的 Strimzi CRD 模型类（如Kafka、KafkaConnect等）。

systemtest 包结构：main 与 test 的分工

systemtest模块按 Maven 惯例分为main和test：

• main（systemtest/src/main/java/io/strimzi/systemtest）：存放所有支撑类，供测试用例复用；
• test（systemtest/src/test/java/io/strimzi/systemtest）：存放各测试套件，如 KafkaST.java、ListenersST.java 等。

main中值得关注的模块：

main中值得关注的类：

• Environment（Environment.java）：单例类，负责加载测试所用的环境变量。从源码可见，它同时支持从环境变量和配置文件加载，例如ST_KAFKA_VERSION、SKIP_TEARDOWN、STRIMZI_FEATURE_GATES均通过ENVIRONMENT_VARIABLES.getOrDefault(...)取值，默认值如ST_KAFKA_VERSION_DEFAULT来自TestKafkaVersion.getDefaultSupportedKafkaVersion()；
• TestConstants（TestConstants.java）：以接口形式集中存放测试常量；测试分组标签常量则定义在 TestTags.java 中（如ACCEPTANCE = "acceptance"、REGRESSION = "regression"等）；
• resources/operator/SetupClusterOperator（SetupClusterOperator.java）：封装 Cluster Operator 的完整安装流程，包括RoleBinding、ClusterRoleBinding、ConfigMap、Deployment、CustomResourceDefinition和 Namespace 准备。Environment 的配置值决定安装方式（OLM / Helm / Bundle），并提供了rollbackToDefaultConfiguration()方法用于把 Operator 恢复为默认配置；若想定制安装细节，可调用defaultInstallation()获得SetupClusterOperatorBuilder；
• storage/TestStorage（TestStorage.java）：在特定ExtensionContext中生成并存储值，保证通过ExtensionContext（借助ConcurrentHashMap）在AbstractST内可取回对应数据；
• parallel/TestSuiteNamespaceManager（TestSuiteNamespaceManager.java）：在@BeforeAll执行之前为测试套件准备所需 Namespace，从而可以在 AbstractST.java 中统一准备命名空间，而不需要每个子类各自处理。

测试阶段：Setup / Exercise / Test / Teardown

Strimzi 系统测试遵循经典四阶段模型。

Setup 阶段

该阶段完成两件事：

1. 部署 Cluster Operator；
2. 部署共享 Kafka 集群及其他组件（可选）。

第二项之所以可选，是因为有些测试场景希望每个用例使用不同的 Kafka 配置，因此把 Kafka 集群及相关资源放到 test 阶段创建。用默认配置部署 Cluster Operator 的示例：

@BeforeAll void setup(ExtensionContext extensionContext){ // deploy Cluster Operator using default configuration SetupClusterOperator .getInstance() .withDefaultConfiguration() .install(); }

资源通过resources包中的类在 Kubernetes 集群里创建，可以随时用 builder 修改默认配置。资源生命周期实现会自动把资源压入当前测试的栈顶，并在测试方法/类结束后删除，因此你可以在任意位置创建资源。同时要始终使用Templates类提供的预定义资源。例如部署一个 3 节点 Kafka 集群：

final int numberOfKafkaBrokers = 3; KubeResourceManager.get().createResourceWithWait(extensionContext, // using KafkaTemplate class for pre-defined values KafkaTemplates.kafka( clusterName, numberOfKafkaBrokers).build() );

从源码结构看，ResourceManager内部维护Map<String, Stack<ResourceItem>>，即每个测试用例都有独立的资源栈，保存该用例创建的所有资源；而ExtensionContext.class保证能唯一地把"哪个栈属于哪个测试"对应起来。

在测试套件作用域内共享资源（并行异步创建 + 屏障同步）的示例：

@BeforeAll void setUp(ExtensionContext extensionContext) { // create resources without wait to deploy them simultaneously KubeResourceManager.get().createResourceWithoutWait(extensionContext, // 不等待就绪，所有资源异步部署 // kafka with cruise control and metrics KafkaTemplates.kafkaWithMetricsAndCruiseControlWithMetrics(...).build(), KafkaTemplates.kafkaWithMetrics(...).build(), KafkaMirrorMaker2Templates.kafkaMirrorMaker2WithMetrics(...).build(), KafkaBridgeTemplates.kafkaBridgeWithMetrics(...).build() ); // sync resources (barier) KubeResourceManager.get().synchronizeResources(extensionContext); }

Exercise 阶段

在该阶段编排覆盖某个具体功能所需的全部操作步骤。

Test 阶段

当环境在前一阶段就绪后，编写断言、消息收发等检查逻辑。

Teardown 阶段

资源生命周期实现保证与某个栈绑定的资源按正确顺序删除。teardown 在AbstractST的@AfterAll中触发：

@AfterAll void tearDownTestSuite(ExtensionContext extensionContext) throws Exception { afterAllMayOverride(extensionContext); }

如果想在@AfterAll中改变 teardown 行为，应覆写afterAllMayOverride()：

@Override protected void tearDownTestSuite() { doSomethingYouNeed(); super.afterAllMayOverride(); } // AbstractST 顶层的默认实现 protected void afterAllMayOverride(ExtensionContext extensionContext) throws Exception { install.unInstall(); // install 是 SetupClusterOperator 的实例 }

删除某个具体测试用例创建的所有资源只需：

KubeResourceManager.get().deleteResources(true);

KubeResourceManager会自动处理其余细节——它知道当前处于哪个测试与上下文，因此无需再传ExtensionContext。

新建测试套件

创建新测试套件时，务必保证类名以ST结尾（如KafkaST、ConnectBuilderST），这与 Maven 的it.test过滤规则保持一致（见下文"运行单个测试类"）。

并行执行测试：配置与架构

如何开启并行

本地并行运行系统测试需要修改两个 JUnit 属性，有两种途径：

1. IDE（IntelliJ）：在 build project 和 run 按钮之间点击"edit configuration"，然后在 VM options 中添加：
   • -Djunit.jupiter.execution.parallel.enabled=true
   • -Djunit.jupiter.execution.parallel.config.fixed.parallelism=4
2. Maven：在 mvn 命令中以额外参数覆盖，例如让ListenersST以 4 并行度运行：

# to run 4 test cases in parallel in ListenersST test class mvn verify -pl systemtest -P all -Dit.test=ListenersST -Djunit.jupiter.execution.parallel.enabled=true -Djunit.jupiter.execution.parallel.config.fixed.parallelism=4

并行架构三要素

1. JUnit5 并行机制

ForkJoinPool按配置生成指定数量的线程。

2. 注解（运行时覆盖并行配置）

• @IsolatedTest：基于@ResourceLock（禁止读写共享），确保该用例独占执行；
• @ParallelTest：通过@Execution(ExecutionMode.CONCURRENT)覆盖并行配置，用例与其他并行测试同时执行；
• @ParallelNamespaceTest：类似@ParallelTest，但额外会自动创建一个专属 Namespace 部署所有资源（适用于部署Kafka、KafkaMirrorMaker2这类场景）。

3. 辅助类

• TestSuiteNamespaceManager（parallel/TestSuiteNamespaceManager.java）：为特定测试套件提供完整的 Namespace 管理。
  • @ParallelSuite：该套件会创建自己的 Namespace（例如 TracingST 对应tracing-st），确保每个并行套件运行在隔离的命名空间；
  • @ParallelNamespaceTest：负责为这类测试用例创建和删除辅助 Namespace。
• SuiteThreadController（parallel/SuiteThreadController.java）：在测试用例（@ParallelTest、@ParallelNamespaceTest、@IsolatedTest）之间提供同步。

一个容易忽略的细节：ForkJoinPool由于 Work-Stealing 算法会生成超出并行度上限的（多余的）线程。源码层面用waitUntilAllowedNumberTestCasesParallel()与notifyParallelTestToAllowExecution()两个方法做同步：当套件结束时，若ForkJoinPool多出的线程可能突破上限，同时启动的套件可能压垮集群，此时机制会把多余线程全部放入"等待室"；等某个ParallelTest执行完毕，调用notifyParallelTestToAllowExecution()并置位isParallelTestReleased标志，保证只有一个用例继续执行，其余线程继续等待。

Cluster Operator 日志检查

每个测试结束后都会检查 Cluster Operator 日志，搜索非预期的错误或异常。基于 Hamcrest 的匹配器实现见 matchers/LogHasNoUnexpectedErrors.java。其中维护了一份"标准错误"清单——这些错误偶发出现，对集群行为没有实际影响，所需动作通常会在后续一次 reconciliation 中自动完成，因此不会判定测试失败。

测试分组（Test Groups）

执行某一组系统测试需要使用groups系统属性：

• -Dgroups=integration：执行单个测试组；
• -Dgroups=acceptance,regression：执行多个测试组；
• -Dgroups=all：执行所有测试组。

若未定义-Dgroups，则执行所有未显式声明测试组的测试。当前使用的标签如下表：

如果你的 Kubernetes 集群不支持 Network Policies 或 NodePort 服务，可以用-DexcludeGroups=networkpolicies,nodeport跳过这些测试。

Maven 配置 中还为主要分组提供了 profile：acceptance、regression、smoke、bridge、operators、components和all（以及performance等）。profile 通过 Surefire/Failsafe 的<groups>与it.test过滤实现，例如 performance 类 profile 固定使用<it.test>performance/**/*Performance*</it.test>。官方建议：默认使用allprofile，再通过 include/exclude 具体分组来收窄范围；若要指定 profile，用-P标志，例如-Psmoke。

所有测试分组标签常量集中定义在 TestTags.java 中（文档中提到的 Constants 类在当前仓库中对应TestTags/TestConstants两个类）。

系统测试的自动文档

每个系统测试套件都有一篇专属 Markdown 文档，位于 development-docs/systemtests 目录下。这些文件由测试源码中的@SuiteDoc和@TestDoc注解自动生成，内容包括：

• 测试套件的用途；
• 测试执行前的 setup 步骤（@BeforeAll）；
• 每个测试方法的分步操作与预期结果；
• 分配给每个套件和方法的标签。

测试还按标签组织在 development-docs/systemtests/labels 目录中。每个标签文件汇集共享该标签的所有测试方法（如kafka、connect、bridge、cruise-control），并链接回对应的测试套件文档。

环境变量配置系统

系统测试可通过多个环境变量定制，这些变量在测试执行前加载（实现见 Environment.java）。变量可以直接定义为环境变量，也可以放在任意路径的配置文件里——路径由ENV_FILE环境变量指定；若未定义ENV_FILE，则使用默认配置位置systemtest/config.yaml（该文件通常由开发者本地创建，不随仓库分发）。

系统配置加载优先级为：

1. 环境变量；
2. 配置文件中定义的变量；
3. 默认值。

每次系统测试运行结束后，所有环境变量会自动保存到$TEST_LOG_DIR/test-run.../config.yaml，因此任何一次测试运行都可以通过以下命令精确复现：

ENV_FILE="path/to/config/file/config.yaml" mvn verify ...

当前支持的环境变量及默认值：

几个值得注意的用法：

• 自定义镜像：若要用不同 tag 或其他仓库的镜像，组合使用DOCKER_REGISTRY、DOCKER_ORG、DOCKER_TAG；
• KUBERNETES_DOMAIN：仅当集群使用特定域名配置时才需要设置；
• 集群内部安全：CLUSTER_SECURITY_ENCRYPTION与CLUSTER_SECURITY_AUTHENTICATION决定整次测试运行中所有Kafka自定义资源的内部通信安全，机制是通过strimzi.io/internal-cluster-security注解下发。使用默认组合（tls加密 +mtls认证）时注解根本不会设置，以便同时覆盖 Cluster Operator 的默认行为。而专门验证内部集群安全配置的测试（如ClusterSecurityST）会自行设置注解，不受这两个变量影响。Operator 升级/降级测试（AbstractKRaftUpgradeST及其子类）与 OLM 测试（OlmAbstractST及其子类，如 OlmAbstractST.java）始终使用默认配置并忽略这些变量——因为它们的 Kafka 集群来自特定 Strimzi 发行版的 examples，且由可能不认识该注解的旧版 Cluster Operator 来协调；
• 指定 Kafka 版本：把ST_KAFKA_VERSION设为 kafka-versions.yaml 中的某个取值；
• 私有 registry：执行测试前需先创建 secret，再通过SYSTEM_TEST_STRIMZI_IMAGE_PULL_SECRET指定该 secret 名（注意 secret 必须创建在default命名空间）；
• KafkaConnect build 自定义 registry：由CONNECT_BUILD_IMAGE_PATH与CONNECT_BUILD_REGISTRY_SECRET控制。前者格式必须为<REGISTRY>/<ORGANIZATION>/<IMAGE_NAME>，且不能带浮动 tag——因为测试可并行执行，每次 connect build 需要唯一 tag，tag 由测试在运行时生成并追加。若 registry 需要认证，用CONNECT_BUILD_REGISTRY_SECRET指定推送用 secret（指向default命名空间的 k8s secret）。两个变量都不设置时，默认使用 Minikube 或 OpenShift 的 registry。

Cluster Operator 日志级别

通过环境变量STRIMZI_DEFAULT_LOG_LEVEL设置 Strimzi 在系统测试中的日志级别，可选值：ERROR、WARNING、INFO、DEBUG、TRACE。

使用远程集群

集成测试与系统测试针对TEST_CLUSTER_CONTEXT环境变量指定的集群运行。未设置该变量时，Kubernetes 客户端使用当前激活的 context；否则使用 KubeConfig 中名为TEST_CLUSTER_CONTEXT的 context。例如：

TEST_CLUSTER_CONTEXT=remote-cluster ./systemtest/scripts/run_tests.sh

注意：由于系统测试的某些动作走命令行Executor，务必让 shell 中激活的 context 与TEST_CLUSTER_CONTEXT保持一致。

辅助脚本

systemtest/scripts/run_tests.sh 可以用与 GitHub Actions 非常相似的配置来运行系统测试，适合高效执行systemtests工程。通过EXTRA_ARGS环境变量可以向mvn透传额外参数：

EXTRA_ARGS="-Dfoo=bar" ./systemtest/scripts/run_tests.sh

运行单个测试类

使用verify构建目标，并通过-Dit.test=TestClassName[#testMethodName]指定测试：

mvn verify -pl systemtest -P all -Dit.test=KafkaST#testJvmAndResources

也可以在启用特定 feature gate 的情况下运行测试：

STRIMZI_FEATURE_GATES="+FeatureName" mvn verify -pl systemtest -P all -Dit.test=KafkaST#testJvmAndResources

跳过 Teardown

调试某些类型用例时，SKIP_TEARDOWN变量非常有用（对应 Environment.java 中的SKIP_TEARDOWN，默认false）。设置后测试结束将跳过 teardown 阶段；并保持该设置不变时，后续 setup 阶段会快很多，因为组件已经部署好了。注意：对组件配置会发生变化的测试，这种方式不适用。

跳过 Surefire 测试

系统测试包内有少量单元测试用于验证systemtest内部工具类，它们通过 Maven Surefire 插件执行。可以在 mvn 命令中加-Dskip.surefire.tests跳过。

访问 GitHub Actions 日志

当 GitHub Actions 任务失败时，可以这样排查：

1. 在 pull request 上失败的检查旁点击View details，进入 workflow run 页面；
2. 滚动到页面底部的Artifacts区域（标注为Produced during runtime），每个 artifact 右侧都有直接下载链接；
3. 下载并解压对应 artifact，检查该次运行的日志。

通过 OLM 部署 Cluster Operator 的测试

Strimzi 支持通过 OperatorHub 部署 Cluster Operator，每个版本都需要更新的 manifest 并经过测试。仓库为此提供了 OLM 测试套件（systemtest/src/test/java/io/strimzi/systemtest/olm 目录，含OlmAbstractST、OlmSingleNamespaceST、OlmAllNamespaceST），它通过 OLM 部署 Cluster Operator 及其他所需组件，并使用 manifests 中的 examples。

运行这些测试前，需要构建一个带 manifests 的镜像并创建指向该镜像的新CatalogSource资源。Dockerfile 可以如下：

FROM quay.io/openshift/origin-operator-registry:latest COPY /manifests /manifests RUN /usr/bin/initializer -m /manifests -o bundles.db ENTRYPOINT ["/usr/bin/registry-server"] CMD ["-d", "bundles.db", "-t", "termination.log"]

构建新镜像后，创建形如以下的CatalogSource：

apiVersion: operators.coreos.com/v1alpha1 kind: CatalogSource metadata: name: strimzi-source namespace: openshift-marketplace labels: app: Strimzi spec: displayName: Strimzi Operator Source image: quay.io/myorg/myimage:latest publisher: Strimzi sourceType: grpc

之后即可高效运行 OLM 测试。

使用自定义镜像运行测试

对 Operator、Kafka 等组件使用自定义镜像运行 ST 有三种路径。

Bundle 安装方式（YAML 文件）

Bundle 安装是默认类型，有两种做法：

1. 更新 packaging/install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml 中与 Cluster Operator 相关的部分；若 DrainCleaner 也用了自定义镜像，还需更新 packaging/install/drain-cleaner/kubernetes/060-Deployment.yaml（当前实现统一取kubernetes部分，即使你运行在 OCP 上）。这样即使只构建了 operator 镜像，也只需改 operator 镜像引用，可精确控制改哪里；
2. 设置DOCKER_REGISTRY、DOCKER_ORG、DOCKER_TAG，它们会批量改写060-Deployment文件中所有镜像，适合流水线或全量构建场景。注意：Bridge 镜像会保持为官方 Quay.io Strimzi 仓库中最新的已发布 Bridge；且这三个变量不会影响 DrainCleaner 文件（本仓库不构建 DrainCleaner 镜像）。

重要：想用自己的自定义 Bridge 镜像，必须显式设置BRIDGE_IMAGE环境变量！因为BRIDGE_IMAGE默认值为latest-released，会阻止DOCKER_*变量重写 Bridge 镜像，未设置时始终使用官方发布的 Bridge 镜像。

Helm 安装方式

与 Bundle 类似，也有两种做法：

1. 更新 packaging/helm-charts/helm3/strimzi-kafka-operator/values.yaml，可逐镜像配置。但注意：ST 会把defaultImageRegistry、defaultImageRepository、defaultImageTag固定为官方镜像值（quay.io、strimzi、latest），不要手动改这三个字段，会被覆写；
2. 设置DOCKER_REGISTRY、DOCKER_ORG、DOCKER_TAG来改变上述三个默认值。同样，它适用于除 Bridge 镜像外的所有镜像。

重要：与 Bundle 方式一致，自定义 Bridge 镜像必须用BRIDGE_IMAGE环境变量，改values.yaml无效且会被官方 Bridge 镜像覆写。

OLM 安装方式

自定义 OLM 镜像并配合 OLM 安装方式运行测试，参见上文"通过 OLM 部署 Cluster Operator 的测试"一节以及OLM_前缀的环境变量。

性能测试

总览

Strimzi 系统测试中的性能测试分为两大类：**capacity（容量）**与scalability（可扩展性）。所有性能报告存放在systemtest/target/performance目录，包含详细 setup 配置与采集到的指标（含 JVM、内存、CPU 占用，如启用），每个测试还会生成一张汇总报告表。以scalabilityUseCase为例：

Use Case: scalabilityUseCase +------------+--------------------+-------------------------+----------------------+----------------------+---------------------------+------------------+-----------------------------------+ || Experiment | IN: MAX QUEUE SIZE | IN: MAX BATCH SIZE (ms) | IN: NUMBER OF TOPICS | IN: NUMBER OF EVENTS | IN: MAX BATCH LINGER (ms) | IN: PROCESS TYPE | OUT: Reconciliation interval (ms) | || 1 | 2147483647 | 100 | 25 | 75 | 100 | TOPIC-CONCURRENT | 9156 | || 2 | 2147483647 | 100 | 2 | 8 | 100 | TOPIC-CONCURRENT | 6147 | || 3 | 2147483647 | 100 | 250 | 750 | 100 | TOPIC-CONCURRENT | 24730 | || 4 | 2147483647 | 100 | 125 | 375 | 100 | TOPIC-CONCURRENT | 26827 | +------------+--------------------+-------------------------+----------------------+----------------------+---------------------------+------------------+-----------------------------------+

• IN:表示输入配置参数，如队列大小、batch 大小、topic 数量、事件数量等；
• OUT:表示产出的性能指标，如以毫秒计的 reconciliation 间隔。

性能测试相关源码集中在 systemtest/src/main/java/io/strimzi/systemtest/performance（常量见PerformanceConstants.java），测试用例如 TopicOperatorPerformance.java。

类别一：容量测试（Capacity Tests）

容量测试度量系统承受递增负载的能力，输出资源占用与运行上限洞察。

Topic Operator 容量测试

• 度量不同maxBatchSize与maxBatchLingerMs对系统吞吐和响应性的影响；
• 评估在不同批处理策略下 Kafka topic 创建、修改、删除的性能；
• 报告内容包括：最大 batch 大小、最大 batch linger 时间（ms）、成功创建的 Kafka topic 数量、topic operator 组件的指标历史。

User Operator 容量测试

评估 User Operator 在不同配置下的性能，包括：

• 控制器线程池大小；
• 缓存刷新间隔（ms）；
• 批处理队列大小；
• 最大 batch 阻塞大小与时间（ms）；
• 用户操作线程池大小；

报告内容包括：worker 队列大小、成功创建的 Kafka 用户数、详细系统指标与历史。

需要留意：这两个容量测试耗时较长——Topic Operator 平均23 分钟，User Operator 平均5 小时 22 分钟，具体取决于硬件规格。

重要：修改测试代码中的性能属性（例如TopicOperatorPerformance.java、TopicOperatorScalabilityPerformance等性能套件中的performanceAttributesmap）时，必须同步更新对应的 GitHub Actions 性能报告测试（维护测试输入目录与匹配PerformanceConstants.java中常量的预期输出，详见 .github/docs/README.md 的 Performance Report Tests 一节）。

类别二：可扩展性测试（Scalability Tests）

可扩展性测试评估 Strimzi 随负载增长时的扩展表现，帮助定位潜在瓶颈。

Topic Operator 可扩展性测试

• 测试 topic operator 在处理不同数量 Kafka topic 时的并发事件处理能力；
• 使用批处理模拟大规模真实 Kafka topic 操作；
• 度量不同 batch 大小下的 reconciliation 时间与资源占用；
• 报告内容：最大队列大小、处理的 topic 数、每个 reconciliation 周期处理的事件数。

该用例最多运行5 分钟。

触发方式

性能测试可通过 GHA、Jenkins 或本地（IDE / Maven，按标准系统测试方式）触发。

GHA：

/gha run pipeline=performance

Jenkins：按标准系统测试方式执行，例如运行TopicOperatorScalabilityPerformance：

@strimzi-ci run tests --profile=performance --testcase=TopicOperatorScalabilityPerformance

Maven 方式即使用performanceprofile（见 systemtest/pom.xml 中performance/**/*Performance*的it.test过滤）。

小结

Strimzi 系统测试体系的核心设计可以概括为：以AbstractST统一生命周期、以资源栈（KubeResourceManager）管理资源创建与清理、以Environment单一入口收敛全部环境变量、以 JUnit5 并行 +@IsolatedTest/@ParallelTest/@ParallelNamespaceTest注解 +SuiteThreadController线程同步保证隔离与限流、以LogHasNoUnexpectedErrors匹配器在每个用例后兜底检查 Operator 日志。配合groups/excludeGroups标签体系与自动生成的套件文档（development-docs/systemtests），开发者可以精确选择、复现和理解任意一组系统测试行为。

【免费下载链接】strimzi-kafka-operatorApache Kafka® running on Kubernetes项目地址: https://gitcode.com/GitHub_Trending/st/strimzi-kafka-operator