企业官网建设流程全解析

Wazuh 测试执行指南：单元测试与集成测试的编译、运行与验证全流程

【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh

导读

Wazuh 作为开源安全平台（XDR 与 SIEM），其代码库横跨 C 语言核心守护进程、Python API/Framework、多平台 Agent（Linux、Windows、macOS），测试体系也因此分层设计：以 CMocka 为框架的 C 单元测试覆盖核心组件，以 pytest 为驱动的 Python 测试覆盖 API 与 Framework，再配合 Docker 化的 Tavern 集成测试验证完整 Wazuh 环境下的模块协作。本文基于仓库中的 docs/dev/test-execution.md 及配套源码，系统讲解如何安装依赖、编译带测试钩子的 Wazuh 二进制、构建并运行各平台单元测试、执行 API/Framework 测试，以及部署 12 容器 Docker 环境运行 API 集成测试。读完本文，你将掌握 Wazuh 全部测试层级的可复现执行命令与排障要点。

一、测试体系总览

Wazuh 的测试分为两大类别，每类下又按被测对象细分：

核心思路是：C 组件单元测试需要先用TEST=1编译 Wazuh，使内部符号与测试钩子暴露给测试包装器；API/Framework 测试直接使用 Python 环境与真实 API 交互；而 API 集成测试则通过 Docker 拉起一个完整的 Wazuh 集群环境，用 Tavern 以 YAML 声明式用例逐端点验证。

二、核心组件单元测试

2.1 前置要求

运行 C 单元测试需要以下工具链：

1. 编译工具（GCC 与/或 MinGW）
2. CMake 3.10 或更高版本
3. Wine（仅在执行 Windows agent 测试时需要）
4. CMocka（C 单元测试框架）

从源码看，src/unit_tests/CMakeLists.txt 明确声明了cmake_minimum_required(VERSION 3.10)，并对TARGET参数进行强制校验（manager/agent/winagent，不匹配即FATAL_ERROR）。同时在include_directories中引入了src/shared/include、src/config/include、src/client-agent、src/syscheckd、src/wazuh_db/include以及全部shared/os_crypto、external子库头文件，并通过add_definitions(-DWAZUH_UNIT_TESTING)打开测试专用宏，这正是单元测试能访问内部符号的关键。

Ubuntu 依赖安装：

sudo apt-get update -y sudo apt-get install -y gcc-mingw-w64 make python3 gcc g++ cmake libc6-dev curl policycoreutils automake autoconf libtool libssl-dev lcov

macOS 依赖安装（Homebrew）：

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)" brew install cmake brew install cmocka brew install lcov

需要说明的是，仓库中 src/unit_tests/Readme.md 提供了比本文档更新的依赖建议（例如在 Ubuntu 上优先安装gcc-14 g++-14 libcmocka-dev，并要求 CMake 3.22.1+、macOS 上从源码安装 CMocka 1.1.7），如果你使用的是较新的发行版，可以优先参考该文档的版本要求。

2.2 编译带测试标志的 Wazuh

要针对特定目标运行单元测试，必须先用TEST选项构建项目：

make TARGET=server|agent|winagent TEST=1

注意两点：

• 仓库 src/Makefile 中将server与manager视为等价目标（ifeq (${TARGET},server) override TARGET := manager），因此make TARGET=server与make TARGET=manager效果相同；Makefile 的帮助信息也明确列出了三个受支持目标：manager、agent、winagent。
• TEST=1构建会在src/build/lib下产出单元测试包装库libwazuh_test.a（以及libconfig.a、libwazuh_modulesd_lib.a）。src/unit_tests/CMakeLists.txt 通过find_library在${SRC_FOLDER}/build/lib中查找这三个库，找不到会直接FATAL_ERROR中止——因此必须先完成make TEST=1编译，再进入unit_tests构建测试。

2.3 Linux 目标（server / agent）单元测试

进入src/unit_tests目录（文档中的wazuh/src/unit_tests即仓库根目录下的src/unit_tests），执行：

mkdir build cd build cmake -DTARGET=server|agent .. make

CMake 配置阶段指定的 TARGET 必须与编译 Wazuh 时使用的目标一致，且 Wazuh 需已预先编译完成。CMake 会根据 TARGET 引入不同的构建清单并复制对应的测试配置文件：src/unit_tests/CMakeLists.txt 中，manager目标会include("./server.cmake")并复制 4 个漏洞检测配置文件；agent目标会include("./agent.cmake")并复制 3 个防篡改（anti-tampering）配置文件；同时只有manager目标不构建syscheckd子目录。

