目前在测试部的各个测试人员都开始使用 MCP 了,部门也有了自己的测试 MCP Server,主要集中在常规流程自动化,常用业务信息查询,各种 JIRA 任务查询,日常工作相关查询。
之前我提了自定义脚本 MCP+playwright MCP 合作方式的想法,目前也应用于当前的测试工作中,效果还行。
下一步呢,想通过 MCP 实现 BUG 自动回归,其实这个可实现性很高:
1、本身 BUG 规范情况下,会有完整的操作步骤,实际问题,期望结果:这个借助 playwright MCP+ 大模型是可以自动化执行的;而实际问题,期望结果也可以进行对应元素比对
2、如果 BUG 有截图,有条件公司的大模型可以读图获取 BUG 框选处情况,能更加精确的判断原 BUG 问题及现在是否修复
3、【前期尝试】可以主动在添加 BUG 时,判断此 BUG 是否可以借助 AI 回归,那就可以进行打标或者标题中有特殊字符。
4、我们使用 JIRA 管理 bug,可以在标题中加入 [AI 回归],在自定义 MCP 中使用过滤器查询出这些待回归的 BUG 的标题、描述;然后规划好任务,让 playwright mcp+ 大模型去一一验证是否回归通过。
5、另外,可以借助 MCP Prompts,直接将整个任务过程编辑为重复使用的 Prompt,可以直接使用
你这比训练一个大模型都难,,,,,,,
这里没有要求 AI 回归具备通用性,而且可以在提交 BUG 时,判断是否 AI 回归,打上标志即可:
很好奇最终做出来会是什么效果 可以的话建议开源分享一波
当个 kpi 还行
期待最后的效果
1,写 BUG 的时候会提页面链接正常,但是你会提某个元素 XPTH 路径么?
2,很多时候这种页面的 BUG 的元素里面的值我自己都不知道他应该是什么,比如一个酒店或者景点的封面图,他就是一个图的链接,我也是要调外部接口才知道值是什么,但是我人眼看得出来这个图不属于这个酒店或者景点 AI 怎么判断呢
3,大模型怎么理解你的操作步骤和预期结果,因为这里面有你具体的业务知识,给他配一个知识库么?
哎,登录态,用户影响回归,纯 web 端,配置复杂一下就麻烦,关键 mcp 也是通过指令去驱动想想就不想搞就只能当玩具
可以具体分享一下现有的么?
画蛇添足,回归 bug 才占多少工作量
额...我觉得空闲时间多的话可以玩一下
我这里提一个很普遍且很简单的场景,一个非常经典、简单的小 BUG,应该符合楼主打标的标准
bug 背景:
如何解决接下来的这些麻烦:
1“进入注册页”
这个注册页如果需要先登录才能访问?AI 如何获取有效的测试账号和密码?是要在 bug 单里写上测试帐号和密码?还是在配置文件里加上通用的测试帐号和密码?
出于安全合规的要求,测试账号都需要区分环境(开发 / 测试 / 预发)、定期轮换密码、处理账号状态(被锁 / 过期 / 权限变更),每次账号变动都要人工同步更新 AI 配置吗?
若进入注册页有其他事件的弹窗干扰,怎么处理?
2” 找到用户名输入框 “
3” 断言 “
【“前端未有长度提示限制、无截断操作、能发起提交” 这一描述对人类清晰,但对 AI 是模糊的】
-【前端未有长度提示限制】提示是文本(如 "最多 20 字符")还是图标?出现在输入框上方还是下方?是否有特定 role="alert"属性?这些细节若不在 BUG 描述中写明,AI 会陷入猜测;若要写清,本质是让测试人员提前完成 "断言设计",AI 沦为执行工具,却额外支付了 AI 调用成本
【无截断操作】AI 在输入 21 个字符后,是否需要执行 await input.value() 来获取输入框的值,并断言其长度等于 21?,截断逻辑是 "输入时实时截断" 还是"失焦后截断” 这些都要在 bug 单上写明吗?
如果提示有了,但是截断逻辑没有修复,填写了 21 个字符后产生报错提示。AI 是否能验证提交? 检查提交按钮的 disabled 属性是否为 false?还是让 AI 真正点击提交按钮,然后判断是否发出请求?
我让 AI 生成可以让 AI 回归更快捷的 bug 单,它给出以下回复
https://test.testerhome.com/addUser
){TEST_ACCOUNT}
,密码:{TEST_PWD}
,从环境变量读取)//button[text()='同意并继续']
(定位器固定)步骤编号 | 操作类型 | 具体指令(含定位器/参数) | 执行约束条件 |
---|---|---|---|
1 | 页面访问 | 打开 URL:https://test.testerhome.com/addUser ,等待页面加载完成(判断标准://form[@id='register-form'] 可见) |
超时时间:10 秒,失败则标记 “环境异常” |
2 | 元素定位 | 定位用户名输入框:page.getByLabel('用户名', {exact: true}) (备选定位器://input[@name='username'] ) |
若主定位器失败,自动尝试备选 |
3 | 输入操作 | 向输入框输入固定字符串:"testuser1234567890abcdef" (共 25 字符,纯英文无特殊符号) |
输入速度:每字符间隔 50ms,模拟人工输入 |
4 | 提交操作 | 定位提交按钮://button[@type='submit' and text()='注册'] ,执行点击操作 |
点击前确认按钮disabled 属性为false
|
//div[@class='error-hint' and @for='username']
)value
属性blur()
操作,再断言值长度/api/register
)username
字段长度必须≤20(后端截断场景)username
长度=25 → 判定 BUG 未修复//div[@id='error-page']
可见):视为后端报错,判定 BUG 未修复就如果按 AI 这个写法,一个三四分钟就能回归的简单 bug,足足在 bug 单上就耗时至少 20 分钟
最后业务测试做多的人都会知道,bug 回归的核心是 “验证动态变化的功能”,就是 UI 可能改、逻辑可能调、异常场景可能新增
毕竟是面向人的验证工作,当然我不是找茬,只是感觉想用 AI 去做回归,真心有点难
统一回复一下,目前有这个想法,是使用了一段时间 browser Use 和 CC+Playwright MCP。
browser Use 他能将你的语义步骤(无需提供 xpath 及 css locator)转换为自动化,虽然成功率视流程及页面元素影响,但针对页面很明确(直接访问到 URL),找到指定元素是可以的。
CC+Playwright MCP:目前在 prompts 调教好的情况,能将你的任务自动拆分执行计划,目前已经在一些业务测试验收:比如自动访问搜索页面,输入关键词或自然语义进行搜索,并将搜索到的商品名称、价格、特殊属性进行获取,并和输入关键词或自然语义通过大模型进行匹配度校验并给出结果报告。那同样针对一些流程简单、异常元素定位明确的 BUG,可以去尝试自动化校验。但这个能否自动执行需要看选择的模型,有的模型会自动,有的每个步骤都需要你去确认。
个人推荐思路,如果想要通畅,可以 MCP+Browser Use,Browser Use 也提供了 MCP 接入,可以考虑整合起来。
上面有小伙伴问是否需要提供定位(xpath),browser Use、【Playwright MCP+ 大模型】目前都是可以语义定位(比如登录名输入框,你直接说 “登录名输入框” 即可;页面中的回复信息的第 1 条,直接这么说即可”),当然你的语义定位要精确些,比如这里
另外,这里只是针对 BUG 回归,回归当前你提出问题本身:期望与实际是否一致,没有要求其发散更多,也没要求去联系业务,这种交给自己去做;
在一个新的、较紧急业务开发中,业务信息不对、不完整类的 BUG 其实占比还是比较多的,这些应该比较合适使用 AI 回归。
回归 bug 占用时间问题,得看 BUG 多不多,什么时候回归。如果任务紧,bug 回归作为最后的系统回归的一部分时,面对堆积的 BUG,可以省去一些时间。
当然,这个也是我使用 CC+Playwright MCP+BrowserUse 应用于 AI 验证搜索结果项目中,产生的可以认为是 KPI 想法;也简单验证了一个 “某某页面,用户审核状态有误,应该是 xx,实际是 yy” 的 BUG demo。
提出来,也是希望抛砖引玉、集思广益。
感谢所有回复的同学
支持下楼主,在技术领域,先不要看效果,看成本,先探索。最早 appium 刚刚出来的时候也是各种被挑战,现在俨然已经是移动端的测试框架排列前茅的了。
👍,期待博主的持续更新
我觉得通过 AI 来完成一些事情后,怎么判断它做的对不对比较关键,比如你这个落地之后,我怎么保证这个被回归的 bug 是真的修复了?
支持一下。只要做的东西,能确实解决楼主工作部分问题,且有精力做,那就可以先去做,任何东西没有一做就是完美的,碰到问题后面慢慢优化,由点及面,说不定也是一大测试利器 。
不方便给完整的,思路是使用 MCP Client 传递 BUG 步骤及问题定位的元素,去调用 Browser User 的包装的 MCP Server,然后将获取的对应 BUG 中元素的当前的值,再交给到模型比对是否和预期一致。
目前只是提出了一些思路和不完善的设计。做出一些小的 demo 也仅限于那种步骤简单明确,问题元素也很容易定位那种,而且大模型的 token 数消耗蛮大的。
验证了一些可行性,至少是这些挑选过的 BUG
这个本地部署吧 不然接口安全好像没办法保证
我想问一下,谁对 AI 回归的 bug 进行负责,也就是回归结果谬误,导致 BUG 遗漏到线上后,谁负责。