目前在调研利用 AI 进行 UI 测试,包括 WEB,原生 APP 等,有没有 V 友实践过目前的 AI UI 测试效果怎么样
 |
1
Ketteiron 24 天前  1
|
 |
2
assilzm 24 天前 2
用 midsence （ https://midscenejs.com/），加上 UI-TARS ，模型用 Doubao-1.5-thinking-vision-pro ，所有端都能适配。就是当前思考时间会比较长。
|
 |
3
TimePPT PRO @Ketteiron 这个和 MS 家官方的 [Playwright MCP]( https://github.com/microsoft/playwright-mcp) 哪个更好用呢？
|
|
6
Ketteiron 24 天前 1
@TimePPT #3 executeautomation 版本是以测试工程师视角开发的 MCP ，与 MS 官方没有关系，提供的工具更多
MS 家的维护更频繁，不局限于测试，有可能在未来完全覆盖当前功能，看自己选择吧 |
 |
9
pike0002 24 天前
chrome 马上支持 devtool mcp 了，让它来辅助测
|
 |
10
keniusahdu 23 天前
|
|
11
keniusahdu 23 天前
@assilzm 这个看着很好玩，但是为啥不写获取页面元素的代码，而是要写自然语言的代码呢？
|
|
12
Ketteiron 23 天前 1
@keniusahdu #10 我觉得 MCP 方案比写 playwright 好，或者这两个可以一起上。
AI 写 playwright ，复杂的场景下又臭又长肯定是要人工检查且大概率要多次返工，浪费不少时间，这是缺点，其次是相关 UI 重构时，也要跟着一起改。 而 MCP 方案是在编写代码的同时就进行检查，出错后 Agent 可以直接修正掉。 测试本质上是为了测试出错误，而不是为了测试而测试，这是不少人推崇 MCP 测试替代传统测试的观点。 做个对比，MCP 方案代码更少，毕竟那一坨 playwright 都砍掉了，合 pr 也更轻松，还可以把 MCP 加进 CI/CD ，每次调用 MCP 都会生成不一样的代码，可以测出更多边界情况。 playwright 方案代码多，重构要修改两处代码，review 更困难，优点是流程固化。 我更倾向于 MCP ，开发团队瓶颈可能在于人工合并代码，AI 合并代码不靠谱，可以提升不少效率。 最稳妥的方案是两个一起上，但我们碰上了如上所述合并代码效率低于提交效率的问题，最终只上了 MCP 。 |
|
13
keniusahdu 23 天前
@Ketteiron #12 可能我的理解很浅，目前我理解 MCP 还是 AI 来驱动任务的完成，如果每一步动作都去调动 AI ，不确定性是很大的问题（可能从你的观点来说不确定性也是 case 的多样性）。看到 midscene 这个方案是很有意思的。每一步动作基于 AI ，如果 AI 的结果是我期望确定性的。可以 cache 起来。全流程 cache 之后可以不依赖 AI 。如果需要改动只针对局部没有命中 cache 的部分重新调动 AI 。可能这就是你说的“两个可以一起上” 目前 midscene 的问题可能是依赖视觉模型，如果用上 cdp 会大大降低门槛。
|
|
14
Ketteiron 23 天前
@keniusahdu #13 midscene 那个 cache 只是降低了思考时间。
midscene 方案目前对于多端 UI 测试看起来还行，如果是纯浏览器，暂时还无法替代 playwright-mcp 、browser-use 、chrome-devtools-mcp 之类的，它需要先解决动态元素识别不准确、滚动查找元素等等问题。 不确定性是目前所有 AI 工具/方案共同的缺点，也在等一个更好的办法。 |
|
15
keniusahdu 18 天前
@Ketteiron #14 今天试用了一下，midscene 确实在 cache 之后还是有 AI 依赖。你说的很对。
|
 |
16
kevan 2 天前
测试了 MIDSCENE/ANDROID 和 UI-TARS-DESKTOP ，主要都是依赖 AI 思考，比传统的 RPA 工具优势就是不用考虑每个步骤细节，例如，遇到的某些 UI 提示操作：确定、发布、发送、取消、在哪、语义表达等无需考虑，AI 会根据提示词设定目标进行逻辑性操作；缺点就是运行效率无法提升，视觉成本过高，每个步骤都需要截图请求模型分析。未来可期
|
Select Language