AI + Playwright 有什么提效的开源工具？

AI + 自动化测试的项目越来越多。

自然语言写 Case、AI 生成 Playwright、AI 操作浏览器……

第一次看的时候都挺惊艳。

但如果真的做过几年 UI 自动化，应该知道一个很现实的问题：

自动化最痛苦的，很多时候不是“写出来”，而是“养下去”。

今天页面还是：

Login

明天产品改版：

Sign in

原来的 Locator 挂了。

今天：

#submit

下个版本前端重构：

[data-testid="login-button"]

又挂了。

于是每天 CI 里面一片红。

你开始排查：

到底是 Bug？

还是环境问题？

还是数据问题？

还是 UI 改了？

还是 Selector 又失效了？

最后发现：

业务一点问题都没有，只是按钮换了个地方。

这也是为什么很多公司自动化刚开始做的时候轰轰烈烈，半年以后就没人愿意维护了。

最近看到一个挺有意思的开源项目：

Passmark。

GitHub：bug0inc/passmark

目前已经有 1K+ Star。

它想解决的问题，刚好就是：

“

能不能让 AI 不只是帮我们“写自动化”，还帮我们“养自动化”？

---

一、先看看普通 Playwright 为什么容易变成维护地狱

比如我们要测试一个商城购物流程。

传统 Playwright 可能是：

await page.goto('/products');await page  .getByText('Acme Circles T-Shirt')  .click();await page  .getByLabel('Color')  .selectOption('White');await page  .getByLabel('Size')  .selectOption('S');await page  .getByRole('button', {    name: 'Add to cart'  })  .click();

第一次写的时候其实没什么问题。

真正的问题发生在几个月以后。

前端：

“

我改了下页面。

测试：

“

改了什么？

前端：

“

没什么，就重构了一下。

然后 CI：

FAILEDElement not found

你：

……

于是开始打开页面。

F12。

找元素。

改 Locator。

重新运行。

提交代码。

CI 再跑。

如果只有 10 条自动化还好。

如果是：

500 条1000 条3000 条

这种维护成本就开始变得很难受了。

所以 UI 自动化真正贵的地方，从来不只是：

第一次写脚本。

而是：

后面每一次页面变化，都可能需要有人继续维护。

---

Passmark 还是建立在 Playwright 上。

但写测试的时候，可以不用先写一堆 Selector。

例如测试一个购物车。

可以直接描述：

打开商城点击 Acme Circles T-Shirt选择 White选择 S加入购物车检查购物车里出现这件商品

Passmark 提供的 runSteps() 会把这些自然语言步骤交给 AI，再通过 Playwright 操作浏览器。

整个流程可以简单理解成：

自然语言测试步骤        ↓       AI        ↓理解页面结构        ↓生成实际操作        ↓    Playwright        ↓     Browser

所以测试人员写的东西开始从：

怎么找到这个按钮？

慢慢变成：

我要测试什么？

比如：

steps: [  { description: "Click Acme Circles T-Shirt" },  { description: "Select color", data: { value: "White" } },  { description: "Select size", data: { value: "S" } },  { description: "Add to cart" }]

代码一下就简单很多。

不过如果 Passmark 只是做到这里，我觉得其实没什么特别值得写的。

现在能做“自然语言 → 浏览器操作”的项目已经不少了。

真正让我觉得有意思的是后面。

---

这是我看到 AI 自动化时最先想到的问题。

假设：

1000 条自动化

每天跑：

5 次

每一个步骤都：

页面 ↓AI ↓分析 ↓操作

那问题马上来了。

第一：

Token 不要钱吗？

第二：

模型调用不要时间吗？

第三：

模型每次结果一定一样吗？

如果传统 Playwright：

几十毫秒↓找到元素↓点击

现在变成：

获取页面↓调用模型↓等待模型↓模型分析↓返回操作↓Playwright 执行

那自动化可能反而越做越慢。

所以 Passmark 加了一个我觉得非常重要的东西：

Step Cache。

---

假设第一次执行：

点击 Login

AI 分析页面。

找到正确操作。

Playwright 执行成功。

Passmark 会把成功的 Step 缓存起来。

下一次再跑：

点击 Login

就不需要重新问 AI 了。

而是：