测试运行有三种方式：

方式一：批量运行全部测试

ctest

CTest 会运行所有可用测试并把结果输出到控制台。如需更多细节，可查看运行后生成的build/Testing/Temporary/LastTest.log。

方式二：生成覆盖率报告

make coverage

测试会先执行，若全部通过，将生成coverage-report目录，内含 HTML 格式覆盖率报告。这一目标在 src/unit_tests/CMakeLists.txt 中实现：它依次调用lcov --zerocounters清零计数器、建立基线coverage.base、执行ctest、抓取coverage.info、合并得到coverage.total，再按目标排除external/、unit_tests/、data_provider/、shared_modules/、engine/以及各 C++ 模块（如wazuh_modules/vulnerability_scanner）等不在遗留 C 测试覆盖范围内的路径，最后用genhtml生成 HTML 报告。构建环境需要安装lcov、gcov、genhtml（Ubuntu 的lcov包通常已包含三者，CMake 会逐一find_program校验，缺失即报错）。

方式三：运行单个测试

进入测试所在的子目录，像运行普通 Linux 二进制一样执行。例如测试create_db.c：

cd syscheckd ./test_create_db

测试输出直接打印到控制台。仓库src/unit_tests下按模块组织了大量测试二进制源文件，例如 src/unit_tests/syscheckd 下的test_create_db.c、src/unit_tests/wazuh_modules/agent_upgrade 下的test_wm_agent_upgrade*.c系列、以及shared、config、os_xml、os_regex、os_crypto等目录中的测试，均可按同样方式单独编译运行。

2.4 Windows agent 单元测试（Linux 主机交叉编译）

Windows agent 测试同样需要 CMake 3.10+、CMocka，外加 32 位 Wine 运行时。构建命令与 Linux 目标的关键区别在于传入 MinGW 交叉编译工具链文件：

mkdir build cd build cmake -DTARGET=winagent -DCMAKE_TOOLCHAIN_FILE=../Toolchain-win32.cmake .. make

CMAKE_TOOLCHAIN_FILE让 CMake 正确配置交叉编译。查看 src/unit_tests/Toolchain-win32.cmake 可知其核心内容：

• CMAKE_SYSTEM_NAME Windows：声明目标系统为 Windows；
• 编译器前缀i686-w64-mingw32，即使用i686-w64-mingw32-gcc/g++/windres/ar/ranlib；
• find_program(WINE "wine")并设置CMAKE_CROSSCOMPILING_EMULATOR wine，使ctest能通过 Wine 执行.exe测试程序。

运行测试同样有三种方式，区别在于测试程序需借助 Wine：

批量运行：

ctest

CTest 会通过 Wine 运行所有测试并展示结果；详细输出在build/Testing/Temporary/LastTest.log。

覆盖率报告：

make coverage

测试通过后在coverage-report目录生成 HTML 报告。

运行单个测试：

cd syscheckd wine test_create_db.exe

2.4.1 为 Windows 目标交叉编译 CMocka

CMocka 是编译与运行单元测试套件的必需品。对 server 和 Linux agent 测试，用包管理器安装的二进制版本即可；但要运行 Windows agent 测试，必须用 MinGW 编译器从源码构建 CMocka（Ubuntu 的 mingw 包不附带 cmocka）：

1. 克隆 CMocka 仓库：

git clone https://git.cryptomilk.org/projects/cmocka.git

2. 检出stable-1.1分支（Wazuh 的测试包装器按 CMocka 1.1 API 编写）。

3. 修改DefineOptions.cmake，将BUILD_SHARED_LIBS设为OFF（构建静态库）。

4. 在仓库目录内交叉编译：

mkdir build cd build cmake -DCMAKE_C_COMPILER=i686-w64-mingw32-gcc -DCMAKE_C_LINK_EXECUTABLE=i686-w64-mingw32-ld -DCMAKE_INSTALL_PREFIX=/usr/i686-w64-mingw32/ -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_BUILD_TYPE=Release .. make sudo make install

这样cmocka.h头文件与静态库libcmocka.a会被安装到/usr/i686-w64-mingw32/下，供 Wazuh 交叉编译时引用。若跳过此步，编译期会以fatal error: cmocka.h: No such file or directory失败。

如果是为 Linux 目标构建 CMocka，保持BUILD_SHARED_LIBS为ON即可：

mkdir build cd build cmake -DCMAKE_BUILD_TYPE=Release .. make sudo make install

