ARTICLE DETAIL

资讯详情

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

在 Artillery 中复用 TypeScript 编写的 Playwright 测试代码

在 Artillery 中复用 TypeScript 编写的 Playwright 测试代码 性能测试接口测试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点击查看免费下载本文以 Artillery 仓库中的examples/browser-playwright-reuse-typescript示例为主线讲解如何把一套纯 PlaywrightTypeScript代码库复用为 Artillery 浏览器负载测试将页面操作逻辑抽象为共享 helper再通过 processor 文件与testFunction配置接入 Artillery 的 playwright 引擎。读完本文你将掌握一套 UI 操作代码同时驱动功能测试与性能测试的落地模式以及相关版本兼容注意事项。示例概览一份代码两种运行方式本示例的目录结构如下仓库相对路径examples/browser-playwright-reuse-typescript/examples/browser-playwright-reuse-typescript/ ├── e2e/ │ ├── helpers/ │ │ └── index.ts # 抽象出的共享操作逻辑 │ ├── tests/ │ │ └── get-issues.spec.ts # 纯 Playwright 测试 │ └── playwright.config.ts # Playwright 配置baseURL 等 ├── performance/ │ ├── processor.ts # Artillery processor导入共享 helper │ └── search-for-ts-doc.yml # Artillery 测试脚本playwright 引擎 ├── package.json └── README.md整个示例的核心思想把浏览器操作流程抽成独立的 helper 函数然后分别被 Playwright 测试e2e/和 Artillery 测试performance/调用。Playwright 负责功能是否正确Artillery 负责在负载下表现如何二者共享同一份页面操作代码避免两套逻辑重复维护、出现漂移。第一步抽象共享 helpere2e/helpers/index.tsPlaywright 测试中的具体操作被抽象为一个接收page与step两个参数的函数// examples/browser-playwright-reuse-typescript/e2e/helpers/index.ts import { type Page, expect } from playwright/test; export const goToDocsAndSearch async (page: Page, step) { await step(go_to_artillery_io, async () { await page.goto(/); }); await step(go_to_docs, async () { await page.getByRole(link, { name: Docs }).first().click(); await expect(page).toHaveURL(/docs); await expect(page.getByText(Get started)).toBeVisible(); }); await step(search_for_ts_doc_and_goto, async () { await page .getByRole(searchbox, { name: Search documentation… }) .click(); await page.keyboard.type(typescript, { delay: 100 }); await page .getByRole(link, { name: processor - load custom code }) .click(); await expect(page.getByText(processor - load custom code)).toBeVisible(); }); };两个关键设计值得注意step参数是抽象的步骤包装器在纯 Playwright 运行中传入的是test.step在 Artillery 运行中传入的是引擎提供的step见下文源码分析。这让同一份代码在两种运行时下都能把操作拆分为有名字的步骤。使用 Playwright 标准 APIgetByRole、expect等helper 本身不依赖任何 Artillery 特有 API因此可以原样被playwright/test调用也可以被 Artillery 的 playwright 引擎调用。纯 Playwright 侧的使用e2e/tests/get-issues.spec.ts// examples/browser-playwright-reuse-typescript/e2e/tests/get-issues.spec.ts import { goToDocsAndSearch } from ../helpers; import { test } from playwright/test; test(search and go to doc page, async ({ page }) { await goToDocsAndSearch(page, test.step); });这里传入test.stepstep(go_to_artillery_io, ...)就会成为 Playwright HTML 报告中可折叠的步骤节点失败时能精确定位到是访问首页、打开 Docs 还是搜索文档哪一步出错。第二步把同一 helper 接入 Artilleryperformance/processor 文件performance/processor.ts// examples/browser-playwright-reuse-typescript/performance/processor.ts import { goToDocsAndSearch } from ../e2e/helpers; export async function playwrightTest(page, vuContext, events, test) { const { step } test; await goToDocsAndSearch(page, step); }playwrightTest是 Artillery playwright 引擎要求的测试函数签名接收page引擎创建好的页面对象、vuContextVU 上下文、events指标事件发射器与test内含step方法。函数内部把test.step解构出来再调用共享的goToDocsAndSearch(page, step)与纯 Playwright 测试的调用方式完全一致。测试脚本performance/search-for-ts-doc.yml# examples/browser-playwright-reuse-typescript/performance/search-for-ts-doc.yml config: target: https://www.artillery.io/ phases: - duration: 1 arrivalRate: 1 name: Phase 1 processor: ./processor.ts engines: playwright: {} scenarios: - engine: playwright testFunction: playwrightTest要点拆解target配置为目标站点根地址。引擎在创建浏览器上下文时会用它作为baseURL见 packages/artillery-engine-playwright/index.ts 中contextOptions { baseURL: self.target, ... }因此 helper 里的相对路径跳转page.goto(/)、断言toHaveURL(/docs)都能正确解析。这与e2e/playwright.config.ts中的baseURL: https://www.artillery.io/一一对应——README 特别强调target 必须匹配 Playwright 配置中的 baseURL。phases负载阶段定义。示例中只跑了 1 秒、每秒 1 个新 VU 的冒烟负载实际压测时可替换为 ramp 等更复杂的阶段配置。processor指向processor.ts。Artillery 支持 TypeScript processor 文件引擎会通过script.config.processor拿到导出的函数对象引擎源码中this.processor Object.assign({}, script.config.processor)即为加载 processor 的入口。engines.playwright空对象即可启用 playwright 引擎可继续添加launchOptions、contextOptions等进阶配置。testFunction指定 scenario 要执行的 processor 导出函数名。引擎执行时通过self.processor[spec.testFunction] || self.processor[spec.flowFunction] || spec.testFunction解析实际函数packages/artillery-engine-playwright/index.ts找不到时会报 Playwright test function not found 错误。第三步运行两种测试首先安装依赖npm install运行纯 Playwright 测试cd e2e npx playwright run运行同一个流程的 Artillery 负载测试cd performance npx artillery run search-for-ts-doc.ymlpackage.json中声明的playwright/test版本为1.45.3见 examples/browser-playwright-reuse-typescript/package.json这也为下面的版本兼容话题埋下伏笔。引擎源码视角step 与指标是如何产生的Artillery 的 playwright 引擎packages/artillery-engine-playwright/index.ts在加载 processor 后会构造一个step函数并注入测试函数const step async (stepName, userActions) { const startedTime Date.now(); await userActions(); const difference Date.now() - startedTime; events.emit( histogram, self.processor.$rewriteMetricName( browser.step.${stepName}, histogram ), difference ); };由此可以确认两条实现事实步骤即指标helper 中的每一个step(..., ...)都会在 Artillery 报告中产生一条browser.step.stepName的直方图指标记录该步骤耗时。因此你可以在负载报告中看到go_to_artillery_io、go_to_docs、search_for_ts_doc_and_goto各自的耗时分布定位瓶颈步骤。引擎自动采集页面级指标除步骤耗时外引擎还通过page.on(response)统计browser.page.codes.status、通过page.on(requestfinished)统计browser.http_requests并在注入 Web Vitals 脚本后上报browser.page.LCP/FCP/CLS/TTFB/INP等指标。这些都不需要你在 helper 中写任何埋点代码。另外引擎默认以 headless 模式启动 ChromiumlaunchOptions默认包含headless: true并默认让同一 worker 内的 VU 共享一个浏览器实例除非设置useSeparateBrowserPerVU: true这些默认行为决定了负载测试的资源消耗模型在评估并发能力时值得留意。进阶用 Page Object Model 组织更大规模的复用示例本身没有使用 Page Object Model但 README 明确给出了扩展方向可以建立集中的 POM把大部分 UI 操作甚至完整用户流程封装成方法然后在 Playwright 测试与 Artillery 测试中按需调用。// 示意POM 化的 helper 设计 export class DocsPage { async open(page: Page, step) { await step(go_to_artillery_io, async () { await page.goto(/); }); } async search(page: Page, keyword: string, step) { await step(search_for_ts_doc, async () { // 搜索框交互…… }); } }这样当页面选择器或交互细节变化时只需修改 POM 一处功能测试与性能测试同时受益。适合把登录、下单、搜索等关键用户旅程沉淀为可复用的流程库。Playwright 版本兼容性重要注意事项Artillery 内置的 playwright 引擎使用特定版本的 Playwright引擎从playwright包导入chromium、selectors见 packages/artillery-engine-playwright/index.ts 顶部导入。因此你现有的 Playwright 测试必须只使用与 Artillery 所用 Playwright 版本兼容的特性package.json中安装的playwright/test版本理想情况下应与 Artillery 当前使用的版本一致本示例锁定1.45.3若使用了较新版本才支持的 API如新的定位器、断言或浏览器特性在 Artillery 运行时可能不可用建议先在本地以 Artillery 方式冒烟运行一遍示例中的 1 秒单 VU 阶段正是这种低成本验证手段。小结browser-playwright-reuse-typescript示例展示的复用模式可以概括为三步抽象把页面操作流程抽成接收page与step的共享 helper或升级为 POM接入在 Artillery processor 中导出签名为(page, vuContext, events, test)的函数并在 YAML 中用testFunction指向它对齐环境保证config.target与 Playwright 的baseURL一致、playwright/test版本与 Artillery 内置 Playwright 版本兼容。这一模式让团队能够以最小代价把已有的 TypeScript Playwright 代码库延伸进负载测试领域同时保留 Playwright 完整的断言与定位器表达能力——同一套代码既验证功能正确性也验证负载下的表现。相关参考实现可继续查阅 packages/artillery-engine-playwright/index.ts引擎实现与 examples/browser-load-testing-playwright配套的浏览器负载测试示例。赞分享性能测试接口测试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点击查看免费下载相关推荐Hindsight 部署完全指南Docker、Kubernetes、裸机 pip 与 Python 嵌入四种安装路径Hindsight 部署完全指南Docker、Kubernetes、裸机 pip 与 Python 嵌入四种安装路径 本篇基于 Hindsight 0.8 版性能测试接口测试CLIUnity Test测试用例设计模式可复用测试代码编写方法Unity Test测试用例设计模式可复用测试代码编写方法 Unity Test作为C语言单元测试的轻量级框架提供了多种测试用例设计模式帮助开发者编写可复测试嵌入式EUI test-helpers用 EuiToolTipObject 为 EuiToolTip 编写 Playwright 测试EUI test helpers用 EuiToolTipObject 为 EuiToolTip 编写 Playwright 测试 EuiToolTipObje前端UI组件设计系统上一篇Jellium Desktop媒体格式入门轻松掌握播放格式基础下一篇ViewAnimator的单元测试模拟使用XCTestExpectation测试异步动画创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表