大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）
 

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

Cursor + Playwright MCP：测试工程师的自救指南

---

又是崩溃的一天

我坐在公司工位上，盯着屏幕上那个刺眼的红色报错：

TimeoutError: page.click: Target closed =========================== logs =========================== waiting for locator(‘[data-testid=“submit-btn”]’)   locator resolved to …   attempting click action   waiting for element to be visible, enabled and stable   element is visible, enabled and stable   scrolling into view if needed   done scrolling   performing click action ============================================================

“明明元素都在那儿，怎么就是点不上？”

这是我这周第三次被同一个测试用例搞崩溃了。

前端的同事昨天刚把 data-testid 从 submit-btn 改成了 submit-button，说是“更符合命名规范”。就这一个改动，我的三十条用例全挂了。

更离谱的是，这个按钮的 class 名是动态生成的——btn btn-primary 后面跟着的那串 data-v-3a2b1c，每次构建都会变。

我试过 CSS 选择器，试过 XPath，试过文本匹配，试过相对定位……能想到的办法都用上了。

“要不你试试截图对比？” 对面工位的同事探过头来说。

“试过，不稳定。UI 稍微变一下像素，就认不出来了。”

“那视觉模型呢？”

“太慢了，跑一轮回归要三小时，领导不可能批这个资源。”

他耸耸肩，转回去了。

我盯着屏幕，突然有点怀疑人生。

都2026年了，AI 都能写代码了，为什么测试自动化还是这么痛苦？

---

前几天，我在刷 GitHub Trending 的时候，看到了一个项目：

Playwright MCP Server

“微软官方出品，基于 Model Context Protocol……”

本来是抱着“又一个玩具项目”的心态点进去的。

但当我看到这段描述时，不觉点好奇起来：

“Unlike screenshot-based approaches, Playwright MCP uses accessibility snapshots to understand page structure, eliminating the need for vision models.”

不用截图，不用视觉模型。

这意味着什么？

意味着我可以摆脱那些该死的像素对比了。意味着测试速度可以快一个数量级。意味着……也许我终于不用再痛苦地去改 XPath 了。

我立刻打开 Cursor，开始折腾。

---

先别急着上手，咱们得搞清楚这东西的原理。

3.1 传统方案的问题

以前做 UI 自动化，基本就两条路：

第一条路：DOM 操作

用 Selenium、Playwright、Cypress 这些工具，直接操作浏览器的 DOM。

优点是快，缺点是脆弱。页面结构一变，选择器就失效。就像我那个凌晨三点遇到的悲剧。

第二条路：视觉模型

用 GPT-5、Claude 4 这些多模态模型，截图喂给 AI，让 AI 告诉你要点哪里。

优点是智能，能处理动态内容。缺点是慢，贵，而且有时候 AI 会“看错”。

3.2 Playwright MCP 的破局点

Playwright MCP 走了第三条路：Accessibility Tree（无障碍树）。

这是什么概念？

现代浏览器为了支持屏幕阅读器（给视障人士用的辅助技术），会在渲染页面的同时，构建一棵“无障碍树”。这棵树描述了页面上每个元素的语义信息：

• 这是一个按钮，文字是“提交”
• 这是一个输入框，标签是“用户名”
• 这是一个链接，指向 “/dashboard”

关键是，这棵树是语义化的，不是视觉化的。

也就是说，即使按钮的样式变了、位置变了、甚至 CSS 类名变了，只要它的语义没变（“这是一个提交按钮”），AI 就能找到它。

Playwright MCP 把这棵树打包成 JSON，通过 MCP（Model Context Protocol）协议传给 Cursor。Cursor 里的 AI 就能“理解”页面结构，然后决定要点哪里、填什么。

3.3 核心工具一览

Playwright MCP 提供了这些工具：

• browser_navigate - 导航到指定 URL
• browser_click - 点击元素
• browser_fill - 填充输入框
• browser_screenshot - 截图（调试时用）
• browser_hover - 悬停
• browser_select_option - 选择下拉框选项
• browser_go_back / browser_go_forward - 浏览器前进后退

看起来和普通的 Playwright API 差不多？

差别在于调用方式。

以前你写：

await page.click(‘[data-testid=“submit-btn”]’);

现在你直接跟 AI 说：

“点击提交按钮”

AI 会自己去看 accessibility tree，找到那个叫“提交”的按钮，然后点它。

不需要你写选择器。

这就是革命性的地方。

---

光说原理没意思，上代码。

以下三个案例，都是我最近在实际项目中遇到的。不是那种“登录表单”的简单示例，而是真实业务里的复杂场景。

案例一：动态表格的数据校验

场景描述：

我们有一个数据报表页面，表格里的数据是实时从后端拉取的。行数不固定，列数也不固定（根据用户权限动态显示）。

以前写这个用例，我得先等表格加载完，然后数有多少行，再遍历每一行，提取单元格文本，最后做断言。

代码长这样：