注意：重建 CMocka 前务必清空build目录中的全部旧文件。

2.4.2 安装 32 位 Wine（Ubuntu）

Wazuh 的 winagent 测试二进制是 32 位，需要 32 位 Wine：

# 添加 32 位架构 sudo dpkg --add-architecture i386 # 添加 WineHQ 密钥 wget -qO - https://dl.winehq.org/wine-builds/winehq.key | sudo apt-key add - ### 添加仓库（Ubuntu 19.10） sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ eoan main' ### 添加仓库（Ubuntu 18.04） sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ bionic main' sudo add-apt-repository ppa:cybermax-dexter/sdl2-backport ### 添加仓库（Ubuntu 16.04） sudo apt-add-repository 'deb https://dl.winehq.org/wine-builds/ubuntu/ xenial main' # 安装 sudo apt update sudo apt install --install-recommends winehq-stable ### 若出现依赖错误，改用 aptitude sudo apt install aptitude sudo aptitude install winehq-stable # 检查版本 wine --version # 链接 wine 二进制 sudo ln -s /opt/wine-stable/bin/wine /usr/bin/

原文档同时建议：若需在 CentOS 7 上运行测试，可参考社区指引构建 32 位 Wine。需要提醒的是，上述 apt 源命令针对的是 Ubuntu 19.10/18.04/16.04 等较旧版本；在更新发行版上应改用 WineHQ 官方针对该发行版（如 noble/jammy）的.sources仓库方式，仓库 src/unit_tests/Readme.md 中给出了 Ubuntu 24.04 的完整命令（含libc6:i386等 32 位运行库与版本钉扎示例）。

2.4.3 配置 Wine 运行环境

安装完成后，需要设置WINEPATH与WINEARCH两个环境变量，让 Wine 以 32 位模式运行并找到测试所需的全部 DLL：

export WINEPATH="/usr/i686-w64-mingw32/lib;/usr/lib/gcc/i686-w64-mingw32/13-posix;/path/to/wazuh/src;/path/to/wazuh/src/build/bin" export WINEARCH=win32

建议将这两行加入~/.bashrc。WINEPATH使用分号分隔（Windows 风格），依次指向 MinGW 运行库、GCC posix 线程模型运行库（提供libstdc++-6.dll、libwinpthread-1.dll等）、Wazuh 源码目录以及src/build/bin（Wazuh 自身构建出的 DLL 所在位置）。WINEARCH=win32强制 Wine 前缀为 32 位。

如果 Wine 报错说它是 64 位安装，请删除或重命名~/.wine目录后重新运行（64 位前缀无法降级为 32 位）。另外注意，13-posix路径对应 Ubuntu 24.04 自带的 GCC 13.x MinGW；其他发行版请用ls /usr/lib/gcc/i686-w64-mingw32/确认实际目录名。

2.5 macOS agent 单元测试

macOS agent 测试与 Linux 目标类似，也要求 CMake 3.10+ 与 CMocka，但需要先把 Homebrew 库目录暴露给链接器：

export LIBRARY_PATH=$LIBRARY_PATH:/usr/local/lib mkdir build cd build cmake -DTARGET=agent .. make

TARGET=agent的 Wazuh 必须预先编译。测试的运行方式与 Linux 系统一致（ctest / make coverage / 单测二进制直跑）。

2.6 从源码安装新版 CMake 与排障提示

如果apt-get或yum安装的 CMake 低于 3.10，先卸载，再从源码安装：

mkdir ~/temp cd ~/temp wget https://cmake.org/files/v3.17/cmake-3.17.0-rc1.tar.gz tar -xzvf cmake-3.17.0-rc1.tar.gz cd cmake-3.17.0-rc1/ ./bootstrap make sudo make install

切换目标前清理构建环境：不同 TARGET 的构建产物互不通用。从 src/unit_tests/Readme.md 可知，切换目标（如 agent → winagent）前应在src/下依次执行make clean与make clean-deps，否则会出现令人困惑的链接错误或编译器版本不匹配问题。

三、API 与 Framework 单元测试

API 与 Framework 的测试基于 pytest，属于纯 Python 测试，不需要编译 C 代码。

3.1 准备 Python 环境

确保安装正确的 Python 版本——所需版本定义在仓库根目录的 .github/workflows/.python-version-it 中，当前为3.11。

可选地，创建并激活虚拟环境：

python -m venv venv source venv/bin/activate pip install -r framework/requirements-dev.txt

3.2 执行测试

• API 测试：

python -m pytest api/api

