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

Wazuh 测试执行指南:单元测试与集成测试的编译、运行与验证全流程 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、多平台 AgentLinux、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 核心组件server/agent/winagent/macOS agentCMocka CTestctest/make coverage/ 直接运行测试二进制单元测试Python API 与 Frameworkpytestpython -m pytest api/api、python -m pytest framework集成测试核心组件守护进程间交互pytest QA 集成框架python -m pytest --tier TIER TEST FOLDER/集成测试API完整 Wazuh 环境Tavern pytest Dockerpytest test_name或run_tests.py核心思路是C 组件单元测试需要先用TEST1编译 Wazuh使内部符号与测试钩子暴露给测试包装器API/Framework 测试直接使用 Python 环境与真实 API 交互而 API 集成测试则通过 Docker 拉起一个完整的 Wazuh 集群环境用 Tavern 以 YAML 声明式用例逐端点验证。二、核心组件单元测试2.1 前置要求运行 C 单元测试需要以下工具链编译工具GCC 与/或 MinGWCMake 3.10 或更高版本Wine仅在执行 Windows agent 测试时需要CMockaC 单元测试框架从源码看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 lcovmacOS 依赖安装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 TARGETserver|agent|winagent TEST1注意两点仓库 src/Makefile 中将server与manager视为等价目标ifeq (${TARGET},server) override TARGET : manager因此make TARGETserver与make TARGETmanager效果相同Makefile 的帮助信息也明确列出了三个受支持目标manager、agent、winagent。TEST1构建会在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 TEST1编译再进入unit_tests构建测试。2.3 Linux 目标server / agent单元测试进入src/unit_tests目录文档中的wazuh/src/unit_tests即仓库根目录下的src/unit_tests执行mkdir build cd build cmake -DTARGETserver|agent .. makeCMake 配置阶段指定的 TARGET 必须与编译 Wazuh 时使用的目标一致且 Wazuh 需已预先编译完成。CMake 会根据 TARGET 引入不同的构建清单并复制对应的测试配置文件src/unit_tests/CMakeLists.txt 中manager目标会include(./server.cmake)并复制 4 个漏洞检测配置文件agent目标会include(./agent.cmake)并复制 3 个防篡改anti-tampering配置文件同时只有manager目标不构建syscheckd子目录。测试运行有三种方式方式一批量运行全部测试ctestCTest 会运行所有可用测试并把结果输出到控制台。如需更多细节可查看运行后生成的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、genhtmlUbuntu 的lcov包通常已包含三者CMake 会逐一find_program校验缺失即报错。方式三运行单个测试进入测试所在的子目录像运行普通 Linux 二进制一样执行。例如测试create_db.ccd 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 -DTARGETwinagent -DCMAKE_TOOLCHAIN_FILE../Toolchain-win32.cmake .. makeCMAKE_TOOLCHAIN_FILE让 CMake 正确配置交叉编译。查看 src/unit_tests/Toolchain-win32.cmake 可知其核心内容CMAKE_SYSTEM_NAME Windows声明目标系统为 Windows编译器前缀i686-w64-mingw32即使用i686-w64-mingw32-gcc/g/windres/ar/ranlibfind_program(WINE wine)并设置CMAKE_CROSSCOMPILING_EMULATOR wine使ctest能通过 Wine 执行.exe测试程序。运行测试同样有三种方式区别在于测试程序需借助 Wine批量运行ctestCTest 会通过 Wine 运行所有测试并展示结果详细输出在build/Testing/Temporary/LastTest.log。覆盖率报告make coverage测试通过后在coverage-report目录生成 HTML 报告。运行单个测试cd syscheckd wine test_create_db.exe2.4.1 为 Windows 目标交叉编译 CMockaCMocka 是编译与运行单元测试套件的必需品。对 server 和 Linux agent 测试用包管理器安装的二进制版本即可但要运行 Windows agent 测试必须用 MinGW 编译器从源码构建 CMockaUbuntu 的 mingw 包不附带 cmocka克隆 CMocka 仓库git clone https://git.cryptomilk.org/projects/cmocka.git检出stable-1.1分支Wazuh 的测试包装器按 CMocka 1.1 API 编写。修改DefineOptions.cmake将BUILD_SHARED_LIBS设为OFF构建静态库。在仓库目录内交叉编译mkdir build cd build cmake -DCMAKE_C_COMPILERi686-w64-mingw32-gcc -DCMAKE_C_LINK_EXECUTABLEi686-w64-mingw32-ld -DCMAKE_INSTALL_PREFIX/usr/i686-w64-mingw32/ -DCMAKE_SYSTEM_NAMEWindows -DCMAKE_BUILD_TYPERelease .. 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_TYPERelease .. make sudo make install注意重建 CMocka 前务必清空build目录中的全部旧文件。2.4.2 安装 32 位 WineUbuntuWazuh 的 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 位模式运行并找到测试所需的全部 DLLexport 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 WINEARCHwin32建议将这两行加入~/.bashrc。WINEPATH使用分号分隔Windows 风格依次指向 MinGW 运行库、GCC posix 线程模型运行库提供libstdc-6.dll、libwinpthread-1.dll等、Wazuh 源码目录以及src/build/binWazuh 自身构建出的 DLL 所在位置。WINEARCHwin32强制 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 -DTARGETagent .. makeTARGETagent的 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.txt3.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_modeauto等选项以支持异步测试。四、核心组件集成测试集成测试验证的是各守护进程与模块在真实 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 pip4.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/ \ --htmlresults.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 个 agentID001~012随后用tavern_utils:test_sort_response校验sort-id、sortos.name,os.major、sort-version,id等排序行为。公共变量协议、主机、端口、凭据、延迟参数、各类 XML 配置模板定义在 api/test/integration/common.yaml并通过 api/test/integration/pytest.ini 的tavern-global-cfgcommon.yaml全局注入。5.2 Docker 测试环境API 集成测试环境用 Docker 构建由12 个容器组成3 个 Wazuh manager组成一个 Wazuh 集群1 个 master 2 个 worker4 个 Wazuh agent与 manager 同版本4 个旧版本4.14.1agent1 个 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.yaml55000为 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(scopesession, autouseTrue)定义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_payload101 条事件、max_size_event12772 词条、large_event12773 词条等 fixture用于测试事件上限类场景。由于环境固定以集群模式运行测试执行命令与环境的关系是确定的命令环境pytest TEST_NAMEWazuh 集群环境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 环境依赖版本如下pytest5.4.3 requests2.23.0 pyaml21.10.1 tavern1.0.0 pykwalify1.7.0 pytest-html2.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.logdocker 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... TEST1 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创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考