关注 霍格沃兹软件测试开发 公众号，回复「资料」, 领取人工智能测试开发技术合集
从“写脚本跑自动化”到“丢设计稿自动探索”，我们换了个玩法
大家好，我是某互联网大厂质量效能团队的测试架构师，负责移动端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每执行一个操作后，会问自己三个问题：
页面状态是否正常？ ——有没有白屏、崩溃、无限加载、乱码？
操作是否有反馈？ ——点击按钮后页面有没有变化？如果点了半天没反应，那就是问题。
跳转是否合理？ ——点了“去支付”却跳到了“首页”，这显然不合理。模型会根据设计稿和常识来判断跳转是否符合预期。
最 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级Bug
9个
传统脚本漏测的Bug
47个（全部）
AI误报率
~12%
人工复核耗时
每版本约1小时
最让我意外的一点：47个Bug里，没有一个是崩溃类的——全都是功能性异常（跳转错误、状态不同步、数据展示不对）。这类Bug恰恰是传统自动化脚本最难覆盖的，因为脚本只会验证“写死”的路径，而AI会到处乱点，反而更容易撞上这些“隐蔽”的问题。
有一次AI在探索“优惠券领取”流程时，发现了一个很有意思的Bug——在某种特定操作顺序下（先领一张券→返回→再进入→再领一张），第二张券的领取按钮会变成灰色但没有任何提示。用户以为不能领了，但其实后台是可以领的。这个Bug如果靠人工测试，需要非常凑巧的操作顺序才能触发。AI在探索过程中随机撞到了这个路径，直接报告了。
测试团队的反应：一开始大家觉得“AI到处乱点能测出什么？”现在变成“每次跑完先看AI的报告，再决定要不要人工补充测。”
六、和传统方案的对比
维度
传统脚本自动化
人工探索式测试
VisionTest（AI探索）
用例编写
2-3人天/版本
不需要
不需要
脚本维护
高（UI一变就挂）
不适用
零维护
覆盖率
固定路径
依赖经验
全量遍历
发现未知Bug的能力
弱
强
强
执行速度
快
慢
中等（15-30分钟）
误报率
低
低
中等（需人工复核）
可规模化
难（脚本膨胀）
难（人力有限）
易（加设备就行）
VisionTest不是要取代人工探索式测试，而是把“重复性的基础探索”自动化了。测试同学现在可以把精力放在复杂业务流的深度测试上，而不是花大量时间到处乱点找Bug。
七、给同行的一些建议
如果你也想尝试这个方向，我有几点掏心窝的话：
- 从“设计稿解析”开始，别一上来就搞全量探索
我们第一个月只做了一个功能——解析UI稿生成页面地图。这一步跑通了，再逐步加上“自主探索”和“智能断言”。分阶段推进，每阶段都有可交付的成果，团队才有信心继续往下做。
- 选对模型比选“大”模型重要
我们试过好几个多模态模型——GPT-4V、Qwen-VL、Gemini、UI-TARS。发现专门针对UI场景优化过的模型（比如UI-TARS、CogAgent）在元素识别准确率上明显优于通用模型。不是参数越大越好，是越“懂UI”越好。
- 接受“AI辅助”的定位，别指望“AI替代”
AI探索式测试的输出是 “疑似问题清单” ，不是“最终缺陷报告”。每个疑似问题都需要人工复核确认。我们现在的流程是：AI跑完→生成报告→测试同学花1小时复核→确认的Bug提交TAPD。
千万别让AI自动提交Bug——我们试过，后果是开发同学在群里疯狂@我：“这什么鬼？这也能算Bug？”
- 先跑“非核心”页面
别一上来就让AI去探索支付流程、登录流程这些核心链路——万一AI把生产环境搞出问题来，你担不起这个责任。
我们最开始只在测试环境的非核心模块（个人中心、设置页、帮助中心）上跑，跑了两周没问题，才逐步扩展到核心业务。安全第一，效率第二。
- 把“探索结果”可视化
AI跑完探索式测试，如果只给一份文字报告，没人看得进去。我们做了一个页面关系图的可视化工具——每个页面是一个节点，每个跳转是一条边，有问题的节点标红。产品、开发、测试一看就明白：“哦，这个页面没覆盖到”“这个跳转有问题”。
可视化比任何报告都管用。
最后
多模态AI做探索式测试，本质上是把“人眼看屏幕+人脑做判断”这个过程自动化了。
技术门槛没有想象中那么高——一个多模态大模型 + 一套设备控制能力 + 一个简单的探索策略，就能搭出一个可用的原型。
但这件事真正有价值的不是“技术有多牛”，而是它改变了测试团队的工作方式——从“写脚本验证已知路径”变成了“让AI探索未知路径”。后者发现的Bug，往往才是真正影响用户体验的。
如果你团队还在被UI自动化脚本的维护成本折磨，我建议你认真看看这个方向。把设计稿丢给AI，让它自己去探索——这事儿真的能成。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
