自动化工具 部分自动化测试可被 AI 取代了-playwright mcp 体验

flyfisher · 2026年01月12日 · 最后由 flyfisher 回复于 2026年01月27日 · 11670 次阅读

据说 AI 能够自动生成测试代码,自动识别页面元素位置了,用自然语言就能开展 UI 测试,于是体验一番。

playwright mcp 介绍

在传统的 UI 自动化测试中,测试人员需要编写大量脚本和选择器来模拟用户操作。然而,随着人工智能技术的快速发展,对话式自动化正在改变这一格局。

Playwright 作为微软开源的现代化 Web 自动化工具,与 MCP(Model Context Protocol)协议的结合,为我们提供了一种全新的自动化测试体验。这种组合允许我们通过自然语言指令来控制浏览器,大大降低了自动化测试的技术门槛,同时提高了脚本编写的效率。

一、Playwright 与 MCP:完美结合
1.1 Playwright 的核心优势
Playwright 是一个强大的端到端测试框架,具有以下突出特点:

跨浏览器支持:原生支持 Chromium(Chrome/Edge)、Firefox 和 WebKit(Safari)三大浏览器引擎
智能等待机制:自动检测元素可交互状态,减少因网络延迟导致的测试失败
多语言支持:提供 JavaScript/TypeScript、Python、.NET 和 Java 等多种语言 API
移动端模拟:内置设备描述符,可真实模拟移动设备环境
录制功能:通过 playwright codegen 命令可录制操作并生成脚本

1.2 MCP 协议的作用
MCP(Model Context Protocol)定义了大型语言模型(LLM)与外部服务交互的规范。它的价值在于:

统一交互标准:让 LLM 能够与浏览器、数据库等外部工具无缝对话
动态流程控制:根据实时反馈调整指令,使自动化流程更加灵活
安全机制:权限分层设计,防止越权操作敏感资源

1.3 结合后的协同效应
当 Playwright 与 MCP 结合时,创建了对话式自动化的新范式:

自然语言驱动:用简单指令替代复杂脚本编写
实时交互调试:每一步操作都可即时验证和调整
降低技术门槛:非技术人员也能参与自动化流程创建

操作指导

根据这个帖子体验了一把 AI 自然语言自动化测试,确实能做到自然语言测试了,无需编程。能够理解自然语言,转换为代码,还能自动获取元素位置。
https://blog.csdn.net/ljyfree/article/details/147462992

实测效果

输入自然语言:
使用playwright mcp server执行以下指令:打开浏览器,前往https://testerhome.com/ ,点击注册按钮,然后输入用户名123456,截图并保存。

自动执行:打开测试者之家

自动执行:点击注册按钮

使用成本

对大模型 token 的消耗量挺大的,用了 7 次就消耗 22 万 token 了,平均一次 3.2 万 token,没玩几下就把我的免费 token 额度耗尽了。

按下面这个大模型 token 价格估算,3 元可以调用 30 次,成本还挺高的。假设有 100 个 UI 用例,每个用例 30 个测试步骤,一次执行完要 300 元 token 费用,一天执行一轮 UI 回归测试,一个月 9000 元。每次下发自然语言指令都要花钱,跑几次全量回归测试,钱包都空了,还要继续降低 AI 使用成本才行。

结论

短期对自动化测试开发影响不大,因为使用成本挺高的;长期看,随着 AI 使用成本下降,自动化测试开发可能会失业,不需要这么多编程人员了。

共收到 15 条回复 时间 点赞

你的结论同样适用于前端开发、后端开发,都可以由 AI 直接生成代码。甚至于微信小程序,通过 AI 自动化生成干掉了数不清的专职微信小程序的开发者。

是的,传统开发很危险,有固定模式的编程都面临 AI 替代冲击

还好我只会点点点😎

对 难道 回复

估计失业得更快😅 AI 根据需求文档生成自然语言用例更容易做到

flyfisher 在 Robot Framework 关键字汉化&优化 中提及了此贴 01月13日 23:46

最新消息,昨天测试 MCP 的 token 消耗数据不是最新的,账单数据同步延迟一个小时左右,今天看到账单,居然欠费了!随便玩一下,就欠费了,钱包在痛。

不知道实际应用怎么样,我们的系统比较老旧,两三层层 iframe 嵌套都是常态化,这种感觉识别效果应该很差劲

对模型要求不高的话,国内版 trae 可以直接用 MCP,暂时没看到付费的地方,要求高的话就付费换 cursor 了。

AI 自动化本身不仅是消耗,还是时间成本变高,在执行 AI 时生成本地数据,下次走本地数据,本地数据失败后走 AI 会划算些

对 flyfisher 回复

测试执行比较明确,对错也好判断,现阶段无非就是贵和耗时 (除了模型本身速度,还需要考虑错了重试的消耗)。
用例生成这种看起来简单的,生成出来的效果反倒是最差的。
特别是迭代到中后期的业务还要涉及到之前的相关文档,压缩也无法明确哪些和本次有关系,会不会被压没了

对 ZYH 回复

是的,提前生成好脚本,固定下来执行,找不到元素时再出发 AI 自愈。

对 zzx 回复

还没试过 iframe,我觉得写个指令切换过去就行了,难度不大

对 难道 回复

哈哈,我是真的只会点点点,但是也知道自己年龄大了,在这行已经没有出路了,所以也没想的卷,在目前的公司能干到什么时候就干到什么时候

对 flyfisher 回复

点点点应该是最不会被替代的,总需要有纯人工验证 AI 是否靠谱

使用 AI 的人必须要对相关的技术非常熟悉,AI 只是加速了你手写代码实现和部署这些的过程,并不能完全替代你的架构设计,它只能快速填空,做不到完整的架构能力。

对 甬力君 回复

初级自动化开发人员会被加速淘汰,资深自动化测试专家的价值会被 AI 放大。有了 AI,测试专家就能操纵一堆 AI 工具人开展测试活动了,初级测试人员会被挤出。就是原来一个业务单元需要投入一个测试专家和 10 个初级测试,可能会变成一个专家搭配 1 个初级测试和 9 个 AI。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册。