// 以前的做法 await page.waitForSelector(‘table tbody tr’); const rows = await page.locator(‘table tbody tr’).all(); const data = []; for (const row of rows) { const cells = await row.locator(‘td’).all(); const rowData = []; for (const cell of cells) {     rowData.push(await cell.textContent());   }   data.push(rowData); } // 然后还要写一堆断言……

用 Playwright MCP 的做法：

我在 Cursor 里新建一个 agent，然后直接说：

“打开报表页面，等表格加载完成后，提取所有数据，验证第三列的总和是否等于右下角的汇总值。”

Cursor 的 AI 会：

1. 调用 browser_navigate 打开页面
2. 等表格加载（通过 accessibility tree 判断表格是否出现）
3. 读取整个表格的结构（通过 accessibility tree，不是 DOM）
4. 提取第三列的所有数值
5. 找到汇总单元格的值
6. 做计算和断言

整个过程，我没有写一行选择器。

AI 自己找到了表格，自己识别了列，自己做了计算。

耗时：从以前的 40 分钟写用例，变成了 3 分钟描述需求。

案例二：复杂的表单联动

场景描述：

一个配置页面，有三级联动下拉框：

• 第一级选“产品类型”
• 第二级的选项根据第一级的结果动态加载
• 第三级的选项根据第二级的结果动态加载
• 还有一些字段是条件显示的（比如选了“企业版”才显示“企业资质上传”）

以前这种用例，我得写一堆 waitFor，还得处理各种异步加载的时序问题。

用 Playwright MCP 的做法：

“打开配置页面，选择产品类型为‘企业版’，等二级下拉框加载完成后选择‘高级套餐’，验证三级下拉框出现了‘旗舰版’选项，并且页面上显示了企业资质上传区域。”

AI 会自己处理等待逻辑。因为 accessibility tree 会告诉它：“二级下拉框现在有 5 个选项”、“企业资质上传区域现在是可见状态”。

关键区别：

以前我用 waitForSelector，等的是 DOM 元素出现。但元素出现了，不代表数据已经加载完了。

现在 AI 读的是 accessibility tree，它能看到下拉框里的选项内容。如果选项还没加载完，AI 会知道“现在还不能选”，然后继续等。

这种“语义层面的等待”，比“DOM 层面的等待”可靠得多。

案例三：跨页面的业务流程

场景描述：

一个完整的业务流程：创建订单 -> 支付 -> 查看订单详情 -> 申请退款 -> 确认退款状态。

涉及 5 个页面，每个页面都有复杂的表单和状态变化。

以前这种用例，我得写几百行代码，还要处理各种页面跳转、弹窗、toast 提示。

用 Playwright MCP 的做法：

我在 Cursor 里写了一段自然语言描述：

帮我测试这个业务流程：
1. 在商品列表页选择“测试商品A”，点击购买
2. 在订单确认页填写收货地址，选择支付宝支付
3. 在支付页完成支付（用测试环境模拟）
4. 验证跳转到订单详情页，状态显示“已支付”
5. 点击申请退款，选择退款原因“拍错了”
6. 提交退款申请后，验证状态变成“退款中”
7. 去后台管理系统（另一个域名）确认退款
8. 回到订单详情页刷新，验证状态变成“已退款”
























Cursor 的 AI 会把这个流程分解成一系列工具调用：

• browser_navigate 到商品列表
• browser_click 选择商品
• browser_fill 填写地址
• browser_click 选择支付方式
• ……

最神奇的是，当 AI 发现“申请退款”按钮被 toast 提示挡住了时，它会自己等 toast 消失，然后再点。

这种“常识性”的处理，以前我得写一堆显式的等待和重试逻辑。现在 AI 自己搞定了。

---

说了这么多好处，也得说说配置过程。

Playwright MCP 不是开箱即用的，我踩了不少坑。

5.1 安装步骤

首先，你需要一个支持 MCP 的编辑器。目前 Cursor 是体验最好的。

然后安装 Playwright MCP：

npm install -g @executeautomation/playwright-mcp-server

在 Cursor 里配置 MCP：

1. 打开 Cursor Settings -> MCP
2. 点击 “Add New MCP Server”
3. 填写：
   • Name: Playwright MCP
   • Type: command
   • Command: npx -y @executeautomation/playwright-mcp-server

5.2 我踩过的坑

坑一：端口冲突

Playwright MCP 默认用 3000 端口。如果你本地跑了其他服务（比如 Next.js 开发服务器），会冲突。

解决：启动时指定端口

npx -y @executeautomation/playwright-mcp-server –port 3456

坑二：浏览器路径

在某些 Linux 环境下，Playwright 找不到 Chromium。

解决：手动安装浏览器

npx playwright install chromium

坑三：权限问题

Mac 上第一次运行可能会报权限错误，说“无法打开，因为无法验证开发者”。

解决：去系统设置 -> 隐私与安全 -> 允许 Anyway。

坑四：网络代理

如果你的公司网络有代理，Playwright MCP 可能连不上浏览器。

解决：设置环境变量

