AI测试 AI 驱动的 UI 自动化测试:国产龙虾 workbuddy 网页识别效果不理想,大神们有啥好的方法吗?

子夜 · 2026年04月29日 · 最后由 软件测试开发阿森 回复于 2026年05月08日 · 6320 次阅读

各位大神,
目前我在使用国产龙虾 workbuddy 做我们系统的 UI 自动化测试,但目前效果不理想,对网页的识别不是很好。
提示词:
你是一位资深测试工程师,根据此上传需求文档(文档中对字段值要求的详细描述),运用各种测试方法,生成针对页面字段测试的测试用例,根据生成的测试用例对 XX 流程发起页面所有的字段进行测试,重要步骤和缺陷都需要截图,请按以下操作步骤进入流程发起页面 1、浏览器访问http://11.9.67.99:8888/XXX 2、输入用户名:张三, 密码:123456, 点击登录,登录成功 2、左侧导航栏,点击【办公】,在办公页面的搜索框中输入流程名称,在搜索结果列表中选择流程,打开流程发起列表页面 3、页面右上角,点击【新建】按钮,浏览器打开新页签,此页签为流程的发起页面,以上所有测试执行完成后,生成一份详细的测试报告

发现的问题:我发现通过上面的提示词执行完后,测试报告是生成了,报告中生成的字段的用例都是通过的状态,我实际去看这是一个伪报告,AI 没有去真正识别页面的元素,导致 AI 没有测试执行就生成报告了。

各位大神,想确认两个问题:
1、大家在做 UI 自动化测试的时候,对于 AI 对网页识别效果不好,有什么心得体会,都会用什么 skill 提升识别的准确度
2、对于这种自动化的全流程测试,需求分析 - 测试用例自动生成 - 用例自动执行 - 生成测试报告,有什么成功的经验分享吗?

非常感谢,各位大神。

共收到 16 条回复 时间 点赞

我没用 workbuddy, 我是用的 midsence, 基于多模态大模型的 UI 自动化识别方案。 底层用的 playwright,而 playwright 用 CDP 跟浏览器交互,目前用下来,稳定性还挺不错的。 多模态大模型通过截图来找到控件的坐标, 然后通过控件坐标,与 playwright 交互找到真正的控件对象。 然后通过 palywright 调用 cdp 操作浏览器。

整套东西用下来, AI 定位控件的正确率还是很高的,我用的是千问的多模态模型。 而 midsence 仍然是用 playwright 的,所以即便 AI 定位失败了, 我们还可以回退到传统的 css 定位。

孙高飞 回复

用这个是不是得需要写脚本吧?类似于这样:
import { Midscene } from '@midscene/web';

async function test() {
const agent = await Midscene.create();
await agent.goto('https://example.com');
await agent.exec('点击登录按钮');
await agent.exec('输入账号: test@xxx.com');
await agent.exec('断言页面包含 "欢迎回来"');
}
其实我是想实现一个全流程的从需求分析 - 生成用例 - 执行用例 - 生成报告,只写提示词,他就能执行自动运转那种模式。有啥建议没?

仅楼主可见
子夜 回复

是需要写脚本, 只不过我都是让 AI 写:

试试用 Playwright-mcp

孙高飞 回复

那请问大佬 访问的网站有 Cloudflare Turnstile 在拦自动化环境,全自动化的话这种的怎么搞

孙高飞 回复

你可以试试 browser-use, 我们就是基于 browser-use 封装的。当然不嫌弃也可以直接用我们软件试试。

你这个提示词太简单了

回复

有专门的 api

子夜 #10 · 2026年04月30日 Author
roclv 回复

大神,您那边有没有实践成功的提示词案例和体系?

我们目前也是在尝试使用 AI 去做 UI 自动化测试,使用的是 claude+skill,输入需求、设计、开发文档让它分析业务流程->生成测试用例->使用 playright+CDP 编写自动化脚本并执行->生成报告,整体流程是能走通,但是主要问题还是业务分析不够深入,只能针对页面的表单之类的做一些简单的增删改查,涉及到业务关联的就分析不出来了,不知道该如何继续深入分析

roclv 回复

browser-use 配合 autogen 吗?

子夜 #13 · 2026年04月30日 Author
wt 回复

确实,AI 目前对于复杂场景的分析还是存在一定的瓶颈

hermes-agent 内置了 TDD 的 skills,可以尝试一下

dogdogaaa 回复

没有用过 autogen,貌似不需要吧。

在大模型时代,UI 自动化测试,不能太偏重代码实现了,重代码实现,对后期的灵活性就会差(页面变动,代码也要调整,不然会报错),其实就应该轻量化,但是有不能让大模型太发散,太发散了,稳定性就会变差, 我更倾向于,思考和决策,反馈,修正等都适合用模型去干,对于底层的点击什么元素,进行什么操作,输入什么值等确定下的事情,一定要有一个可靠性的框架来驱动去干,分工合作。

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