★ FEATURED ARTICLE 没接触过Playwright的同学可能觉得它不过是又一个Selenium换皮工具。但真把测试用例写起来你会发现它跟传统自动化测试的思考方式完全不一样——你不再天天跟time.sleep、显式等待、StaleElement异常搏斗而是把“元素可见、可点、可输入”这些事直接交给框架去判断。这篇文档是Playwright中文系列的第一篇主题就是“编写测试”我会从环境准备一直讲到报告调试尽量把每条命令背后的设计逻辑也讲清楚让大家不只会抄代码还能理解为什么这么写。1. 为什么是Playwright三个让测试不“脆”的设计核心说句实话早期我用Selenium写UI自动化最痛苦的不是写用例而是维护用例。今天元素加了个span包一层明天按钮从click变成mouseover弹出后天页面加载快了0.5秒导致等待超时——整个测试套件就像用沙子堆的城堡一碰就塌。Playwright把这些问题从根上处理掉了它的设计哲学不是“模拟用户操作浏览器”而是“让浏览器按照用户的真实行为来完成操作”。1.1 Web-First断言测试意图更直接传统断言是assert element.text xxx你得先拿到元素再取值再比较中间任何一步失败都会抛出一堆底层的WebDriver异常。Playwright的断言是await expect(page.locator(...)).toHaveText(xxx)它会自动重试直到元素出现、文本匹配或超时。这个区别理解起来就像“你去餐厅点菜服务员会一直盯着后厨直到菜做好端上来”而不是“你去窗口问一句好了没没好就报错”。所有expect断言都内置了重试机制默认超时5秒你基本不用手写等待。1.2 自动等待与操作链告别sleeppage.click()、page.fill()、page.check()这些动作在执行之前会自动检查元素是否附加到DOM、是否可见、是否稳定不抖动、是否能接收事件。有一个条件不满足它就继续等等到超时为止。这背后的机制叫Actionability检查是它和Selenium最大的体验差异。你可以理解为Playwright把“等待”这件事从“测试代码”里剥离出来下沉到了“浏览器操作层”所以你的代码里基本看不到Thread.sleep(1000)这种垃圾代码。1.3 浏览器上下文隔离每个测试都是全新用户每次测试运行Playwright都会启动一个全新的浏览器上下文Browser Context相当于打开了一个隐身窗口。Cookie、LocalStorage、缓存全部是空的测试之间零污染。这个设计特别适合需要登录态的测试——你想让用例B复用用例A的登录状态那你就得显式去保存和复用存储状态这就逼着你把用例设计成“每个用例独立可跑”从根本上避免了测试套件里最常见的“顺序依赖”问题。那到底什么项目适合用Playwright我认为凡是基于Chromium、Firefox、WebKit的Web应用无论前端是React、Vue还是老式jQuery都可以用它做端到端测试。如果你是做爬虫、页面数据抓取、自动化脚本的同学它也能当无头浏览器工具用但这篇文档我们聚焦在测试编写上。2. 安装与初始化第一步就避开的三个坑Playwright支持JavaScript/TypeScript、Python、Java、.NET四种语言。这篇文档按JavaScript/TypeScript的路子走因为生态最完整、跟前端工具链融合得最好。不过Python版的API几乎一致看完这篇你再切到Python也没什么学习成本。2.1 环境准备与依赖安装先确认机器上有Node.js 18以上版本我用的是Node 20 LTS。然后在你打算放测试代码的目录下执行npm init -y npm i -D playwright/test npx playwright install第三条命令会下载Chromium、Firefox、WebKit三个浏览器的二进制文件。这里我要提醒第一个坑如果你在公司网络环境里下载大概率会失败。要么给npm配置镜像要么单独设置播放器浏览器的下载镜像环境变量比如在.bashrc或PowerShell里设置# Windows PowerShell 示例 $env:PLAYWRIGHT_DOWNLOAD_HOST https://npmmirror.com/mirrors/playwright/ npx playwright install chromium我只装了Chromium因为绝大多数业务测试跑在Chrome内核上就够了Firefox和WebKit主要用来做兼容性验证。等后面CI上真的需要多浏览器覆盖时再补装不迟没必要一开始就全量下载占磁盘。2.2 初始化项目结构与配置文件执行npx playwright test之前建议先跑一下npx playwright test --init新版本可用它会生成一个基础配置文件和示例测试目录。不过我更习惯手动建目录结构如下project-root/ ├── playwright.config.js ├── tests/ │ ├── login.spec.js │ └── cart.spec.js └── test-data/ └── users.jsonplaywright.config.js是核心配置我最小化配置长这样// playwright.config.js const { defineConfig } require(playwright/test); module.exports defineConfig({ testDir: ./tests, timeout: 30000, retries: 1, use: { baseURL: https://example.com, headless: true, viewport: { width: 1280, height: 720 }, screenshot: only-on-failure, video: retain-on-failure, trace: retain-on-failure, }, projects: [ { name: chromium, use: { browserName: chromium } }, ], });这里要特别说明trace: retain-on-failure它是Playwright的调试神器——测试失败时会自动录制一份完整的操作轨迹包含DOM快照、网络请求、控制台日志。后面写复杂用例你就知道它多值钱了。还有retries: 1我建议本地调试时设成0否则失败用例会自动重跑一遍影响我们判断问题。2.3 同步API与异步API怎么选Playwright同时提供sync_playwrightPython里和playwright异步两种风格。JavaScript/TypeScript下主要用异步API因为Node.js本身就是事件循环模型异步写法才能充分利用I/O并发。很多新手会问为什么page.click()前面要加await因为这些操作走的都是CDPChrome DevTools Protocol通道本质上是异步发消息再等响应。你不需要深挖协议细节你只需要记住所有对页面有影响的操作、所有取值的操作前面都加await养成肌肉记忆就行。第一阶段的安装和项目骨架到这里是够用的MCPModel Context Protocol那些集成后面单独开篇再说现在先聚焦到“写测试”这件事上。3. 第一个测试用例从定位到断言的完整链路纸上谈兵没意思直接上一个能跑的示例。假设我们要测试一个简单的搜索功能页面有一个输入框和一个搜索按钮搜索后结果区域会显示关键词。3.1 写一个最小可运行用例在tests/目录下新建search.spec.js// tests/search.spec.js const { test, expect } require(playwright/test); test(用户可以通过关键词搜索到结果, async ({ page }) { // 打开页面 await page.goto(https://example.com/search); // 在输入框输入关键词 await page.getByLabel(搜索关键词).fill(playwright); // 点击搜索按钮 await page.getByRole(button, { name: 搜索 }).click(); // 断言结果区域包含关键词 await expect(page.locator(.search-results)).toContainText(playwright); });就这么简单没有一行关于等待的代码没有try-catch没有显式的sleep。我把每一步拆开讲一下page.goto()跳转页面会等待页面load事件触发。但注意它不等所有图片和XHR请求完成如果你要测SPA应用后面要结合waitForLoadState(networkidle)或者更推荐对具体元素做断言。page.getByLabel(搜索关键词)这是Playwright的语义化定位器它会找到label标签关联的输入框。比page.fill(input[namekeyword])这种CSS写法人性化太多。page.getByRole(button, { name: 搜索 })通过ARIA角色定位按钮这模拟的是“残障用户使用读屏软件时如何识别页面”是一种更接近用户视角的定位方式。expect(page.locator(.search-results)).toContainText(playwright)这个断言会自动等待最多5秒直到.search-results元素中出现包含playwright的文本。3.2 用test.describe组织业务场景当用例多起来以后建议用test.describe做分组这样报告里层级清晰也能给一组用例统一加前置和后置钩子test.describe(搜索功能, () { test.beforeEach(async ({ page }) { await page.goto(https://example.com/search); }); test(搜索空关键词给出提示, async ({ page }) { await page.getByRole(button, { name: 搜索 }).click(); await expect(page.locator(.empty-tip)).toBeVisible(); }); test(搜索特殊字符不报错, async ({ page }) { await page.getByLabel(搜索关键词).fill(#$%^*); await page.getByRole(button, { name: 搜索 }).click(); await expect(page.locator(.search-results)).toBeVisible(); }); });beforeEach比beforeAll更适合UI测试因为每个用例都要保证从干净状态开始。这个组织方式看多了你会发现它跟Jest、Mocha的语法基本同构上手成本为零。3.3 命令行运行与参数说明跑测试用npx playwright test常用参数参数作用--headed有头模式肉眼看浏览器操作过程--debug调试模式会打开Playwright Inspector可单步执行--grep 搜索只运行标题中包含“搜索”的用例--projectchromium指定浏览器项目运行--workers1单线程执行排错时优先用--reporterlist使用list格式报告调试时更直观我日常开发时习惯用npx playwright test --debug来写用例一边写一边看每一步在页面上的实际效果。运行完可以在终端看到测试通过或失败的汇总失败时还会输出错误堆栈和定位器建议比如“尝试使用getByRole获取该元素”这个提示非常友好照着改就行了。4. 定位器与自动等待测试稳定的根基很多人写完第一版用例能跑通但跑几次就偶发失败。大多数问题都出在定位器写得不稳或者对自动等待机制理解不够深。这一节是把测试写稳的核心也是我实际项目中投入时间最多的地方。4.1 定位器优先级从“人如何看页面”出发Playwright推荐的定位器优先级是这样的getByRole按角色定位比如按钮、链接、文本框、复选框。最接近用户感知也是官方最推荐的。getByLabel按表单标签定位适合输入框、下拉框。getByPlaceholder按输入框占位符定位。getByText按文本内容定位适合链接、按钮、div。getByTestId按自定义>await page.locator(div.nav ul li:nth-child(2) a).click();一旦菜单多了一个li整个定位就废了。但用角色定位await page.getByRole(link, { name: 产品中心 }).click();不管菜单怎么加项只要链接文字还是“产品中心”用例就不会挂。4.2 Actionability检查的五个维度click()之所以能解决大量偶发问题是因为它在执行前会检查元素的五个状态元素已附加到DOMAttached元素可见Visible有非空的边界框且没有visibility: hidden元素稳定Stable在连续两次动画帧之间位置不变化元素能接收事件Receives Events不会被其他元素遮挡元素已启用Enabled不是disabled状态这五个条件全部满足后click()才会真正执行。如果有条件不满足Playwright默认会持续等待直到超时。这种设计的价值在真实项目里感受特别明显——你不需要关心是接口数据慢导致按钮晚出现还是某个动画挡住了点击Playwright自己会处理。但要注意一点如果元素一直在动比如图表 loading 旋转动画点击可能直接超时报错。这时候你可以用click({ force: true })跳过稳定性检查但这属于“绕过”不要滥用最多是临时规避手段。真正合理的做法是等动画结束后再点击。4.3 Web-First断言详解除了一般的toBeVisible()、toHaveText()、toHaveValue()我再补充几个场景里高频用到的await expect(locator).toHaveCount(3)用于校验列表项数量比如搜索结果条数。它自动等待直到数量匹配。await expect(locator).toHaveAttribute(href, /product/123)校验属性。await expect(page).toHaveURL(/\/search\?qplaywright/)校验当前URL支持正则。await expect(page).toHaveTitle(/搜索结果/)校验页面标题。这些断言都是异步的前面一定记得加await。我见过很多人写expect(locator).toBeVisible()忘了await结果断言对象没解析就执行下一步测试出现各种奇怪行为。4.4 自定义超时与全局配置默认超时是5秒大促页面、报表页面这种加载慢的可以针对某个操作单独加超时await page.getByText(加载完成).click({ timeout: 15000 });同时也支持在配置里全局调整use: { actionTimeout: 10000, // 操作超时 navigationTimeout: 30000, // 导航超时 }我的习惯是测试开发阶段全用默认值等CI上确实因为网络不稳定频繁超时再针对特定场景调大超时。“超时”类问题不能一上来就全局加大那会把真实的性能回归问题掩盖掉。比如说页面加载从2秒变成10秒如果你在配置里把导航超时设成30秒这个问题可能直到用户投诉才会被发现。测试的其中一层价值就是守住性能底线。5. 测试登录态、接口Mock与文件上传下载的实战写法第一篇文章如果只讲定位和断言那其实还没完全脱离Selenium时代的思维框架。Playwright真正厉害的地方在于它对“浏览器能力”做了全面封装——网络层、存储层、对话框、多标签页、iframe都能直接控制。这一节全是干货每段代码都是我实际项目里跑过的。5.1 登录态复用storageState每个测试独立浏览器上下文导致每个用例都要重新登录登录一次还好如果登录还要扫码、还要走短信验证码那测试效率会被拖垮。Playwright的解法是storageState——先把登录后的存储状态保存下来后续用例直接加载。// 登录并保存状态一般单独跑一次 test(登录并保存认证信息, async ({ page }) { await page.goto(https://example.com/login); await page.getByLabel(用户名).fill(tester); await page.getByLabel(密码).fill(pass123); await page.getByRole(button, { name: 登录 }).click(); await page.waitForURL(**/dashboard); // 保存cookie和localStorage到指定文件 await page.context().storageState({ path: auth/user.json }); });后续用例在配置里直接指定use: { storageState: auth/user.json, }这样每个用例起来就是已登录状态。需要注意storageState保存的是cookie和localStorage如果你的登录态存在sessionStorage里某些SPA会这么干是保存不了的这时就得考虑让登录接口走page.request直接请求或者每个用例自己登录。另外auth文件不要提交到代码仓库里面是敏感信息我在.gitignore里始终放着auth/目录。5.2 拦截与Mock网络请求UI自动化最怕外部依赖不稳定——第三方登录、支付回调、天气接口超时。Playwright用page.route()可以拦截请求并返回mock数据test(支付成功页展示订单金额, async ({ page }) { // 拦截支付状态查询请求 await page.route(**/api/payment/status?**, route { route.fulfill({ status: 200, contentType: application/json, body: JSON.stringify({ status: success, amount: 99.00 }), }); }); await page.goto(https://example.com/order/123); await expect(page.locator(.pay-status)).toContainText(支付成功); await expect(page.locator(.pay-amount)).toContainText(99.00); });route.fulfill()直接从浏览器层面伪造响应页面根本感知不到请求是真是假。这下你不再需要启动一个mock server不需要改测试环境hosts每个用例可以独立控制接口返回。搭配条件路由你还能模拟失败场景await page.route(**/api/user/info, route { route.fulfill({ status: 500, contentType: application/json, body: {error:server error} }); });用来测试前端对接口异常的处理。这是我在实际工作中最常用、也最提升用例稳定性的功能。原本依赖后端环境联调的用例现在在本地就能全量跑。5.3 iframe与多标签页处理scrapy和playwright结合爬动态iframe页面是网上问得比较多的话题。如果页面里有嵌套的iframe直接page.locator()是拿不到的需要先切换到frameconst frame page.frameLocator(#main-iframe); await frame.getByLabel(用户名).fill(tester); await frame.getByRole(button, { name: 提交 }).click();注意是frameLocator返回的是一个专门的定位器后续操作都在这个iframe内部查找。不需要像Selenium那样driver.switchTo().frame()然后再切回来Playwright的frameLocator是链式的也不影响外层页面的定位心智负担小很多。多标签页的处理也简洁——用Promise.all同时监听新页面const [newPage] await Promise.all([ page.waitForEvent(popup), page.getByRole(link, { name: 打开新窗口 }).click(), ]); await newPage.getByRole(heading, { name: 新页面内容 }).toBeVisible();这里有个经典坑如果你先点击再waitForEvent(popup)新页面已经打开你就错过了这个事件所以必须用Promise.all把“等待事件”和“触发事件”同时挂起。很多新手在这卡很久我当年也是踩了一遍才反应过来。5.4 文件上传与下载文件上传有两种常见交互。一种是input typefile元素直接用setInputFiles()await page.getByLabel(上传头像).setInputFiles(test-data/avatar.png);如果是拖拽上传区域没有input元素那就要合成一个DataTransfer来触发drop事件。这块代码稍微繁琐但原理就是通过page.dispatchEvent把文件放到拖拽事件里。需要的时候可以再查官方文档我先把这类场景标记为“可做但不常用”。文件下载更简单const downloadPromise page.waitForEvent(download); await page.getByRole(button, { name: 导出Excel }).click(); const download await downloadPromise; await download.saveAs(downloads/result.xlsx);saveAs()支持指定保存路径下载到的文件名还可以用download.suggestedFilename()拿到。跑完用例后我一般会加一条断言检查下载的文件大小不为0const path await download.path(); const fs require(fs); const stat fs.statSync(path); expect(stat.size).toBeGreaterThan(0);别小看这条断言我以前遇到过下载接口返回200但文件是空的——前端没报错用户下载下来是个0字节文件不检查根本发现不了。6. 运行与调试从失败信息里快速定位问题用例写得再稳总有挂掉的时候。能不能高效地从失败信息定位问题直接决定自动化测试能不能真正跑进CI流程。这一节分享我自己平时排错的具体流程和工具用法。6.1 HTML报告与Trace Viewer跑完npx playwright test后执行npx playwright show-report浏览器会自动打开一份HTML测试报告。里面能看到每个用例的执行结果、运行时长、失败时自动截的截图和录屏。但我个人觉得最厉害的是Trace Viewer——打开失败用例的trace文件后你可以在时间线上逐步回放整个测试过程每一步都带DOM快照。比如某个用例失败在点击按钮那一步Trace Viewer里你能看到那一瞬间页面的真实DOM是什么样元素是否存在、被什么遮挡网络请求发了哪些、返回了什么状态码控制台有没有报错这个信息密度是传统日志完全没法比的。我自己的排错效率因为Trace Viewer至少提升了三倍。很多问题以前要复现好几次才能定位现在打开Trace一次就能看到。所以配置里的trace: retain-on-failure一定要开这是后期排查问题的关键。6.2 调试模式步进执行与实时查看元素用npx playwright test --debug跑用例会自动打开Playwright Inspector。界面上能单步执行每一步操作左侧是操作列表右侧是页面实时状态。点击页面上的任何元素Inspector会给出该元素的推荐定位器代码直接复制就能用。这个功能还有个杀手锏——Timespans时间轴。在Inspector面板的右上角可以查看每一步操作花了多少毫秒。如果某一步特别慢说明页面当时正在等某个资源或者动画这往往是测试不稳定的根源。配合调试我建议本地把headless临时改成false看着浏览器真实操作比纯靠日志判断直觉准确得多。6.3 定位失败的常见原因与处理页面元素未出现就点击了默认5秒超时不够针对操作单独加timeout。有多个相似元素getByRole(button, { name: 提交 })报strict mode violation说明页面上有多个“提交”按钮。这时候需要把定位范围缩小比如page.locator(.modal).getByRole(button, { name: 提交 })先框定弹窗范围再定位。元素被遮挡检查是否有弹窗、遮罩层覆盖。先处理遮罩或者用expect(popup).toBeHidden()确认弹窗关闭后再继续。iframe元素定位不到看页面结构用frameLocator切换上下文。SPA路由延迟点击后不立即出现新页面用page.waitForURL()等待URL变化。调试问题我建议别依赖猜测优先开Trace看现场。大多数错误信息都会提示具体是哪个定位器失败、超时多久、有哪些候选元素。按提示改定位器通常比乱试快得多。6.4 重试机制与Flaky用例的取舍测试偶发失败在业内叫Flaky Test是自动化测试套件最大的敌人之一。配置中设置retries: 1或retries: 2能暂时掩盖这个问题但我不建议单纯靠重试“治标”。你的目标应该是保证测试套件在无重试的情况下也能稳定通过。如果某个用例反复出现间歇性失败先打开它的Trace看看失败瞬间页面在干什么。常见原因包括接口响应在2秒和10秒之间波动操作超时设置太紧第三方广告或埋点脚本阻塞主线程动画未结束导致元素位置不稳定前端日志上报导致页面资源竞争针对前两种把相关超时调大、拦截广告脚本就能解决针对动画可以用expect先等待动画相关的样式稳定或者干脆在测试环境禁用动画效果。一个经验法则是如果一个用例重试3次里能挂1次它迟早会在主干流水线上给你添堵。与其容忍不如当天就把原因查了。6.5 与CI集成之后的一些维护体会最后聊点实际的维护心得。Playwright官方提供了Docker镜像CI里可以这样跑docker run --rm --network host mcr.microsoft.com/playwright:v1.40.0 npx playwright test或者更常见的是在GitHub Actions、GitLab CI里直接用官方维护的action。核心思路都是在CI环境安装浏览器依赖后执行测试命令再把HTML报告和trace上传为构建产物。这样开发同学能直接在流水线页面点开失败用例的Trace根本不用本地复现。在实际项目里我是这样安排测试分层的每次提交跑冒烟测试耗时3分钟以内覆盖核心流程每晚全量回归覆盖全部用例跑完自动发报告到企业微信/邮件每周清理一次Flaky用例这套策略跑了一年多测试从“Q3前的演示玩具”变成了“版本发布前的门禁标准”核心原因就是Playwright的调试体验足够好让整个团队愿意去维护用例。如果调试一个失败用例要花半天没人会想碰它。7. 从测试生成器开始的另一种路径codegen帮你快速起步写用例不一定要手写Playwright自带一个测试生成器不过它是基于录制的。适合用来快速生成一段可运行的测试骨架再手动改造成真正的测试用例。在命令行执行npx playwright codegen会弹出一个浏览器窗口和一个Inspector面板。你在浏览器里操作页面Inspector会自动记录每一步操作并生成对应的代码。操作结束后把代码复制进测试文件补充断言就行了。这个工具真正有用的场景是不熟悉某个新页面的DOM结构时用它操作一遍GEnerated代码再对照修改定位器。比自己翻DevTools快得多。需要快速验证某个操作序列在playwright里能不能跑通。面对复杂控件比如富文本编辑器、日历组件录制比手写定位器靠谱。但它生成的代码也存在一些缺点定位器经常是page.locator(div:nth-child(2) .ant-input)这种脆弱的CSS路径断言也只会生成一些基础的expect。所以我的建议是用它来“探路”不要直接拿它生成的代码当最终产物。生成之后一定把定位器改成语义化的角色/文本定位。8. 从编程模型角度理解Playwright同步等待与异步事件Playwright的编程模型跟大部分测试框架有本质区别。它不是一次性执行完所有测试命令就结束而是维护了一套“事件循环自动等待”机制。理解这一点能帮助你在写复杂用例时避开很多深坑。8.1 事件驱动的等待机制以page.waitForSelector()为例现在更推荐直接配合expect使用它底层是一个Promise等到元素出现或者超时才resolve。而page.click()底层的实现也不仅仅是发射一个鼠标点击事件而是先走完整个Actionability检查链再通过CDP发射输入事件。这个模型的好处是你不再需要关心页面是刚加载完还是正在异步渲染中。8.2 并发执行与并发安全默认情况下Playwright会在多个worker中并行跑测试文件所以--workers参数才存在。每个worker是独立的浏览器进程这约束着你写的测试代码必须是线程安全的。最常见的反例是多个测试文件共用同一个临时目录或修改同一个全局配置这会导致竞争条件。我的建议是每个测试用例用到的测试数据都生成独立副本不要共用可变状态。比如上传文件名的生成可以用test-info里的唯一标识const fileName upload-${test.info().testId}.png;9. 我自己的项目实践从100个用例到500个用例的踩坑记录最后这段我不讲框架讲讲在真实业务场景里把Playwright用起来的完整经历。这套东西如果不落地到具体项目永远只是“会写”而不是“会用”。9.1 初期选对第一批用例我先选了一个最高频、收益最大的核心路径做试点——用户从登录到下单的全流程。大概20条用例包含了登录、搜索、加购、下单、支付回调、订单列表。因为这是产品最核心的路径开发频繁改动回归成本高用自动化替换人工回归收益立竿见影。第一批用例跑稳后再逐步向外扩散到用户中心、订单中心、客服工作台等功能域。扩散时遵循一个原则新用例必须能在本地跑通20次不失败才会合入主测试套件。这条原则帮我挡住了大量Flaky用例。9.2 中期测试数据管理500个用例跑起来后最大的痛点变成了测试数据。每个用例要独立的商品数据、用户数据、订单数据。一开始我是在测试环境手工造数据后来发现数据库被其他团队开发重置后就全挂了。现在的方案是基础数据商品、用户用接口fixture在beforeAll的时候造业务数据订单、优惠券用page.request创建敏感或高成本数据用mock方式拦截三者结合基本做到每个用例不依赖“当前测试环境残留了什么”。9.3 后期失败通知与追踪每晚全量回归跑完报告会推送到团队的即时通讯群。我要求开发同学看到失败通知的第一反应不是“谁又乱改页面了”而是去Trace Viewer里把失败现场看完再决定怎么处理。这套流程跑顺后前端代码合并前必须过一遍关联用例回归问题在合并前就拦住了。9.4 关于Cherry Studio安装Playwright和MCP集成搜索热词里提到“cherry studio怎么安装playwright”和“playwright MCP”。Cherry Studio这种AI客户端本质就是一个桌面壳子它要的就是安装Playwright命令行工具然后通过MCP协议暴露给AI去操作浏览器做自动化验证。其实思路跟我们在项目里做的一样——让非测试人员也能用自然语言驱动一套已验证的Playwright脚本库去验证页面。这块内容展开讲能写一整篇这篇先点到为止等后续文章再单独开专题。10. 书写下一章之前的一个小建议按这个系列往下走下一篇应该会讲“页面对象模型Page Object Model”怎么落地以及如何组织一个中大型项目的测试结构。第一条建议已经摆出来了不要期望一次性把用例写到完美。先写能跑的再逐步把定位器改为语义化、把公共逻辑提取成POM、把数据准备改成接口调用。Playwright的优势是它给你留了很大的重构空间不会像早期框架那样改一次定位器就要动一整批用例。只要你能从小用例跑起稳定积累它就会成为你手上最顺手的回归利器。
阅读完成 · 觉得有帮助？