export HTTP_PROXY=http://your-proxy:port export HTTPS_PROXY=http://your-proxy:port

坑五：Timeout 太短

默认的 timeout 是 30 秒，对于慢一点的页面不够用。

解决：在 Cursor 的 MCP 配置里加参数：

{   “command”:“npx”, “args”:[“-y”,“@executeautomation/playwright-mcp-server”], “env”:{     “PLAYWRIGHT_TIMEOUT”:“60000” } }

5.3 **实践

经过两周的折腾，我总结了几条**实践：

1. 先截图确认：让 AI 先 browser_screenshot 一下，确认它在看正确的页面
2. 分步骤验证：复杂的流程拆成多个小步骤，每步验证一下状态
3. 保留日志：开 DEBUG=* 环境变量，出问题好排查
4. 别完全相信 AI：AI 偶尔也会认错元素，关键断言还是要人工检查

---

说了这么多，来点实在的：用了 Playwright MCP 之后，我的效率到底提升了多少？

我统计了最近一个月的数据：

最惊喜的是最后一条。

上周组里来了新同事，以前从来没写过自动化测试。我让他用 Playwright MCP 写个简单的登录用例，结果他 20 分钟就搞定了。

以前我得先给他讲 XPath、CSS 选择器、显式等待、隐式等待……现在？

“你就告诉 AI 你想测什么，它会帮你写。”

---

写到这里，我得泼点冷水。

Playwright MCP 不是万能的，它有自己的局限性。

7.1 对复杂视觉场景无能为力

如果你的测试需要验证“这个按钮是不是红色的”、“这个图表的柱状图高度对不对”，Playwright MCP 搞不定。

它读的是 accessibility tree，不是像素。颜色、布局、视觉样式，它都看不到。

这种场景还是得用视觉模型，或者传统的截图对比。

7.2 对自定义组件支持有限

如果你的前端用了一些非标准的自定义组件（比如自己用 Canvas 画的图表、用 WebGL 做的 3D 效果），accessibility tree 里可能没有这些信息。

AI 会“看不见”这些元素。

7.3 成本问题

Playwright MCP 本身免费，但 Cursor 的 AI 调用是收费的。

我算了一下，跑一轮完整的回归测试（大概 200 条用例），AI 调用的成本大约在 2-3 美元。

如果你们的测试量很大，这个成本要考虑进去。

7.4 调试难度

当测试失败时，调试比以前复杂了。

以前我能直接看代码，知道是哪行报的错。现在 AI 生成的操作序列是动态的，出问题得看日志，一层层追踪 AI 的决策过程。

Cursor 的 MCP 调试工具还在完善中，目前体验一般。

7.5 不适合极度复杂的场景

如果你的测试需要处理多窗口、多标签页、iframe 嵌套、文件上传下载……Playwright MCP 能搞定，但 AI 的决策会变得不稳定。

这种场景建议还是写传统代码，或者把流程拆得更细。

---

最后聊聊趋势。

2026 年，测试行业正在经历一场静默的革命。

从“人工测试”到“智能测试”

以前，测试工程师的核心技能是写代码、写 SQL、写 XPath。

现在，这些技能依然重要，但不再是核心。

核心技能变成了：描述清楚你要测什么。

AI 会帮你实现。你只需要告诉它业务逻辑、验收标准、边界条件。

从“脚本维护”到“意图维护”

以前，页面一变，测试脚本就得重写。

现在，只要业务意图没变（“用户要能登录”），AI 能自己适应页面的变化。

从“回归测试”到“持续验证”

以前，回归测试是阶段性的——发版前跑一次。

现在，AI 可以在每次代码提交后自动跑测试，甚至可以在开发过程中实时验证。

Playwright MCP 只是这个趋势的一个缩影。

类似的工具还有：

• Browser-use：另一个基于 AI 的浏览器自动化工具
• Stagehand：专门做端到端测试的 AI 框架
• Testim / Mabl：商业化的 AI 测试平台

2026 年，不会用 AI 辅助测试的工程师，可能会像 2020 年不会用 Selenium 的工程师一样，逐渐被淘汰。

---

现在我很少在公司加班到很晚了。

不是因为我变懒了，而是因为效率真的提高了。

以前改一个用例要半小时，现在五分钟。以前维护测试脚本是噩梦，现在 AI 帮我扛住了大部分压力。

但我也要说一句：Playwright MCP 不是替代测试工程师的工具，它是放大测试工程师能力的工具。

你依然需要懂业务、懂测试设计、懂边界条件分析。这些 AI 替代不了。

但那些重复的、机械的、让人崩溃的 DOM 操作，就让 AI 去干吧。

我们去做更有价值的事。

---

如果你也想试试 Playwright MCP，建议从一个小项目开始。

别一上来就重构整个测试框架。先选几个最痛苦的用例，用 Playwright MCP 重写一遍，感受一下区别。

相信我，当你第一次看着 AI 自己找到那个“怎么都定位不到”的按钮时，你会和我一样，忍不住说一句：

“真香。”

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​​

​