这会在 api/api 目录下收集并运行测试。该目录中与测试相关的内容包括 api/api/test/test_alogging.py、api/api/test/test_authentication.py、api/api/test/test_configuration.py、api/api/test/test_encoder.py、api/api/test/test_error_handler.py、api/api/test/test_middlewares.py、api/api/test/test_signals.py、api/api/test/test_uri_parser.py、api/api/test/test_util.py 与 api/api/test/test_validator.py 等，覆盖日志、鉴权、配置加载、编解码、异常处理、中间件、信号、URI 解析、工具函数与参数校验等 API 内部组件。

• Framework 测试：

python -m pytest framework

该命令遍历 framework 目录，覆盖 framework/wazuh 下的 agent、cluster、manager、mitre、security、stats、task 等核心模块（其测试文件位于 framework/wazuh/tests，如 framework/wazuh/tests/test_agent.py、framework/wazuh/tests/test_cluster.py 等），以及 framework/wazuh/rbac/tests 下的 RBAC 相关测试。framework/pytest.ini 配置了asyncio_mode=auto等选项以支持异步测试。

四、核心组件集成测试

集成测试验证的是各守护进程与模块在真实 Wazuh 环境中协同工作的行为，测试代码位于仓库 tests/integration 目录。

4.1 准备 Python 环境

同样要求 Python 3.11（见 .github/workflows/.python-version-it），建议使用虚拟环境：

python -m venv venv source venv/bin/activate pip install --upgrade pip

4.2 安装 Wazuh 与 QA 集成测试框架

先安装被测版本的 Wazuh（从源码或安装包均可），然后安装 Wazuh 的 QA 集成测试框架（选择一个合适的 QA 分支）：

git clone -b "$QA_BRANCH" --single-branch https://github.com/wazuh/qa-integration-framework.git sudo pip install qa-integration-framework/ rm -rf qa-integration-framework/

该框架（wazuh_testing包）为集成测试提供了守护进程控制、配置生成、日志监控、Agent 模拟器（agent_simulator、authd_simulator、remoted_simulator）等基础设施，参见 tests/integration/conftest.py 顶部的导入与 tests/integration 下各测试套件的实际使用。

4.3 运行测试并生成报告

进入集成测试目录并按 Tier 筛选运行：

cd tests/integration python -m pytest \ --tier <TIER> \ <TEST FOLDER>/ \ --html=results.html \ --self-contained-html

其中<TIER>对应测试的分级标记。查看 tests/integration/pytest.ini，其声明了tier(level)、darwin、linux、win32、server、agent等 markers，并开启--strict-markers。仓库 tests/integration 下的测试套件包括test_agentd、test_api、test_authd、test_aws、test_fim、test_logcollector、test_remoted、test_sca、test_syscollector、test_wazuh_db等，每个目录内含 pytest 用例与 YAML 数据文件。

测试执行完成后会生成 HTML 报告：

tests/integration/results.html

五、API 集成测试

API 集成测试用于验证 API 在完整 Wazuh 环境中的正确工作——即各应用模块集成后的交互行为是否符合预期。这套测试全部位于 api/test/integration 目录，环境通过 Docker 构建。

5.1 测试文件结构与命名

API 集成测试用例使用Tavern框架编写。Tavern 是一个基于 pytest 的 API 测试框架（支持 HTTP、MQTT 等协议），用例文件用 YAML 语言书写，命名格式为：

test_{module}_endpoints.tavern.yaml # 或 RBAC 模式 test_rbac_{rbac_mode}_{module}_endpoints.tavern.yaml

其中module是被测端点所属的模块，rbac_mode是测试使用的 RBAC 模式（white 或 black）。仓库中现存的用例文件印证了这一规律，例如 api/test/integration/test_agent_GET_endpoints.tavern.yaml、api/test/integration/test_cluster_endpoints.tavern.yaml、api/test/integration/test_security_POST_endpoints.tavern.yaml、api/test/integration/test_task_endpoints.tavern.yaml，以及 RBAC 系列的 api/test/integration/test_rbac_white_all_endpoints.tavern.yaml、api/test/integration/test_rbac_black_agent_endpoints.tavern.yaml 等。

以一个典型用例为例，api/test/integration/test_agent_GET_endpoints.tavern.yaml 中的GET /agents测试分为多个 stage：先请求根路径获取 API 版本，再携带Bearer {test_login_token}请求/agents，断言返回 12 个 agent（ID001~012），随后用tavern_utils:test_sort_response校验sort=-id、sort=os.name,os.major、sort=-version,id等排序行为。公共变量（协议、主机、端口、凭据、延迟参数、各类 XML 配置模板）定义在 api/test/integration/common.yaml，并通过 api/test/integration/pytest.ini 的tavern-global-cfg=common.yaml全局注入。