Step ↓检查 Cache ↓找到之前成功的操作 ↓Playwright ↓直接执行

也就是：

第一次自然语言 ↓AI ↓找到操作 ↓Playwright ↓成功 ↓Cache以后自然语言 ↓Cache ↓Playwright

AI 退出。

这点其实非常重要。

因为 AI 自动化如果真的想进入 CI/CD，就不能：

每一个步骤、每一次回归，都让大模型重新思考。

稳定的东西应该尽可能缓存下来。

---

这就到了 Passmark 最有意思的部分：

Auto-Healing。

比如之前：

Add to cart

这个步骤已经缓存。

每天直接执行。

突然某天前端改版。

原来的操作失效了。

传统自动化：

Cache / Locator     ↓   执行     ↓   FAILED     ↓测试人员收到通知     ↓打开页面     ↓重新找元素     ↓修改代码     ↓重新提交

Passmark 想做的是：

Cache  ↓执行  ↓失败  ↓AI 重新分析当前页面  ↓找到新的操作方式  ↓重新执行  ↓成功  ↓更新 Cache

这就是所谓：

Self-Healing。

说得简单一点：

“

旧路走不通了，让 AI 自己重新找一条路。

---

以前大家讨论 AI + 自动化，经常关注：

“

AI 能不能帮我写代码？

但我越来越觉得：

这可能不是最有价值的问题。

因为一个稍微熟悉 Playwright 的测试工程师，写：

await page.getByRole('button').click();

真的没有多难。

真正让测试人员头疼的是：

半年以后，这几千行代码谁来维护？

如果 AI 能做到：

页面小改版↓原操作失效↓AI 自动重新定位↓验证成功↓缓存新操作↓继续跑

那么它解决的是：

自动化维护成本。

这比“帮我少写几行 Locator”有价值得多。

---

做测试最终绕不开一个问题：

怎么判断 PASS / FAIL？

传统自动化一般是：

expect(text).toBe("Success");

非常确定。

但如果我们开始用 AI 判断页面：

“这个订单是不是创建成功了？”

问题来了：

AI 会不会看错？

如果只有一个模型：

Claude：PASS

测试就通过？

Passmark 的做法比较有意思。

它可以同时让：

Claude+Gemini

判断。

如果：

Claude：PASSGemini：PASS

那比较简单。

如果：

Claude：PASSGemini：FAIL

怎么办？

再让第三个模型当裁判。

也可以直接配置成：

两个模型意见不一致↓直接 FAIL↓交给人看

这个设计我挺喜欢。

因为 AI 测试真正麻烦的地方并不是：

AI 会不会操作页面。

而是：

AI 判断错了怎么办？

让多个模型互相验证，至少比“一个模型说了算”靠谱一些。

---

这个功能我觉得挺有意思。

比如点击：

保存

页面弹出：

保存成功

1 秒以后消失。

这种 Toast、Snackbar、临时 Banner，在 UI 自动化里面经常比较烦。

因为你截图的时候：

没了。

你做 AI 页面判断的时候：

也没了。

Passmark 提供了：

Video Assertion。

简单理解就是：

开始执行 ↓录制页面 ↓点击保存 ↓Toast 出现 ↓Toast 消失 ↓执行结束 ↓把整段视频交给模型 ↓判断：“刚才有没有出现保存成功？”

这样 AI 判断的不是：

最后一帧。

而是：

刚才整个过程中发生过什么。

对于：

ToastSnackbarLoading短暂动画一闪而过的错误提示

这种东西确实挺有用。

---

Passmark 默认还是通过页面的 Accessibility / ARIA 信息理解 Web 页面。

但现在它还支持 Computer Use 模式。

简单理解：

传统方式：

DOM / ARIA ↓AI ↓Playwright

Computer Use：

页面截图 ↓AI 看屏幕 ↓判断按钮在哪里 ↓通过坐标操作

这就意味着以后某些：

Canvas复杂可视化页面拖拽SliderDOM 不友好的页面

也可以尝试让视觉模型处理。

当然，这种方式成本和稳定性目前肯定还是需要实际验证。

但方向已经比较明显了：

规则明确的页面，用结构化信息。

实在不好操作的页面，再让 AI 看屏幕。

