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

flyfisher · January 12, 2026 · Last by flyfisher replied at January 27, 2026 · 6388 hits

据说 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 关键字汉化&优化 中提及了此贴 13 Jan 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。

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up