从“写脚本跑自动化”到“丢设计稿自动探索”我们换了个玩法大家好我是某互联网大厂质量效能团队的测试架构师负责移动端UI自动化测试体系建设。今天聊一个我们最近做成的实验——把UI设计稿直接丢给多模态大模型让它自己完成对整个App的探索式测试。先上结果系统上线三个月覆盖了200个页面、3000个交互元素发现了47个传统自动化脚本漏掉的功能性Bug其中9个是P1级。整个过程零脚本、零用例编写。不是标题党。下面我把整个方案从头到尾拆一遍。一、UI自动化测试的“死循环”做移动端UI自动化的人都经历过这个死循环写脚本 → UI改版 → 脚本挂 → 修脚本 → UI又改版 → 脚本又挂我们团队之前维护着一套基于Appium的自动化回归脚本300多条用例每版本光修脚本就要花2-3人天。更坑的是——脚本只能验证“写死”的路径页面里多了个新按钮、弹了个意外弹窗脚本完全不知道该怎么办。探索式测试呢靠人工。测试同学拿着手机到处点凭经验找Bug。效率低、覆盖率看运气、没法规模化。我们一直在想一个问题能不能让AI像人一样“看”着屏幕做探索式测试直到多模态大模型的出现这个想法才有了落地的可能性。二、技术方案三层架构我们的系统叫VisionTest内部代号核心逻辑很简单——把UI设计稿当作“地图”让AI自己探索、自己判断。架构分成三层第一层视觉理解层—— 多模态模型看懂UI稿和实际截图第二层自主探索层—— AI Agent决策“下一步点哪里”第三层智能断言层—— AI判断“这个结果对不对”三、核心能力拆解能力一从UI稿里“读懂”要测什么这是整个方案的起点。我们把产品的Figma设计稿导出成高清截图直接喂给多模态模型我们用的是内部部署的Qwen-VL和GPT-4V的组合方案。模型要做三件事第一识别所有可交互元素。按钮、输入框、开关、滑动条、Tab切换——模型像人眼看设计稿一样把页面上所有“能点能滑”的东西都标出来。第二理解元素的功能语义。光知道“这里有个按钮”不够模型还要理解“这个按钮是干什么的”——“提交订单”“返回首页”“展开更多”——这些语义信息决定了后续探索的优先级和预期结果的判断依据。第三建立页面之间的跳转关系。设计稿里通常包含多个页面模型要识别出“点这个按钮会跳到哪个页面”形成一张页面关系图。这一步听起来简单但实际做起来有很多细节。比如设计稿里的“交互说明”注释“点击后弹出浮层”“长按显示菜单”这些信息在纯截图里是看不到的。我们的做法是把Figma的标注信息一起导出来作为额外的文本输入喂给模型。效果一个中等复杂度的页面20-30个交互元素AI解析耗时不到10秒准确率约92%。人工标注一个页面大概需要15-20分钟。能力二自主探索——像人一样“到处点”有了“地图”接下来就是“探索”。我们的AI Agent采用了一种基于好奇心的探索策略参考了美团KuiTest和VLM-Fuzz的思路第一步从首页开始。AI截取当前屏幕多模态模型分析页面列出所有可交互元素。第二步决定点哪个。AI不是随机乱点而是有策略地选择优先点没去过的元素覆盖率优先优先点语义重要的元素“提交订单”比“返回”优先级高如果某个元素点了之后页面没变化标记为“疑似异常”第三步执行点击并观察结果。AI通过ADB或XCTest执行点击操作然后再次截图让多模态模型判断页面有没有变化跳转了弹窗了还是没反应变化是否符合预期点了“提交订单”应该跳转到支付页而不是报错有没有出现异常白屏、崩溃、错误弹窗第四步记录并继续。把这次探索的结果记录下来哪个页面、点了什么元素、跳转到了哪里、有没有异常然后选择下一个元素继续探索。关键设计探索深度和广度的平衡如果AI无限制地探索下去一个App可能有成百上千个页面状态组合永远跑不完。我们的解决方案是两层探索广度优先先把所有页面都“逛”一遍每个页面只点2-3个核心元素快速建立全貌深度优先对重点页面支付、登录、核心业务流做深度探索穷尽所有交互元素同时设置探索上限——每个页面最多探索15个交互元素整个探索过程最多30分钟。超时自动停止并生成报告。真实案例有一次AI在探索“个人中心”页面时点了一个不起眼的“会员等级”入口跳转到了一个从未被任何测试用例覆盖过的页面——会员权益详情页。AI在这个页面上发现了一个Bug点击“立即续费”按钮后页面白屏。这个Bug如果靠人工探索大概率会被漏掉因为那个入口藏得太深了。能力三智能断言——AI自己判断“对不对”传统自动化测试最难的部分是断言——你得提前写死“预期结果是什么”。但探索式测试的难点就在于——你事先不知道会探索到什么怎么判断对不对我们的方案是让多模态模型自己判断“这个结果合不合理”。具体来说AI每执行一个操作后会问自己三个问题1. 页面状态是否正常——有没有白屏、崩溃、无限加载、乱码2. 操作是否有反馈——点击按钮后页面有没有变化如果点了半天没反应那就是问题。3. 跳转是否合理——点了“去支付”却跳到了“首页”这显然不合理。模型会根据设计稿和常识来判断跳转是否符合预期。最 tricky 的部分有些“异常”其实是正常的产品设计——比如点了“返回”弹出一个“确定要离开吗”的确认框。怎么区分“正常弹窗”和“异常弹窗”我们的解法是两层判断第一层规则兜底预置了一些硬规则——崩溃、白屏、ANR直接判失败第二层AI判断其他情况交给多模态模型根据UI稿和页面语义做综合判断初期误报率很高~40%后来我们加入了置信度阈值——AI判断置信度低于0.8的不直接判失败而是标记为“需人工复核”。同时用历史数据持续微调Prompt现在误报率降到了12%左右。四、踩过的坑说三个最痛的坑一设计稿和真实App的“买家秀”差距太大UI稿是完美的——字体、间距、颜色都整整齐齐。但真实App在不同设备、不同系统版本上渲染效果千差万别。AI在UI稿上识别出的元素在真机截图上可能位置偏移、样式变化、甚至直接消失。解法我们放弃了“像素级对比”的思路改用语义级匹配——不管按钮长什么样、在什么位置只要文字和功能语义一致就认为是同一个元素。这需要模型有很强的泛化能力而不是死记硬背UI稿的像素布局。坑二AI“迷路”了——在页面循环里出不來有些App的页面设计存在循环跳转——A页面点按钮到B页面B页面点按钮又回到A页面。AI如果没有记忆机制会一直在几个页面之间“打转”浪费大量时间。解法给AI加了一个访问历史记录。每次进入一个新页面先检查这个页面之前是否来过。如果来过就优先探索没去过的元素如果所有元素都去过了就“撤退”到上一个页面继续探索。坑三AI的“幻觉”问题多模态模型有时候会“脑补”一些不存在的元素。比如设计稿里明明没有“分享”按钮模型愣是说“这里有个分享按钮”。解法引入交叉验证机制——不光靠多模态模型看截图同时用UI Hierarchy视图树做二次验证。模型说“这里有按钮”我们去视图树里查一下如果确实有可点击的View就采信如果没有就标记为“疑似幻觉”并跳过。这个方案让元素识别的准确率从78%提升到了94%。五、效果数据说几个硬数据截止目前运行了三个月指标数据覆盖页面数200覆盖交互元素3000单次探索耗时15-30分钟全自动发现Bug总数47个其中P1级Bug9个传统脚本漏测的Bug47个全部AI误报率~12%人工复核耗时每版本约1小时最让我意外的一点47个Bug里没有一个是崩溃类的——全都是功能性异常跳转错误、状态不同步、数据展示不对。这类Bug恰恰是传统自动化脚本最难覆盖的因为脚本只会验证“写死”的路径而AI会到处乱点反而更容易撞上这些“隐蔽”的问题。有一次AI在探索“优惠券领取”流程时发现了一个很有意思的Bug——在某种特定操作顺序下先领一张券→返回→再进入→再领一张第二张券的领取按钮会变成灰色但没有任何提示。用户以为不能领了但其实后台是可以领的。这个Bug如果靠人工测试需要非常凑巧的操作顺序才能触发。AI在探索过程中随机撞到了这个路径直接报告了。测试团队的反应一开始大家觉得“AI到处乱点能测出什么”现在变成“每次跑完先看AI的报告再决定要不要人工补充测。”六、和传统方案的对比维度传统脚本自动化人工探索式测试VisionTestAI探索用例编写2-3人天/版本不需要不需要脚本维护高UI一变就挂不适用零维护覆盖率固定路径依赖经验全量遍历发现未知Bug的能力弱强强执行速度快慢中等15-30分钟误报率低低中等需人工复核可规模化难脚本膨胀难人力有限易加设备就行VisionTest不是要取代人工探索式测试而是把“重复性的基础探索”自动化了。测试同学现在可以把精力放在复杂业务流的深度测试上而不是花大量时间到处乱点找Bug。七、给同行的一些建议如果你也想尝试这个方向我有几点掏心窝的话1. 从“设计稿解析”开始别一上来就搞全量探索我们第一个月只做了一个功能——解析UI稿生成页面地图。这一步跑通了再逐步加上“自主探索”和“智能断言”。分阶段推进每阶段都有可交付的成果团队才有信心继续往下做。2. 选对模型比选“大”模型重要我们试过好几个多模态模型——GPT-4V、Qwen-VL、Gemini、UI-TARS。发现专门针对UI场景优化过的模型比如UI-TARS、CogAgent在元素识别准确率上明显优于通用模型。不是参数越大越好是越“懂UI”越好。3. 接受“AI辅助”的定位别指望“AI替代”AI探索式测试的输出是“疑似问题清单”不是“最终缺陷报告”。每个疑似问题都需要人工复核确认。我们现在的流程是AI跑完→生成报告→测试同学花1小时复核→确认的Bug提交TAPD。千万别让AI自动提交Bug——我们试过后果是开发同学在群里疯狂我“这什么鬼这也能算Bug”4. 先跑“非核心”页面别一上来就让AI去探索支付流程、登录流程这些核心链路——万一AI把生产环境搞出问题来你担不起这个责任。我们最开始只在测试环境的非核心模块个人中心、设置页、帮助中心上跑跑了两周没问题才逐步扩展到核心业务。安全第一效率第二。5. 把“探索结果”可视化AI跑完探索式测试如果只给一份文字报告没人看得进去。我们做了一个页面关系图的可视化工具——每个页面是一个节点每个跳转是一条边有问题的节点标红。产品、开发、测试一看就明白“哦这个页面没覆盖到”“这个跳转有问题”。可视化比任何报告都管用。最后多模态AI做探索式测试本质上是把“人眼看屏幕人脑做判断”这个过程自动化了。技术门槛没有想象中那么高——一个多模态大模型 一套设备控制能力 一个简单的探索策略就能搭出一个可用的原型。但这件事真正有价值的不是“技术有多牛”而是它改变了测试团队的工作方式——从“写脚本验证已知路径”变成了“让AI探索未知路径”。后者发现的Bug往往才是真正影响用户体验的。如果你团队还在被UI自动化脚本的维护成本折磨我建议你认真看看这个方向。把设计稿丢给AI让它自己去探索——这事儿真的能成。
我用多模态AI直接把UI稿丢进去，它自己完成了所有页面的探索式测试
从“写脚本跑自动化”到“丢设计稿自动探索”我们换了个玩法大家好我是某互联网大厂质量效能团队的测试架构师负责移动端UI自动化测试体系建设。今天聊一个我们最近做成的实验——把UI设计稿直接丢给多模态大模型让它自己完成对整个App的探索式测试。先上结果系统上线三个月覆盖了200个页面、3000个交互元素发现了47个传统自动化脚本漏掉的功能性Bug其中9个是P1级。整个过程零脚本、零用例编写。不是标题党。下面我把整个方案从头到尾拆一遍。一、UI自动化测试的“死循环”做移动端UI自动化的人都经历过这个死循环写脚本 → UI改版 → 脚本挂 → 修脚本 → UI又改版 → 脚本又挂我们团队之前维护着一套基于Appium的自动化回归脚本300多条用例每版本光修脚本就要花2-3人天。更坑的是——脚本只能验证“写死”的路径页面里多了个新按钮、弹了个意外弹窗脚本完全不知道该怎么办。探索式测试呢靠人工。测试同学拿着手机到处点凭经验找Bug。效率低、覆盖率看运气、没法规模化。我们一直在想一个问题能不能让AI像人一样“看”着屏幕做探索式测试直到多模态大模型的出现这个想法才有了落地的可能性。二、技术方案三层架构我们的系统叫VisionTest内部代号核心逻辑很简单——把UI设计稿当作“地图”让AI自己探索、自己判断。架构分成三层第一层视觉理解层—— 多模态模型看懂UI稿和实际截图第二层自主探索层—— AI Agent决策“下一步点哪里”第三层智能断言层—— AI判断“这个结果对不对”三、核心能力拆解能力一从UI稿里“读懂”要测什么这是整个方案的起点。我们把产品的Figma设计稿导出成高清截图直接喂给多模态模型我们用的是内部部署的Qwen-VL和GPT-4V的组合方案。模型要做三件事第一识别所有可交互元素。按钮、输入框、开关、滑动条、Tab切换——模型像人眼看设计稿一样把页面上所有“能点能滑”的东西都标出来。第二理解元素的功能语义。光知道“这里有个按钮”不够模型还要理解“这个按钮是干什么的”——“提交订单”“返回首页”“展开更多”——这些语义信息决定了后续探索的优先级和预期结果的判断依据。第三建立页面之间的跳转关系。设计稿里通常包含多个页面模型要识别出“点这个按钮会跳到哪个页面”形成一张页面关系图。这一步听起来简单但实际做起来有很多细节。比如设计稿里的“交互说明”注释“点击后弹出浮层”“长按显示菜单”这些信息在纯截图里是看不到的。我们的做法是把Figma的标注信息一起导出来作为额外的文本输入喂给模型。效果一个中等复杂度的页面20-30个交互元素AI解析耗时不到10秒准确率约92%。人工标注一个页面大概需要15-20分钟。能力二自主探索——像人一样“到处点”有了“地图”接下来就是“探索”。我们的AI Agent采用了一种基于好奇心的探索策略参考了美团KuiTest和VLM-Fuzz的思路第一步从首页开始。AI截取当前屏幕多模态模型分析页面列出所有可交互元素。第二步决定点哪个。AI不是随机乱点而是有策略地选择优先点没去过的元素覆盖率优先优先点语义重要的元素“提交订单”比“返回”优先级高如果某个元素点了之后页面没变化标记为“疑似异常”第三步执行点击并观察结果。AI通过ADB或XCTest执行点击操作然后再次截图让多模态模型判断页面有没有变化跳转了弹窗了还是没反应变化是否符合预期点了“提交订单”应该跳转到支付页而不是报错有没有出现异常白屏、崩溃、错误弹窗第四步记录并继续。把这次探索的结果记录下来哪个页面、点了什么元素、跳转到了哪里、有没有异常然后选择下一个元素继续探索。关键设计探索深度和广度的平衡如果AI无限制地探索下去一个App可能有成百上千个页面状态组合永远跑不完。我们的解决方案是两层探索广度优先先把所有页面都“逛”一遍每个页面只点2-3个核心元素快速建立全貌深度优先对重点页面支付、登录、核心业务流做深度探索穷尽所有交互元素同时设置探索上限——每个页面最多探索15个交互元素整个探索过程最多30分钟。超时自动停止并生成报告。真实案例有一次AI在探索“个人中心”页面时点了一个不起眼的“会员等级”入口跳转到了一个从未被任何测试用例覆盖过的页面——会员权益详情页。AI在这个页面上发现了一个Bug点击“立即续费”按钮后页面白屏。这个Bug如果靠人工探索大概率会被漏掉因为那个入口藏得太深了。能力三智能断言——AI自己判断“对不对”传统自动化测试最难的部分是断言——你得提前写死“预期结果是什么”。但探索式测试的难点就在于——你事先不知道会探索到什么怎么判断对不对我们的方案是让多模态模型自己判断“这个结果合不合理”。具体来说AI每执行一个操作后会问自己三个问题1. 页面状态是否正常——有没有白屏、崩溃、无限加载、乱码2. 操作是否有反馈——点击按钮后页面有没有变化如果点了半天没反应那就是问题。3. 跳转是否合理——点了“去支付”却跳到了“首页”这显然不合理。模型会根据设计稿和常识来判断跳转是否符合预期。最 tricky 的部分有些“异常”其实是正常的产品设计——比如点了“返回”弹出一个“确定要离开吗”的确认框。怎么区分“正常弹窗”和“异常弹窗”我们的解法是两层判断第一层规则兜底预置了一些硬规则——崩溃、白屏、ANR直接判失败第二层AI判断其他情况交给多模态模型根据UI稿和页面语义做综合判断初期误报率很高~40%后来我们加入了置信度阈值——AI判断置信度低于0.8的不直接判失败而是标记为“需人工复核”。同时用历史数据持续微调Prompt现在误报率降到了12%左右。四、踩过的坑说三个最痛的坑一设计稿和真实App的“买家秀”差距太大UI稿是完美的——字体、间距、颜色都整整齐齐。但真实App在不同设备、不同系统版本上渲染效果千差万别。AI在UI稿上识别出的元素在真机截图上可能位置偏移、样式变化、甚至直接消失。解法我们放弃了“像素级对比”的思路改用语义级匹配——不管按钮长什么样、在什么位置只要文字和功能语义一致就认为是同一个元素。这需要模型有很强的泛化能力而不是死记硬背UI稿的像素布局。坑二AI“迷路”了——在页面循环里出不來有些App的页面设计存在循环跳转——A页面点按钮到B页面B页面点按钮又回到A页面。AI如果没有记忆机制会一直在几个页面之间“打转”浪费大量时间。解法给AI加了一个访问历史记录。每次进入一个新页面先检查这个页面之前是否来过。如果来过就优先探索没去过的元素如果所有元素都去过了就“撤退”到上一个页面继续探索。坑三AI的“幻觉”问题多模态模型有时候会“脑补”一些不存在的元素。比如设计稿里明明没有“分享”按钮模型愣是说“这里有个分享按钮”。解法引入交叉验证机制——不光靠多模态模型看截图同时用UI Hierarchy视图树做二次验证。模型说“这里有按钮”我们去视图树里查一下如果确实有可点击的View就采信如果没有就标记为“疑似幻觉”并跳过。这个方案让元素识别的准确率从78%提升到了94%。五、效果数据说几个硬数据截止目前运行了三个月指标数据覆盖页面数200覆盖交互元素3000单次探索耗时15-30分钟全自动发现Bug总数47个其中P1级Bug9个传统脚本漏测的Bug47个全部AI误报率~12%人工复核耗时每版本约1小时最让我意外的一点47个Bug里没有一个是崩溃类的——全都是功能性异常跳转错误、状态不同步、数据展示不对。这类Bug恰恰是传统自动化脚本最难覆盖的因为脚本只会验证“写死”的路径而AI会到处乱点反而更容易撞上这些“隐蔽”的问题。有一次AI在探索“优惠券领取”流程时发现了一个很有意思的Bug——在某种特定操作顺序下先领一张券→返回→再进入→再领一张第二张券的领取按钮会变成灰色但没有任何提示。用户以为不能领了但其实后台是可以领的。这个Bug如果靠人工测试需要非常凑巧的操作顺序才能触发。AI在探索过程中随机撞到了这个路径直接报告了。测试团队的反应一开始大家觉得“AI到处乱点能测出什么”现在变成“每次跑完先看AI的报告再决定要不要人工补充测。”六、和传统方案的对比维度传统脚本自动化人工探索式测试VisionTestAI探索用例编写2-3人天/版本不需要不需要脚本维护高UI一变就挂不适用零维护覆盖率固定路径依赖经验全量遍历发现未知Bug的能力弱强强执行速度快慢中等15-30分钟误报率低低中等需人工复核可规模化难脚本膨胀难人力有限易加设备就行VisionTest不是要取代人工探索式测试而是把“重复性的基础探索”自动化了。测试同学现在可以把精力放在复杂业务流的深度测试上而不是花大量时间到处乱点找Bug。七、给同行的一些建议如果你也想尝试这个方向我有几点掏心窝的话1. 从“设计稿解析”开始别一上来就搞全量探索我们第一个月只做了一个功能——解析UI稿生成页面地图。这一步跑通了再逐步加上“自主探索”和“智能断言”。分阶段推进每阶段都有可交付的成果团队才有信心继续往下做。2. 选对模型比选“大”模型重要我们试过好几个多模态模型——GPT-4V、Qwen-VL、Gemini、UI-TARS。发现专门针对UI场景优化过的模型比如UI-TARS、CogAgent在元素识别准确率上明显优于通用模型。不是参数越大越好是越“懂UI”越好。3. 接受“AI辅助”的定位别指望“AI替代”AI探索式测试的输出是“疑似问题清单”不是“最终缺陷报告”。每个疑似问题都需要人工复核确认。我们现在的流程是AI跑完→生成报告→测试同学花1小时复核→确认的Bug提交TAPD。千万别让AI自动提交Bug——我们试过后果是开发同学在群里疯狂我“这什么鬼这也能算Bug”4. 先跑“非核心”页面别一上来就让AI去探索支付流程、登录流程这些核心链路——万一AI把生产环境搞出问题来你担不起这个责任。我们最开始只在测试环境的非核心模块个人中心、设置页、帮助中心上跑跑了两周没问题才逐步扩展到核心业务。安全第一效率第二。5. 把“探索结果”可视化AI跑完探索式测试如果只给一份文字报告没人看得进去。我们做了一个页面关系图的可视化工具——每个页面是一个节点每个跳转是一条边有问题的节点标红。产品、开发、测试一看就明白“哦这个页面没覆盖到”“这个跳转有问题”。可视化比任何报告都管用。最后多模态AI做探索式测试本质上是把“人眼看屏幕人脑做判断”这个过程自动化了。技术门槛没有想象中那么高——一个多模态大模型 一套设备控制能力 一个简单的探索策略就能搭出一个可用的原型。但这件事真正有价值的不是“技术有多牛”而是它改变了测试团队的工作方式——从“写脚本验证已知路径”变成了“让AI探索未知路径”。后者发现的Bug往往才是真正影响用户体验的。如果你团队还在被UI自动化脚本的维护成本折磨我建议你认真看看这个方向。把设计稿丢给AI让它自己去探索——这事儿真的能成。