5.2 Docker 测试环境

API 集成测试环境用 Docker 构建，由12 个容器组成：

• 3 个 Wazuh manager，组成一个 Wazuh 集群（1 个 master + 2 个 worker）；
• 4 个 Wazuh agent，与 manager 同版本；
• 4 个旧版本（4.14.1）agent；
• 1 个 HAProxy 负载均衡器。

manager 与非旧版 agent 使用的 Wazuh 版本由执行测试的分支决定。此外还模拟了2 个断连（disconnected）和 2 个从未连接（never-connected）的 agent。

环境定义与部署文件分布在 api/test/integration 子目录中：docker-compose.yml位于env目录；Dockerfile、entrypoint.sh及其他配置文件位于base目录；针对不同测试的配置与健康检查位于configurations目录；健康检查常用的 Python 脚本位于tools目录。

端口约定（见 api/test/integration/common.yaml）：55000为 master、55001为 worker1、55002为 worker2、55010为 HAProxy 负载均衡入口。测试凭据默认为用户testing/ 密码wazuh，登录端点为security/user/authenticate。

5.3 环境自动部署机制（conftest.py）

环境的部署在运行测试时自动完成——执行pytest <test_name>即可。api/test/integration/conftest.py 是环境部署的核心：

• 通过@pytest.fixture(scope='session', autouse=True)定义api_testfixture，任何测试执行时都会自动触发；
• 它从测试文件名解析出rbac_mode与module，据此调用change_rbac_mode()/enable_white_mode()修改security.yaml中的 RBAC 模式，调用rbac_custom_config_generator()生成自定义 RBAC SQL 脚本（写入custom_rbac_schema.sql），调用general_procedure()把base与模块专属配置合并复制到临时目录供容器 entrypoint 消费；
• build_and_up()读取当前 Git 分支，以WAZUH_BRANCH作为 build-arg 执行docker compose build --no-cache与docker compose up -d（最多重试 3 次），构建 manager 镜像时会先探测 GitHub 上该分支的 tarball 是否存在，不存在则直接判失败；
• 环境启动后，check_health()通过docker inspect轮询 master/worker1/worker2、8 个 agent 与 HAProxy 的健康状态，最长等待约 300 秒，同时检查 master 容器内/entrypoint_error是否记录了 entrypoint 失败；
• 测试结束后，finalizer 清理临时配置目录，若存在失败用例则调用save_logs()用docker cp收集各节点日志（api.log、cluster.log、wazuh-manager.log、各 agent 的ossec.log、HAProxy 日志）到_test_results/logs，并记录环境最终状态后执行docker compose down -v。

conftest.py 还通过 pytest-html 钩子定制了 HTML 报告的样式与汇总表，并提供了big_events_payload（101 条事件）、max_size_event（12772 词条）、large_event（12773 词条）等 fixture，用于测试事件上限类场景。

由于环境固定以集群模式运行，测试执行命令与环境的关系是确定的：

5.4 RBAC API 集成测试

test_rbac_{rbac_mode}_{module}_endpoints.tavern.yaml这类测试用于验证带 RBAC 配置的 Wazuh 环境行为。conftest.py中包含切换 RBAC 模式与创建指定 RBAC 资源的函数；env/configurations/rbac目录存放了每个 RBAC 测试（white 与 black 两种模式）的专属配置。

理解两个模式的关键语义（见 api/test/integration/conftest.py 的change_rbac_mode()注释）：Black 模式默认全部允许，White 模式默认全部拒绝。RBAC 测试没有使用任何 pytest mark，运行它们时无需也不能指定 mark——一旦指定过滤条件，测试会被过滤器全部筛掉；换言之，RBAC 测试总是在默认的集群环境下执行。以 api/test/integration/test_rbac_white_all_endpoints.tavern.yaml 为例，其开头注释列出了无需权限的例外端点（如GET /、DELETE|POST /security/user/authenticate、GET /security/users/me等），随后各 stage 验证白名单模式下越权操作返回403与error: 4000。

此外，api/test/integration/mapping/integration_test_api_endpoints.json 记录了 API 源码文件到集成测试用例的映射关系（例如authentication.py由 agent/cluster 等端点的 tavern 用例覆盖），可用于评估测试覆盖面。

