把验收需求说给AI就能跑:Playwright自动化测试从零到一上手指南 把验收需求说给AI就能跑Playwright自动化测试从零到一上手指南【免费下载链接】playwright-skillGeneral-purpose Playwright automation for coding agents项目地址: https://gitcode.com/gh_mirrors/pl/playwright-skill周五晚上八点你正准备下班产品丢来一句新版的注册流程能帮忙测一下吗两个浏览器、三种屏幕尺寸今晚给结论。你翻开本地项目想起上次手写 Playwright 自动化测试脚本的经历找选择器、猜等待时间、处理弹窗、对着无头浏览器的日志逐行猜错在哪——一瞬间下班的心情全没了。这篇文章要介绍的开源项目 playwright-skill正是为解决这类场景而生的。它是一套面向编程助手的通用浏览器自动化技能包把 Playwright 自动化测试从手写脚本变成口头描述需求你只要说清楚想测什么它负责写代码、开浏览器、点按钮、截图最后把结论摆到你面前。下面我们从一个最小可用的例子出发再从原理、配置到踩坑把整套流程从零到一讲透。十分钟装好环境并跑通第一个自动验收先别急着理解概念直接动手。在终端里执行下面四条命令把技能装进 Claude 这类编程助手的技能目录git clone https://gitcode.com/gh_mirrors/pl/playwright-skill /tmp/playwright-skill mkdir -p ~/.claude/skills cp -r /tmp/playwright-skill/skills/playwright-skill ~/.claude/skills/ cd ~/.claude/skills/playwright-skill npm run setup最后一条npm run setup会安装 Playwright 依赖并下载 Chromium 内核几分钟内完成。如果之后还想测 Firefox、WebKit再补一句npm run install-all-browsers即可。装完之后把本地开发服务跑起来然后对 AI 说一句帮我把首页的标题、导航菜单和登录按钮都检查一遍看看有没有报错。它就会自己扫一遍本机端口找到正在运行的服务写出一份类似下面的脚本并执行const { chromium } require(playwright); const targetUrl process.env.TARGET_URL || http://localhost:3000; (async () { const browser await chromium.launch({ headless: false }); try { const page await browser.newPage(); await page.goto(targetUrl); console.log(页面标题, await page.title()); await page.getByRole(navigation).waitFor(); await page.screenshot({ path: /tmp/homepage.png, fullPage: true }); } finally { await browser.close(); } })();这种临时脚本默认存在系统的临时目录里命名类似playwright-test-*.js不会混进你的项目代码。跑完直接在对话里看结论和截图路径即可。如果是临时的一句小任务也可以用内置的一行执行方式省去建文件node run.js -e const p await browser.newPage(); await p.goto(http://localhost:3000); console.log(await p.title());拆开看内部原理AI 到底替你完成了哪几步跑通之后值得花两分钟弄明白它为什么能指哪打哪。整个技能由三块拼成各司其职指令说明书SKILL.md里写清了工作流程——先检测本地服务、脚本写到临时目录、默认开可视浏览器、用可访问性定位器找元素。AI 每次动手前先读这份规则行为才稳定可预期。统一执行器run.js是脚本的发射台负责解析模块路径、把运行目录保持在你的项目里这样脚本里的相对路径不会跑偏还支持上面提到的-e内联执行。辅助函数库lib/helpers.js提供几个高频小工具比如端口扫描、Cookie 弹窗处理、整页截图让 AI 不必每次从零造轮子。这里有个很实用的细节所谓自动检测本地开发服务器其实是detectDevServers这一函数对 3000、5173、8080 等一串常见端口逐个发探测请求把有响应的端口整理成 URL 列表。只发现一个就默默用上发现多个会反问你要哪个一个都没有就提示你给地址或先启动服务。三种情况都安排得明明白白。另一个设计值得点名表扬它采用渐进式披露。SKILL.md保持精简AI 只读当前任务需要的最小信息遇到网络拦截、视频录制、设备模拟这类进阶需求才会按需翻出完整的API_REFERENCE.md。文档不小但平时不会拖慢响应。几个环境变量开关让自动化执行更趁手日常使用中你大概率会用到下面这组环境变量它们相当于给执行器拧旋钮换浏览器PW_BROWSERfirefox或PW_BROWSERwebkit决定用哪个内核装了 Chrome、Edge 的话还能用PW_CHANNELchrome直接驱动现成浏览器或PW_EXECUTABLE_PATH指向自定义的可执行文件。显隐切换默认就是带界面的可视模式方便你盯着每一步操作想跑静默批处理时再设PW_HEADLESStrue。调试阶段可以给SLOW_MO设个毫秒数让 AI 的每个动作都放慢肉眼能跟上。请求头注入后端想识别自动化流量或者接口需要带令牌用PW_HEADER_NAME加PW_HEADER_VALUE塞单个请求头要批量就传 JSONPW_EXTRA_HEADERS{X-Test-Id:001,X-Env:staging} node run.js /tmp/playwright-test-page.js产物去向PW_SCRIPT_DIR会把用到的脚本复制到指定目录做留存重名时自动追加时间戳PW_ARTIFACT_DIR则统一接管截图输出位置默认落在系统临时目录。三个高频场景的现成脚本登录、响应式、接口异常装好、调顺之后下面是三个我实测最常用的场景模板可以直接拿给 AI 参考也可以自己存起来反复用。场景一验证登录流程。关键点是不要臆造真实账号密码用你提供的测试凭据并且要同时验证跳转成功和登录后的元素真的出现两步都过了才算数await page.goto(${targetUrl}/login); await page.getByLabel(Email).fill(process.env.TEST_EMAIL); await page.getByLabel(Password).fill(process.env.TEST_PASSWORD); await page.getByRole(button, { name: /sign in|log in/i }).click(); await page.waitForURL(**/dashboard); await page.getByRole(heading, { name: /dashboard/i }).waitFor();场景二响应式截图对比。想确认同一页面在不同设备下的观感用循环切视口、逐张全页截图最省事const viewports [ { name: desktop, width: 1440, height: 900 }, { name: mobile, width: 390, height: 844 }, ]; for (const vp of viewports) { await page.setViewportSize(vp); await page.goto(targetUrl); await page.screenshot({ path: /tmp/${vp.name}.png, fullPage: true }); }场景三模拟接口出错。想看看页面在服务端崩溃时有没有兜底文案拦截路由直接返回 500 即可await page.route(**/api/**, route route.fulfill({ status: 500, body: Server Error }) );另外遇到满屏飘的 Cookie 同意弹窗直接调helpers.handleCookieBanner(page)它会按一批常见文案逐个尝试点掉比手写一堆 if 判断干净得多。新手最容易踩的四个坑与对应解法跑了几个任务之后我总结了四个高频翻车点提前避开能省很多调试时间。坑一用固定延时等页面。await page.waitForTimeout(5000)写起来顺手但网络一波动就现原形——快了白等慢了报超时。正确姿势是用面向结果的等待等某个可见元素出现、等 URL 跳转到位、等某个角色元素就绪比如上面的waitForURL和getByRole(...).waitFor()。Playwright 的多数操作本身就带自动等待你只需要在关键节点补一个明确的完成信号。坑二死磕 class 和 id 选择器。.btn-primary、#submit这类写法一旦前端改版就全线崩。优先用用户视角的定位方式按优先级是getByRole带无障碍名称、getByLabel表单控件、getByText可见文本应用提供了测试契约时再用getByTestId。坑三开着无头模式硬调。无头跑起来日志一堆、画面全无出错了只能靠猜。技能默认就是可视浏览器除非你主动要静默如果想看得更细把SLOW_MO调大配合page.on(console, ...)把浏览器日志打到终端定位问题会轻松很多。坑四不看结果就宣布通过。脚本退出码为 0 不代表页面正确。正确习惯是点完登录按钮后确认 URL 变了、目标标题出来了再下结论。技能的工作流里也明确要求没有确认页面呈现就不得声称成功这条同样适用于你自己手写的脚本。常见疑问快问快答问测试脚本到底存哪里会弄脏我的仓库吗答默认全部写在系统临时目录文件名形如playwright-test-*.js不占项目空间想保留就设PW_SCRIPT_DIR它会自动复制过去并在重名时加时间戳。问本地没有开发服务器想测外部网站怎么办答直接把地址丢给 AI 就行比如帮我检查 https://example.com 的响应式表现它会以你给的 URL 为目标执行。问要测必须登录的页面怎么办答两条路。一是用测试账号完整走一遍登录流程注意凭据要你提供别让 AI 编二是先手动开一个开了远程调试端口的 Chrome用chromium.connectOverCDP(http://127.0.0.1:9222)直接复用当前会话里的登录态和扩展。后者等于借用你浏览器里的现状涉及敏感信息时务必确认是你主动要求的。问能同时跑多个测试吗答能。写多个脚本各自执行即可并行推进Playwright 本身也支持多上下文并发适合批量检查多个页面。问报错说找不到 playwright 模块答八成是没走执行器。务必经由node run.js 脚本路径启动由它负责模块解析再不行就去技能目录里补一次npm run setup。什么时候不该用它选对工具边界最后说点反常识的playwright-skill 不是万金油搞清楚边界反而能让你用得更好。它最擅长的场景是需要写一段真正的 Playwright 程序——要循环、要断言、要开多个上下文、要拦网络、要录视频、要一份能保存下来反复跑的脚本。这种自动化本身就是成果的任务它比任何现成脚本都灵活。反过来如果你只是想让 AI 临时开个浏览器、翻几页网页、看个快照属于轻量交互式浏览那用更轻量的方案反而合适没必要搬出整套编程式执行。选工具的道理很简单任务越接近写代码越该交给这个技能任务越接近随便逛逛越该用省事的现成工具。回到开头那个周五夜。现在你的答案会变成启动本地服务对 AI 说一句测一下注册流程桌面和手机两个尺寸都要然后看着浏览器窗口自动操作几轮对话之后带着截图和结论下班。这就是把浏览器交给 AI 的真正意义——你只需要负责描述想要什么剩下的重复劳动交给 playwright-skill 替你跑完。【免费下载链接】playwright-skillGeneral-purpose Playwright automation for coding agents项目地址: https://gitcode.com/gh_mirrors/pl/playwright-skill创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考