没必要什么东西都上最贵的 AI。

---

我觉得千万不要把它理解成：

“

Passmark 要替代 Playwright。

恰恰相反。

它底层还是 Playwright。

可以简单理解：

            测试人员                ↓          自然语言 Test                ↓            Passmark                ↓        ┌───────┴────────┐        ↓                ↓      Cache              AI        ↓                ↓        └───────┬────────┘                ↓           Playwright                ↓             Browser

Playwright 负责：

稳定执行浏览器操作。

AI 负责：

那些不稳定、需要理解页面的地方。

Cache 负责：

能不用 AI 的时候就别用 AI。

我觉得这个分工其实挺合理。

---

这里还是得泼点冷水。

Self-Healing 最大的问题就是：

它修好了，到底是不是好事？

比如以前按钮叫：

Submit Order

后来页面改成：

Cancel Order

如果 AI：

“原来的按钮找不到了。”

然后聪明地找到了另外一个按钮。

点击。

执行成功。

……

这反而可能是事故。

所以 Self-Healing 最重要的问题从来不是：

能不能找到新的元素。

而是：

它找到的新元素，还是不是原来业务上那个东西？

这也是为什么 AI 自动修复不能完全没有边界。

对于：

按钮换位置DOM 重构class 变化Selector 变化

Self-Healing 很适合。

但如果：

业务流程变化交互逻辑变化产品规则变化

最好还是让测试人员确认。

否则：

测试脚本倒是绿了，业务已经测偏了。

---

而是它给出了一种比较现实的组合：

自然语言+AI+Cache+Self-Healing+Multi-Model Assertion+Playwright

每一个东西负责不同的问题。

AI：

第一次理解页面。

Cache：

别每次都浪费 Token。

Playwright：

稳定执行。

Self-Healing：

页面小变化以后自己恢复。

Multi-Model：

降低 AI 判断错误的风险。

Video：

补充截图看不到的瞬时 UI。

这比一句：

“

“AI 自动生成 Playwright 脚本。”

完整得多。

---

我以前一直觉得，AI 对 UI 自动化最大的价值是：

降低写脚本的门槛。

但看完 Passmark 这类项目之后，我现在更关注另外一个问题：

AI 能不能降低维护自动化的成本？

因为写一条自动化，只发生一次。

维护一条自动化，却可能发生：

10 次、20 次、50 次。

如果 AI 只是帮我们：

100 行代码↓变成20 行代码

确实有帮助。

但真正改变测试工作方式的，可能是：

页面改了↓测试挂了↓不用马上找测试人员↓AI 尝试修复↓确认业务语义没变↓继续回归

如果这条路最后真的能跑通，那么未来 UI 自动化的重点可能也会慢慢发生变化。

测试人员不用天天跟 Locator 较劲。

而是把时间放在：

到底测什么。

什么结果才算正确。

哪些场景绝对不能出问题。

AI 自动修复以后，到底有没有把测试修歪。

这可能才是 AI 真正进入自动化测试以后，更值得关注的变化。

下一步我准备实际把 Passmark 跑起来。

不用特别复杂的系统。

就拿一个普通商城，做一个：

登录 → 搜索商品 → 加购物车 → 验证结果

先跑第一次，让 AI 建立 Cache。

然后故意修改页面元素。

再跑第二次。

看看它所谓的 Self-Healing 到底能不能真的把自动化救回来。

如果最后只是 Demo 看着漂亮，那也没什么不好。

至少我们能知道：

AI 自动化到底走到哪一步了。

这里有一点我建议你保留：不要把 Self-Healing 写成“页面怎么变都不用维护”。Passmark 官方实际机制是成功步骤缓存在 Redis 中，后续优先走缓存；缓存步骤失效时才回退到 AI 重新解析并更新缓存。缓存目前也有适用范围，并不是所有复杂多步骤 Flow 都能无条件缓存。

另外它的多模型 Assertion 目前确实是 Claude + Gemini 并行判断，意见不一致时可以调用第三个模型裁决，或者配置为直接失败；Video Assertion 则是录制完整步骤后交给 Gemini 判断瞬时 UI。

Passmark GitHub 项目https://github.com/bug0inc/passmark?utm\_source=chatgpt.com