2026/9/25 5:12:00

在 GitLab CI/CD 中运行 Artillery 负载测试:完整实战指南

在 GitLab CI/CD 中运行 Artillery 负载测试:完整实战指南 性能测试接口测试CLI【免费下载链接】artilleryThe complete load testing platform. Everything you need for production-grade load tests. Serverless distributed. Load test with Playwright. Load test HTTP APIs, GraphQL, WebSocket, and more. Use any Node.js module.项目地址https://gitcode.com/gh_mirrors/ar/artillery点击查看免费下载在 GitLab CI/CD 中运行 Artillery 负载测试完整实战指南导读本文以 examples/cicd/gitlab-ci-cd 目录下的官方示例为主线完整演示如何在 GitLab CI/CD 流水线中运行 Artillery 负载测试从一份针对 Socket.IO 服务器的测试脚本含ensure断言到.gitlab-ci.yml中基于 Docker 镜像的作业定义、JSON 报告生成与 artifacts 归档一应俱全。读完本文你将掌握把 Artillery 压测接入 GitLab 流水线、自动产出并保存测试报告的标准做法并能据此扩展到 HTTP API、GraphQL、WebSocket 等其他协议场景。示例概览三个文件构成一个可用的 CI 压测流水线examples/cicd/gitlab-ci-cd目录下共三个文件正好构成脚本 → 流水线 → 说明的完整闭环文件作用README.md示例说明描述示例用途与运行方式.gitlab-ci.ymlGitLab CI/CD 流水线定义负责拉取 Artillery 镜像、执行压测、归档报告tests/performance/socket-io.ymlArtillery 测试脚本对 Socket.IO 服务进行压测并带ensure断言这也是仓库 examples/cicd 下所有 CI/CD 示例GitHub Actions、Azure DevOps、CircleCI、Jenkins、AWS CodeBuild的统一组织方式方便对照学习不同 CI 平台的接入差异。Artillery 测试脚本对 Socket.IO 服务压测并自动断言示例的压测目标是一台运行中的 Socket.IO 服务器测试脚本位于 tests/performance/socket-io.yml完整内容如下config: target: http://lab.artillery.io # As an example, well only run a single virtual user in this # test script. For real-world load testing, youll want to # adjust your load phases according to your needs. phases: - duration: 1 arrivalRate: 1 ensure: maxErrorRate: 1 max: 500 scenarios: - name: emit_an_event engine: socketio flow: - emit: channel: echo data: Hello from Artillery response: channel: echoResponse data: Hello from Artilleryconfig 段目标、负载阶段与断言target被测服务地址http://lab.artillery.io这是 Artillery 官方提供的一个 Socket.IO echo 演示服务。phases负载阶段定义。示例只跑duration: 11 秒、arrivalRate: 1每秒新建 1 个虚拟用户是用于 CI 冒烟验证的最小负载。注释中也明确提示真实压测中应根据需求调整负载阶段参数如加长 duration、提高 arrivalRate、使用多个阶段做 ramp-up。若需要更复杂的负载模型可参考 packages/types/schema/config/phases.js 中定义的phases配置模式。ensure这是 artillery-plugin-ensure 插件的断言配置——压测结束后自动校验结果不满足条件即以非零退出码结束从而让 CI 作业失败maxErrorRate: 1最大错误率不超过 1%。从 packages/artillery-plugin-ensure/plugin.ts 的源码实现看该值会转化为表达式((vusers.created - vusers.completed)/vusers.created * 100) 1进行校验。max: 500max属于该插件的 legacy 阈值写法源码中LEGACY_CONDITIONS [min, max, median, p95, p99]见 plugin.ts即校验某个指标的绝对值上限这里针对的是latency指标。scenarios 段Socket.IO 事件收发场景emit_an_event使用engine: socketio对应仓库中的 Socket.IO 引擎实现 packages/artillery/lib/core/engine_socketio.tsemit向echo频道发送一条数据Hello from Artilleryresponse随后在echoResponse频道上等待并校验返回数据是否等于Hello from Artillery。从引擎源码看emit与response或acknowledge同时出现时engine_socketio.ts引擎会等待匹配的响应并对比数据内容不匹配时抛出错误isValid校验逻辑见 engine_socketio.ts。也就是说这不仅仅是一次发送即结束的压测而是带端到端数据校验的冒烟测试服务器必须正确 echo 数据测试才算通过。这一点在 CI 场景中非常关键——压测通过的前提是被测服务功能正常。GitLab CI/CD 流水线让每次推送都自动压测仓库中随附的 .gitlab-ci.yml 是整个集成的核心内容如下artillery: image: name: artilleryio/artillery:latest entrypoint: [] script: | mkdir reports /home/node/artillery/bin/artillery run --output reports/report.json tests/performance/socket-io.yml artifacts: paths: - reports作业设计逐项拆解作业名artillery这是一个单作业流水线未指定stage因此使用默认的test阶段。任何代码 push 到仓库后GitLab 会自动触发该作业。image使用官方 Docker 镜像artilleryio/artillery:latest。注意entrypoint: []这一关键写法——它清空了镜像的默认入口使 GitLab Runner 能以自己的 shell 执行script中的命令。script两行命令mkdir reports创建报告输出目录/home/node/artillery/bin/artillery run --output reports/report.json tests/performance/socket-io.yml直接调用镜像内固定的可执行文件路径/home/node/artillery/bin/artillery而非依赖 PATH用--output参数把 JSON 报告写入reports/report.json再传入测试脚本路径。报告归档artifacts 是关键一环artifacts.paths将reports目录整体归档效果包括作业结束后可在 GitLab 的Jobs → Browse页面下载reports/report.json该报告可进一步配合 GitLab 的报告展示能力或后续分析脚本使用artifacts未设置expire_in时将按 GitLab 实例默认保留期保存生产环境建议显式设置保留时间。--output生成的 JSON 报告是 Artillery 的原始指标输出。仓库根目录 package.json 通过report命令artillery report可将该 JSON 渲染为 HTML 报告在本地拿到report.json后执行npx artillery report reports/report.json即可生成可视化 HTML 报表便于团队审阅。关于运行时的说明示例没有指定runner标签或only/except规则因此作业会在任意可用的共享/组 Runner 上运行并在每次 push 时触发。若想限制触发条件例如仅 main 分支、或按 cron 定时执行可在作业上添加rules或only字段——这是把每次推送都压测扩展为定时压测的常见做法。可参考同仓库其他 CI 示例的调度写法如 examples/cicd/github-actions/README.md 提到的每日定时执行思路。本地快速验证先跑通脚本再上流水线在把测试交给 GitLab Runner 之前建议先在本地验证脚本本身。仓库 examples/cicd/gitlab-ci-cd 的 README 提到可以在 Artillery 的在线 REPL 中直接运行该示例脚本查看效果本地则可用以下命令npx artillery run tests/performance/socket-io.yml如果希望像流水线里那样同时产出 JSON 报告mkdir reports npx artillery run --output reports/report.json tests/performance/socket-io.yml本地验证通过ensure断言全部通过、退出码为 0后再提交到仓库触发 GitLab 流水线可以最大程度避免 CI 中的无效失败。扩展到 HTTP / GraphQL / WebSocket换脚本即可这套 GitLab 接入方式与具体协议解耦——.gitlab-ci.yml只关心用 Artillery 跑一个脚本并归档报告。因此把tests/performance/socket-io.yml换成任意 Artillery 测试脚本即可HTTP API把场景中的engine: socketio改为默认 HTTP 引擎用requests定义请求序列GraphQL在 HTTP 场景中以 POST 方式发送 GraphQL 查询WebSocket使用engine: ws编写收发消息的场景Playwright 浏览器压测使用engine: playwright在 CI 中做浏览器级负载测试。无论哪种协议config.phases、ensure断言、--output报告与artifacts归档的链路完全一致这正是把 Artillery 集成进 GitLab CI/CD 的核心价值一套流水线模板承载所有压测场景。小结要素对应文件 / 命令关键点测试脚本tests/performance/socket-io.ymlphases定义负载ensure定义通过条件流水线作业.gitlab-ci.yml官方镜像 清空 entrypoint 直接调用 bin 路径报告产出--output reports/report.jsonJSON 原始报告可渲染为 HTML报告归档artifacts.paths: [reports]GitLab 网页可下载、可设置保留期本地复现npx artillery run tests/performance/socket-io.yml先本地验证再上流水线这一示例同样是仓库 examples/cicd 中 CI/CD 集成系列GitHub Actions、Azure DevOps、CircleCI、Jenkins、AWS CodeBuild的组成部分你可以对照阅读快速掌握 Artillery 在不同 CI 平台上的接入模式。赞分享性能测试接口测试CLI【免费下载链接】artilleryThe complete load testing platform. Everything you need for production-grade load tests. Serverless distributed. Load test with Playwright. Load test HTTP APIs, GraphQL, WebSocket, and more. Use any Node.js module.项目地址https://gitcode.com/gh_mirrors/ar/artillery点击查看免费下载相关推荐XUnity.AutoTranslator架构创新与性能突破的Unity游戏实时翻译解决方案XUnity.AutoTranslator架构创新与性能突破的Unity游戏实时翻译解决方案 面对海外优质Unity游戏的语言壁垒传统翻译方案往往陷入兼容性性能测试接口测试CLI在 GitHub Actions 中运行 Redwood 测试从 CI 到数据库 CD 的完整实战指南在 GitHub Actions 中运行 Redwood 测试从 CI 到数据库 CD 的完整实战指南 良好的测试策略是任何项目的基石。Redwood 提供了后端前端Web框架开发工具在 GitLab CI/CD 中构建并部署到 VercelBring Your Own CI/CD 完整实战指南在 GitLab CI/CD 中构建并部署到 VercelBring Your Own CI/CD 完整实战指南 导读 本文基于开源仓库 GitHub_Tre示例工程前端后端上一篇开发者手册OpenHermes-2.5-neural-chat-7b-v3-1-7B API调用与自定义prompt技巧下一篇cait_xs24_384.fb_dist_in1k部署指南生产环境中的最佳实践创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考