利用 AI 进行 UI 测试目前有什么好用的方案吗

[layxy]

目前在调研利用 AI 进行 UI 测试,包括 WEB,原生 APP 等,有没有 V 友实践过目前的 AI UI 测试效果怎么样

[Ketteiron]

只在 web 端实践过，效果还行
https://github.com/executeautomation/mcp-playwright
或者用 playwright 写也是一样的，反正是 AI 写

[assilzm]

用 midsence （ https://midscenejs.com/），加上 UI-TARS ，模型用 Doubao-1.5-thinking-vision-pro ，所有端都能适配。就是当前思考时间会比较长。

[TimePPT]

@Ketteiron 这个和 MS 家官方的 [Playwright MCP]( https://github.com/microsoft/playwright-mcp) 哪个更好用呢？

[op351]

@Ketteiron 实践的时候调用的哪个模型？

[ddter]

https://developer.chrome.com/blog/chrome-devtools-mcp?hl=en

[Ketteiron]

@TimePPT #3 executeautomation 版本是以测试工程师视角开发的 MCP ，与 MS 官方没有关系，提供的工具更多
MS 家的维护更频繁，不局限于测试，有可能在未来完全覆盖当前功能，看自己选择吧

[Ketteiron]

@op351 #4 Claude-4-sonnet 模型影响不大

[TimePPT]

@Ketteiron 👍🏻

[pike0002]

chrome 马上支持 devtool mcp 了，让它来辅助测

[keniusahdu]

@pike0002 已经有了。

但是我理解应该用 AI 写 playwright(或者 cdp ）的代码来完成，这样整个流程才能固化，ai 驱动 mcp 是花架子，demo 演示可以。

[keniusahdu]

@assilzm 这个看着很好玩，但是为啥不写获取页面元素的代码，而是要写自然语言的代码呢？

[Ketteiron]

@keniusahdu #10 我觉得 MCP 方案比写 playwright 好，或者这两个可以一起上。
AI 写 playwright ，复杂的场景下又臭又长肯定是要人工检查且大概率要多次返工，浪费不少时间，这是缺点，其次是相关 UI 重构时，也要跟着一起改。
而 MCP 方案是在编写代码的同时就进行检查，出错后 Agent 可以直接修正掉。
测试本质上是为了测试出错误，而不是为了测试而测试，这是不少人推崇 MCP 测试替代传统测试的观点。

做个对比，MCP 方案代码更少，毕竟那一坨 playwright 都砍掉了，合 pr 也更轻松，还可以把 MCP 加进 CI/CD ，每次调用 MCP 都会生成不一样的代码，可以测出更多边界情况。
playwright 方案代码多，重构要修改两处代码，review 更困难，优点是流程固化。
我更倾向于 MCP ，开发团队瓶颈可能在于人工合并代码，AI 合并代码不靠谱，可以提升不少效率。
最稳妥的方案是两个一起上，但我们碰上了如上所述合并代码效率低于提交效率的问题，最终只上了 MCP 。

[keniusahdu]

@Ketteiron #12 可能我的理解很浅，目前我理解 MCP 还是 AI 来驱动任务的完成，如果每一步动作都去调动 AI ，不确定性是很大的问题（可能从你的观点来说不确定性也是 case 的多样性）。看到 midscene 这个方案是很有意思的。每一步动作基于 AI ，如果 AI 的结果是我期望确定性的。可以 cache 起来。全流程 cache 之后可以不依赖 AI 。如果需要改动只针对局部没有命中 cache 的部分重新调动 AI 。可能这就是你说的“两个可以一起上” 目前 midscene 的问题可能是依赖视觉模型，如果用上 cdp 会大大降低门槛。

[Ketteiron]

@keniusahdu #13 midscene 那个 cache 只是降低了思考时间。
midscene 方案目前对于多端 UI 测试看起来还行，如果是纯浏览器，暂时还无法替代 playwright-mcp 、browser-use 、chrome-devtools-mcp 之类的，它需要先解决动态元素识别不准确、滚动查找元素等等问题。
不确定性是目前所有 AI 工具/方案共同的缺点，也在等一个更好的办法。