ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

libwebsockets 持续集成(CI)测试接入指南:从 Travis 配置到多模式测试矩阵

libwebsockets 持续集成(CI)测试接入指南:从 Travis 配置到多模式测试矩阵 人工智能AI Agent多模态语音AI 应用【免费下载链接】ten-frameworkOpen-source framework for conversational voice AI agents项目地址https://gitcode.com/TEN-framework/ten-framework点击查看免费下载libwebsockets 的 CI 接入并非简单的构建一下、跑个测试就能了事——它需要把依赖安装、构建选项、协议一致性测试、负载压测与安全攻击测试完整串联起来。本文基于third_party/libwebsockets/READMEs/README.ci.md的骨架结合仓库内真实存在的scripts/travis_install.sh、scripts/travis_control.sh及配套测试脚本完整讲解 libwebsockets 的 CI 测试体系为什么要为每个新功能补 CI 用例、三个接入点在源码中的具体落点以及lwsws / mbedtls / smp / libev / libuv等测试模式各自跑哪些测试。读完本文你将掌握 libwebsockets 的 CI 测试设计思路并能在自己的集成流程中复用它现成的测试脚本与构建参数约定。说明libwebsockets 以第三方依赖形式内置于本仓库TEN-framework / ten-framework的third_party/libwebsockets目录作为底层 HTTP(S)/WebSocket 传输库使用其完整的 README 系列文档与 CI 脚本一并随源码树保留因此本文所引用的脚本路径均以仓库根目录为基准。为什么要给 libwebsockets 加 CI原文档README.ci.md开篇就点明了 CI 的必要性这段论述本身就是接入 CI 的第一条原则凡是应当长期可用的功能就必须在 CI 中持续被锻炼原话是至少要在 Travis 上跑通。新增非平凡代码时尽量带上对应的 CI 测试。冷门功能最容易悄悄坏掉如果一个功能使用者很少那么重构或其它大改动随时可能把它破坏到不可用而且没有任何人注意到直到很久以后。经验表明这是常态而不是例外。作者也直言维护 CI 测试是非产出性的苦差事nonproductive PITA从来没人为此感谢过他但要想让各种功能可用的承诺继续保持下去为新代码补 CI 测试就是必须付出的代价。这条原则直接决定了本仓库third_party/libwebsockets/scripts/下那套测试脚本的存在形态它们不是为了演示而写的玩具而是被设计成可在 CI 里按模式批量驱动、可判定成败的真测试。CI 的三个接入点Integration points原文档把 CI 接入归纳为三个明确的集成点每个点对应仓库里的一个具体文件1. cmake测试活动与构建选项的映射.travis.ymlmaps the various test activities to CMake options needed.即在 CI 配置中不同测试活动如 TLS 栈选择、事件循环选择、是否启用 minimal-examples被映射成对应的 CMake 选项。从scripts/travis_control.sh的实际内容可以看到这些 CMake 选项包括LWS_OPENSSL_LIBRARIES/LWS_OPENSSL_INCLUDE_DIRS指定 OpenSSL 库路径如/usr/local/lib/libssl.so;/usr/local/lib/libcrypto.so与/usr/local/include/openssl供lwsws、lwsws2、smp、mbedtls、ssmbedtls等模式使用OPENSSL_ROOT_DIRmacOS 上定位 Homebrew 安装的 OpenSSL/usr/local/opt/openssl$CMAKE_ARGSCI 注入的通用 CMake 参数透传变量所有模式都会把它追加到cmake ...命令末尾由测试脚本额外约定的构建选项例如 attack.sh 头部注释要求用cmake .. -DCMAKE_BUILD_TYPEDEBUG -DLWS_WITH_MINIMAL_EXAMPLES1构建而 autobahn-test-server.sh 同样要求-DLWS_WITH_MINIMAL_EXAMPLES1因为测试依赖 minimal examples 生成的可执行文件如bin/lws-minimal-http-server-tls。需要说明的是本仓库快照中并未包含.travis.yml本体Travis CI 已停止服务上游也未随源码树携带该文件但原文档描述的由 CMake 选项驱动测试活动的机制通过travis_control.sh中按LWS_METHOD分支传递$CMAKE_ARGS的代码可以完整印证。2. 依赖安装scripts/travis_install.shSee./scripts/travis_install.sh该脚本scripts/travis_install.sh负责在 CI 环境中按测试模式安装依赖逻辑按平台 × 测试模式LWS_METHOD交叉展开LinuxTRAVIS_OS_NAME linux使用 apt-getLWS_METHOD安装内容lwsws/lwsws2realpath libjemalloc1 libev4 libuv-dev libdbus-1-dev valgrind mosquitto并安装 Python 依赖six1.9、Twisted16.0.0、pyopenssl0.14、autobahntestsuite再解压openssl-1.1.0-trusty.tar.bz2到/并执行ldconfig、update-ca-certificatesmbedtls/ssmbedtlsrealpath libjemalloc1 libev4 libuv-dev valgrind 同样的 OpenSSL 预编译包smprealpath libjemalloc1 libev4 OpenSSL 预编译包libevlibev-devlibuvlibuv-devlwsws/lwsws2分支也会顺带安装macOSTRAVIS_OS_NAME osx使用 brewlwsws/lwsws2brew install dbuslibevbrew install libevlibuv及lwsws/lwsws2brew install libuv。特殊开关当COVERITY_SCAN_BRANCH 1Coverity Scan 分支时直接退出不安装任何依赖——因为该分支只做静态扫描不需要运行测试环境。从依赖清单可以看出各测试模式的能力边界libev/libuv是事件循环后端分别对应LWS_EVLIB_EVENT/LWS_EVLIB_UV测试面mosquitto是 MQTT broker供 dbus/MQTT 相关测试用autobahntestsuite则是 WebSocket 协议一致性测试工具。3. 执行预编排的测试动作scripts/travis_control.shSee./scripts/travis_control.sh该脚本scripts/travis_control.sh是 CI 的核心调度器负责构建 → 安装 → 按模式跑测试。它的分支结构与travis_install.sh一一对应整理如下COVERITY_SCAN_BRANCH 1跳过全部构建与测试。macOSmkdir build cd build执行cmake -DOPENSSL_ROOT_DIR/usr/local/opt/openssl $CMAKE_ARGS .. cmake --build .但mbedtls/ssmbedtls模式跳过因为 OpenSSL 路径参数对 mbedTLS 无意义。Linux 各模式lwswscmake带LWS_OPENSSL_LIBRARIES/LWS_OPENSSL_INCLUDE_DIRS→ 构建 →sudo make install→ 依次执行minimal-examples/selftests.sh、scripts/h2spec.sh、scripts/attack.sh、scripts/h2load.sh、scripts/autobahn-test-server.sh、scripts/autobahn-test-client.sh即全套测试lwsws2构建 安装后只跑scripts/autobahn-test-server.sh侧重 WebSocket 一致性smp构建后只跑scripts/h2load-smp.sh多核并发压测mbedtls/ssmbedtlscmake → 构建 → 安装 → 跑selftests.sh、h2spec.sh、h2load.sh、attack.sh与 lwsws 相比少了 Autobahn 与 h2load-smp其它默认路径只做cmake $CMAKE_ARGS .. cmake --build .即普通编译验证。这种按模式裁剪测试集合的设计正是原文档所说把各种测试活动映射到 CMake 选项的运行时体现。测试矩阵里的各个测试脚本scripts/目录third_party/libwebsockets/scripts里除了travis_install.sh/travis_control.sh两个调度脚本还有一批被调用的专项测试脚本它们的职责与判定方式如下。HTTP/2 协议一致性h2spec.shh2spec.sh 从 h2spec v2.1.0 的 linux_amd64 发布包解压出h2spec工具后台启动minimal-http-server-tls示例服务器监听 127.0.0.1:7681然后执行../../../build/h2spec -h 127.0.0.1 -p 7681 -t -k -S /tmp/hlog其中-t表示 TLS 模式、-k忽略证书校验、-S跳过对同一连接上多个 stream 的要求。判定逻辑很直接若输出中出现Failures:则打印失败段并exit 1否则exit 0。这是把HTTP/2 协议规范符合性固化成 CI 门槛的典型做法。HTTP/1.1 与 HTTP/2 负载压测h2load.sh 与 h2load-smp.shh2load.sh 与 h2load-smp.sh 结构几乎相同差别仅在于前者打的是单进程的lws-minimal-http-server-tls后者打的是 SMP 模式的lws-minimal-http-server-smp -s。压测命令为HTTP/1.1h2load -n 10000 -c 1 --h1、-n 10000 -c 10 --h1、-n 100000 -c 100 --h1HTTP/2去掉--h1同样按 1 / 10 / 100 并发、1 万到 10 万请求递增。任何一档压测命令返回非零即终止并退出对应错误码。这套组合同时覆盖了协议版本与并发规模两个维度用于防止回归把吞吐或并发能力打回原形。安全与健壮性攻击测试attack.shattack.sh 是最狠的一个脚本其注释明确要求以-DCMAKE_BUILD_TYPEDEBUG -DLWS_WITH_MINIMAL_EXAMPLES1构建。它启动libwebsockets-test-server -d15调试级别日志用lws-minimal-raw-netcat作为原始 TCP 客户端逐项攻击 HTTP 解析层URI 参数解析/cgi-bin/settingsjs?UPDATE_SETTINGS1...等请求校验URI Arg的切分结果百分号编码与路径归一化/t%3dest?key1%3d2value1、%2f%2e%2e%2f%2e./xxtest.html等验证解码与路径重写目录穿越攻击/../../../../etc/passwd、/%2e%2e%2f../../../etc/passwd、%2f%2e%2e%2f%2e./.%2e/.%2e%2fetc/passwd等必须被归一化为 404/403 而非泄露文件畸形请求缺失 URI、重复方法、超长 header 名、超长 URI 内容、随机字节垃圾80 字节、10MB等服务器必须存活且正确拒绝HTTP/1.1 管线化用wget连续请求 8 个/test.html对响应内容做 md5 一致性校验URI 变体大矩阵脚本内置了 200 余条/.../、/../、/./、/%等组合变体逐条请求并对比预期状态码表403/404/200最后用 md5sum 比对整体结果。attack.sh 的本质是把 HTTP 解析器的攻击面系统性锤一遍确保路径归一化、编码解码与错误处理在每次 CI 中都被重新验证。WebSocket 协议一致性Autobahn TestSuiteAutobahn 是 WebSocket 社区标准的协议一致性测试套件libwebsockets 同时用它测服务器侧与客户端侧两个方向autobahn-test-server.sh生成fuzzingclient.json以lws-minimal-ws-server-echo端口 9001为被测服务器wstest -m fuzzingclient全量跑测试用例cases: [*]仅排除 2.10 / 2.11RFC6455 不要求单连接内多 PING/PONG 并发lws 出于内存效率也不支持随后解析reports/servers/index.json只要出现非OK/NON-STRICT/INFORMATIONAL的 behavior 即记为失败。autobahn-test-client.sh反过来由wstest -m fuzzingserver扮演服务器lws-minimal-ws-client-echo循环请求/runCase?caseNagentlibwebsockets逐个用例最后用/updateReports生成报告排除项除 2.10/2.11 外还排除了 12.3.1、12.3.2、12.4.*、12.5.*脚本注释指出 Autobahn 自 2017 年 8 月起对这些用例本身就有缺陷。注意它用PYTHONHASHSEED0启动 wstest保证用例执行顺序可复现。两个脚本最后都以exit $RESULT返回汇总状态因此 CI 可以直接把退出码当作通过/失败依据。如何把一个新功能接入 CI可复用的接入步骤把原文档的为什么与脚本的怎么做合起来向 libwebsockets 的 CI 体系添加新功能测试可以遵循如下流程本仓库的脚本即为现成模板先回答值不值得该功能是否承诺长期可用若是就有义务进 CI越是冷门、使用者少的功能越需要 CI 兜底否则下一次重构就会让它无声坏死。确认测试可被 CMake 选项驱动新增功能需要对应的构建开关类似LWS_WITH_MINIMAL_EXAMPLES并把它通过$CMAKE_ARGS传入使测试活动与构建选项的映射成立。补依赖安装分支在 travis_install.sh 中按LWS_METHOD与平台Linux 的 apt-get / macOS 的 brew把新功能所需依赖加上同时保留COVERITY_SCAN_BRANCH的短路出口。注册测试动作在 travis_control.sh 中决定该功能适合哪种模式lwsws全量、smp压测、mbedtls轻量 TLS 面等把对应的测试脚本挂到该模式的执行链上。用可判定成败的方式写测试参考 h2spec.sh 的失败关键字 exit 1、h2load.sh 的非零退出即失败、autobahn 脚本的行为归类统计以及 attack.sh 的md5 整体比对让测试结果能机械地被 CI 判定。在本仓库中的位置与延伸阅读本仓库将 libwebsockets 以第三方依赖形式置于third_party/libwebsockets全部 README 与测试脚本随树保留可直接查阅本文主依据README.ci.md依赖安装scripts/travis_install.sh测试调度scripts/travis_control.sh专项测试h2spec.sh、h2load.sh、h2load-smp.sh、attack.sh、autobahn-test-server.sh、autobahn-test-client.sh若想进一步了解与 CI 相关的构建与测试机制可继续阅读同目录下的 README.cmake.mdCMake 选项体系与 README.ctest.mdCTest 集成方式它们与本文的 CI 脚本互为补充共同构成 libwebsockets 的构建—测试—持续集成全链路。赞分享人工智能AI Agent多模态语音AI 应用【免费下载链接】ten-frameworkOpen-source framework for conversational voice AI agents项目地址https://gitcode.com/TEN-framework/ten-framework点击查看免费下载相关推荐weixin-game-helper完全指南从安装到精通的微信游戏辅助神器weixin game helper完全指南从安装到精通的微信游戏辅助神器 weixin game helper是一款功能强大的微信游戏辅助神器它能够为玩家示例工程Karma 接入 Travis CI 持续集成完全指南从 .travis.yml 配置到 Firefox 无头浏览器测试Karma 接入 Travis CI 持续集成完全指南从 .travis.yml 配置到 Firefox 无头浏览器测试 本文以 Karma 项目官方文档 d测试开发工具FoldingCell持续集成Travis CI配置与自动化测试FoldingCell持续集成Travis CI配置与自动化测试 在iOS开发中手动测试UI组件的折叠展开功能既耗时又容易遗漏边缘场景。本文将详细介绍如何为UI组件移动开发上一篇Langfuse 的 Turborepo 任务执行详解turbo run 在 Monorepo 构建中的用法与实战下一篇SiYuan v3.5.4 版本变更深度解读导出管线重构、.sy.zip 批量导出与任意文件读取漏洞修复创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表