5.5 测试环境依赖与执行示例

运行 API 集成测试需要一个特定的 Python 3 环境，依赖版本如下：

pytest==5.4.3 requests==2.23.0 pyaml==21.10.1 tavern==1.0.0 pykwalify==1.7.0 pytest-html==2.1.1

另外，docker-compose版本要求1.28.0 或更新，但不能是 2.X.Y——2.x 的破坏性变更会导致 API 集成测试环境构建失败。

满足上述条件后即可执行测试，例如：

$ python3 -m pytest test_agent_GET_endpoints.tavern.yaml --disable-warnings ========================================== test session starts =========================================== platform linux -- Python 3.9.9, pytest-5.4.3, py-1.11.0, pluggy-0.13.1 rootdir: /home/user/git/wazuh/api/test/integration, inifile: pytest.ini plugins: html-2.1.1, metadata-2.0.1, tavern-1.0.0 collected 92 items test_agent_GET_endpoints.tavern.yaml ............................................................. [ 66%] ............................... [100%] ============================== 92 passed, 98 warnings in 217.61s (0:03:37) ===============================

pytest 可直接接受的可选参数：

API integration tests optional arguments: --build-managers-only Recreates only the managers' image once the AIT test environment is built. --nobuild Prevents rebuilding the environment when running tests once the images are already created. --disable-warnings Disables warnings during test execution.

5.6 使用 run_tests.py 批量执行

除了直接调用 pytest，还可以使用 api/test/integration/run_tests.py 脚本批量收集和执行测试。其参数如下：

$ python3 run_tests.py -h usage: run_tests.py [options] API integration tests optional arguments: -h, --help show this help message and exit -l TEST_LIST, --list TEST_LIST Specify a list of tests separated by a comma. -e, --exclude Run every test excluding the already saved in the RESULTS_FOLDER. -r, --results Get result summary from the already run tests. -k KEYWORD, --keyword KEYWORD Specify the keyword to filter tests out. Default None. -R {both,yes,no}, --rbac {both,yes,no} Specify what to do with RBAC tests. Run everything, only RBAC ones or no RBAC. Default "both". -i ITERATIONS, --iterations ITERATIONS Specify how many times will every test be run. Default 1.

脚本的行为细节（结合 api/test/integration/run_tests.py 源码）：

• 内部以pytest -vv为基底命令，-l/--list通过逗号分隔的子串匹配文件名来筛选用例；-k/--keyword在文件名中做子串过滤；-R/--rbac决定收集普通、RBAC 或全部用例；-i/--iterations控制每个测试重复执行的次数；
• 每个测试的完整输出不会显示在终端，而是保存为_test_results目录下的结果文件，脚本通过正则解析其中的汇总行（= ... in ... =）打印简要结果；
• -e/--exclude模式会跳过_test_results中已有结果文件的测试，适合增量回归。

5.7 测试结果与日志

脚本运行产生的全部产物位于 api/test/integration/_test_results：

• 完整报告：_test_results下的结果文件；
• 容器日志：_test_results/logs，包括各节点与 agent 的ossec.log、api.log、cluster.log以及docker.log（docker compose 构建与启动输出）；
• HTML 报告：_test_results/html_reports，每个测试一份独立 HTML（--self-contained-html生成，便于归档分享）。

当测试失败时，conftest.py的save_logs()会自动把集群各节点与全部 agent 的日志复制到_test_results/logs（文件命名形如test_{test_name}-{node}-{log}），并输出环境最终状态（docker ps表格），便于定位环境与代码问题。

六、结语

Wazuh 的测试体系覆盖了从 C 核心到 Python 层再到完整环境的全部深度：make TARGET=... TEST=1+ CMake/CMocka/CTest 支撑了 server、agent、winagent、macOS agent 四个目标的单元测试与覆盖率统计；pytest支撑了 API 与 Framework 的组件测试；而 Tavern + Docker 的 API 集成测试则以 12 容器集群环境对 API 端点与 RBAC 策略进行了端到端验证。理解并掌握这些命令与脚本，是参与 Wazuh 开发、贡献补丁或排查功能回归的第一步。如需更细化的最新依赖版本与 CI 细节，可继续查阅 src/unit_tests/Readme.md 与 api/test/integration/README.md。

【免费下载链接】wazuhWazuh - The Open Source Security Platform. Unified XDR and SIEM protection for endpoints and cloud workloads.项目地址: https://gitcode.com/GitHub_Trending/wa/wazuh