Google开源ARTEMIS：AI Agent驱动的Android真机UI自动化测试实践-北京尧图网络

上个月我在跑一条Android端到端用例光是因为首页的一个弹窗脚本就在CI上红了两天。改完之后产品隔天把按钮文案从立即体验改成开始使用选择器又挂一次。做客户端测试的人都懂UI自动化的最大成本从来不是写脚本而是维护脚本。所以当Google把ARTEMIS这个AI Agent项目开源、并且明确说它用于Android真机测试的时候我第一时间去扒了源码。这个项目想干的事情很激进——不再是你写脚本告诉机器去哪而是你给一句自然语言任务Agent在真机上自己看屏幕、自己决定下一步点哪里。这篇文章我不打算复述官方README而是结合我自己把它跑起来的过程聊聊ARTEMIS的工作方式、实际效果、部署要点以及AI Agent测试这条路线离真正可用还有多远。如果你是被UI用例维护折磨的客户端测试、或者在做LLM Agent工具落地的开发者这篇文章应该能帮你少走不少弯路。1. ARTEMIS 想解决的问题UI 自动化为什么越写越痛1.1 传统 UI 测试的维护诅咒先回顾一下我们在用的主流方案。Espresso、UIAutomator、Appium本质上都是同一套思路你用代码定位一个控件执行一个操作再做一次断言。定位控件的方式无外乎resource-id、文本内容、class名、或者相对坐标。这套思路在页面结构稳定的App上运行得很好一旦进入快速迭代阶段问题就来了。比如前面提到的弹窗。测试脚本里写了如果出现弹窗就点关闭可弹窗的文案、按钮位置、出现的时机每个版本都在变。今天弹窗盖在列表上方明天改成盖在底部你的脚本就得跟着改。再比如按钮文案从立即体验改成开始使用基于文本匹配的定位直接失效如果产品再换个图标不换文案基于ID的可能还好基于图片的又挂了。真正做过的人都知道一个大型App的UI自动化用例维护成本占七八成写用例本身只占两成。而且这种维护是纯手工的、重复的、没有技术增量的劳动干久了非常消耗士气。更麻烦的是脚本的健壮性依赖测试工程师对产品变动的预判但产品变动恰恰是最难预判的。1.2 从脚本执行器到智能体ARTEMIS的出发点就是绕开预判这件事。它不再要求你写一个精确到控件的操作序列而是让你用一句自然语言描述目标比如打开设置找到关于手机告诉我Android版本号。剩下的事情交给AI Agent它自己看当前屏幕自己决定下一步操作直到任务完成。这里有个关键点ARTEMIS不是录制回放工具也不是简单的OCR识别坐标点击。它是一个具备视觉理解、规划决策、工具执行能力的完整智能体。它把每个UI测试任务当成一个在真实环境里求解的问题来处理——先观察环境再根据观察做决策执行动作后再次观察形成闭环。这和人类测试工程师的实际操作逻辑几乎一样区别只是人类会疲劳、会漏看、会忘记步骤Agent不会。而且它跑的是真机不是模拟器。为什么选真机因为很多场景你就是得在真机上才能测出来存储空间不足的表现、各种厂商定制系统MIUI、ColorOS这类的权限弹窗、刘海屏和挖孔屏的布局、弱网状态下的超时逻辑。模拟器覆盖不了一家公司真实的用户设备矩阵。ARTEMIS做的是一个在真机上长出手脚和眼睛的Agent这也是它和一堆只在模拟器里跑Demo的论文项目最不一样的地方。1.3 Google 为什么选择开源Google把ARTEMIS开源的意图与其说是做一个测试工具不如说是把Android生态的UI智能化交互往前推一把。对于工程界来说开源有几个直接价值第一测试团队可以在自己内部环境部署不用把设备画面和App交互数据送到第三方云服务第二社区能贡献新的动作类型、校验逻辑和设备适配第三模型这块可以根据各家情况替换——不一定非用Gemini只要你接的模型支持视觉输入和结构化输出理论上都能跑。这个可扩展性对测试基础设施团队来说极其重要。从测试从业者的视角看开源也意味着我们不再只能干等商业产品支持某个功能。Agent动作空间不够自己加。某个设备型号适配不好自己修。这种自由度在以前只能买商业UI自动化工具的时候是没法想象的。维度传统UI脚本ARTEMIS AI Agent用例编写方式精确控件定位操作断言自然语言任务描述对UI变动的适应能力差文案/层级变化即失效强依据视觉语义自行调整探索未知界面不支持支持结果断言精确、可靠需要额外校验器辅助调试难度日志录屏定位推理日志截图回放维护成本高相对低但要维护prompt和校验器2. 核心工作流拆解看一眼屏幕、想一步、点一下2.1 设备的眼睛截图与状态获取ARTEMIS对设备状态的感知核心路径是截图。Android的截屏在ADB层面就是一个命令adb exec-out screencap -p screen.png。在Agent的运行循环里这一步高频执行每次决策前都要抓一张当前画面。但直接拿原始截图喂给模型在工程上会有几个问题。首先是分辨率。现在很多真机是1080P以上甚至1440P、2K直接把大图塞给视觉模型一方面token开销大另一方面模型对过小元素的定位精度会下降。实操中通常会把截图做等比缩放或者只截取关键区域保证文字清晰的前提下尽量减小尺寸。其次是旋转。手机当前横竖屏状态不同截图传给模型前需要统一方向否则模型给出的坐标会错位。再次是刘海屏、挖孔屏的遮挡区域截图包含这些信息模型如果不懂就可能在状态栏附近误触。如果只有截图模型在部分场景下会看不准比如两个长得一样的列表项、深层嵌套的弹窗。ARTEMIS在需要的时候会额外读取UI层级信息通过uiautomator dump拿到当前界面的控件树。有了控件树模型的定位就不是猜而是可以在候选控件里选。但UI层级信息有两个缺点一是Canvas渲染的自定义控件经常dump不到内容二是大型列表会生成巨大的XML解析开销不小。所以实际策略是截图为主UI层级为辅模型自己决定什么时候需要辅助信息。2.2 模型的大脑从画面到动作拿到了截图接下来就是模型的推理环节。ARTEMIS的推理循环本质上是一个不断迭代的prompt工程把系统指令、当前任务描述、历史动作摘要和当前截图一起交给多模态大模型要求模型输出一个结构化的动作指令。动作空间是这套设计的核心。ARTEMIS支持的动作类型大致包括tap单击某个坐标或单击某个控件swipe滑动用于翻页、下拉刷新、删除列表项long_press长按触发上下文菜单或拖拽type_text往输入框填入文本press_back返回键press_home回到桌面scroll页面滚动方向可指定wait等待若干毫秒用于处理页面加载和动画模型输出这些动作时需要对屏幕坐标有精确的感知。比如tap动作模型要在图像里找到按钮的位置再输出一个相对坐标代码再换算成屏幕像素坐标。这个过程叫坐标回归coordinate regression是视觉语言模型在UI操作任务里最核心的能力之一。为什么不用控件选择器因为控件选择器要求先知道界面的语义结构而模型做的是从像素层面直接理解画面——哪怕是一个完全自绘的、没有标准控件的界面它也能根据视觉特征判断这里像一个按钮。这恰恰是传统自动化框架最头疼的地方。输出的动作结构一般是一个JSON对象包含动作类型、必要的参数和坐标。类似这样{ action_type: tap, coordinate: {x: 0.62, y: 0.21}, description: 点击桌面上的设置图标 }解析之后ARTEMIS通过ADB或者系统UI服务去执行比如用input tap x y或者调用UIAutomator的API做文本输入。执行完不是结束而是新一轮循环的开始。2.3 闭环执行、观察、再决策Agent和后端脚本最大的不同在于闭环反馈。脚本只关心我发指令-系统执行-我拿返回结果而Agent关心我做了这个动作之后屏幕变成了什么样。所以ARTEMIS在每次动作执行后都会立即再抓一张截图和动作前的状态做对比。如果屏幕没有任何变化说明这个动作可能失效了比如点击落在空白区域、动画还在进行中Agent会记录这次失败换一个策略重试。如果屏幕变化了Agent需要理解这变化是否符合预期是弹窗出现了还是页面跳转了还是列表滚动了基于新的状态再决策下一步动作。这个过程需要记忆机制。一个长任务可能涉及十几步操作如果模型每次都只看到当前截图很容易忘记自己已经做过什么、距离目标还有多远。ARTEMIS会在上下文中维护一份精炼的操作历史把每步的动作观察结果压缩成摘要随下一次请求一起发给模型。这相当于给Agent带了一个便签本避免重复点击或来回跳转。循环的终止条件有两个一是模型自己判断任务已完成二是达到预设的最大步数。实际使用中第二个条件尤其重要否则一个卡住的任务会在设备上无限执行下去浪费设备资源。提示如果你在部署时发现Agent反复执行同一动作优先检查你的历史摘要字段是否正常传给模型。上下文丢历史是循环卡死最常见的根源。2.4 可插拔的校验器ARTEMIS还有一个对测试工程师很友好的设计你可以在Agent的动作循环里插入自定义校验逻辑。比如任务执行到某一步后代码里检查某个文本是否出现、某个控件是否存在如果不满足就停止并报失败。这意味着AI Agent不是完全的黑盒。测试团队可以把传统的断言能力保留下来在AI自由发挥的基础上对关键节点做确定性校验。我用下来觉得这是目前把AI测试落地到生产环境最稳妥的姿势让Agent负责探索和操作让代码负责关键结果的验证两边互补。3. 跑通一次真机测试环境搭建与任务执行记录3.1 环境准备清单这部分按我实际操作过的步骤来写具体版本号以官方仓库的README为准因为项目迭代比较快。准备工作分四块Python环境建议3.10以上版本顺手把虚拟环境建好避免污染系统Python。Android SDK platform-tools主要用ADB。装好之后adb version能正常输出版本号即可。一台真机开启开发者选项和USB调试。建议先用Pixel或原生系统设备跑通再换国产定制系统。一个大语言模型的API KeyARTEMIS默认接Gemini系模型需要配置环境变量。如果走兼容OpenAI协议的其他多模态模型理论上也可以替换但需要自己改适配层的代码。大致的安装流程如下git clone https://github.com/google/artemis.git cd artemis python -m venv venv source venv/bin/activate pip install -r requirements.txt export GEMINI_API_KEY你的APIKey3.2 ADB 连接与设备健康检查设备连上电脑后先跑adb devices确认设备被识别。如果设备状态显示unauthorized需要在手机上确认USB调试授权弹窗。然后我习惯检查两个东西屏幕是否亮着、锁屏是否解开。Agent如果碰到解锁界面它可能自己尝试滑动、输入密码但与其让它猜不如提前把设备状态弄干净。把屏幕超时时间调长一些避免测试中途息屏——这一步很关键息屏之后截图全黑模型会完全瞎掉。设备准备好之后运行Agent的命令大致是这样的python run_agent.py \ --device serial_number \ --task 打开设置找到关于手机告诉我Android版本号 \ --max-steps 153.3 一个任务的全过程查看Android版本号我故意选了一个很简单的任务来观察Agent的行为打开设置找到关于手机告诉我Android版本号。任务描述用自然语言写在配置文件里Agent启动后开始循环。下面是我从日志里摘出来的推理过程还原了每一轮的观察-决策-执行第1步屏幕显示桌面。Agent识别到设置图标输出tap动作坐标大概在桌面图标区。执行后屏幕进入设置主页。第2步设置主页没有直接显示关于手机Agent决定向下滑动。执行swipe屏幕滚动一屏。第3步还是没有看到目标项Agent改为使用设置页顶部的搜索框。先tap搜索框再type_text输入关于手机。第4步搜索结果出现在界面中Agent识别出第一个结果项tap进入。第5步页面显示Android版本号: 14等信息。Agent判断任务完成输出完成标记循环结束。整个过程大概10秒左右中途没有需要人工介入的地方。从测试角度看Agent的自然语言导航能力是OK的尤其是第三步当滑动没有找到目标时它主动选择了换一种方法而不是机械地继续滑动这种策略切换能力是传统脚本很难实现的。3.4 任务完成的判定与可信度任务完成后ARTEMIS会返回完成标记和它认为的关键信息。但这里有个实际的问题需要测试工程师注意Agent说完成了是真的完成了我测下来的经验是纯靠模型自报完成并不可靠尤其是当任务要求提取某个具体数值的时候模型可能自信地给出一个错误答案。所以我会在测试脚本里加一道校验任务结束后代码重新抓取当前屏幕检查关键控件是否存在、关键文本是否正确。这条经验也适用于所有AI测试工具——AI的探索执行可以用但结果断言尽量交给确定性代码。4. 实测效果与能力边界哪些场景值得用4.1 它真正擅长的地方用了一段时间之后我的判断是ARTEMIS有一个非常明确的适用区间长流程、多步骤、需要视觉理解的UI操作。比如一个App的新用户注册流程可能要填手机号、填验证码、设置密码、同意协议、跳转首页。传统脚本写这个流程任何一步的控件变化都能让整条用例报废。ARTEMIS不一样它不依赖控件路径而是靠视觉理解这是一页注册表单然后照着目标一步步填。即使按钮位置变了、文案改了只要页面的功能没变它大概率还能完成操作。另一个典型场景是探索性测试。给Agent一个模糊目标比如看看这个App的设置页有没有异常它会自己点进各个子页面四处滑动然后报告看到的情况。这种不预设路径的探索以前只能靠人肉去做现在可以丢给Agent去跑一轮粗筛。4.2 当前明显不擅长的场景把丑话说在前面。这类AI Agent测试方案离替代一切UI测试还远得很有几个场景我用下来是真的不行精确数据断言。断言计算器显示的加法结果是5.0这种场景Agent可能因为视觉识别误差给出4.99或者看起来是5不如传统断言稳定。对时间的感知。页面加载超时、动画闪回、断网重连这类和时序强相关的验证Agent的观察粒度不够它抓了一张截图发现没变化可能判定失败也可能傻等。复杂手势。双指缩放、画圈、拖动到指定位置再松手这类动作在Agent的动作空间里支持得很弱。多语言与地区化文本。模型在非英文界面的识别准确率会下降需要额外做prompt和镜像样本调优。另外性能测试、弱网模拟、电池耗电这些领域本来就不是这类工具的菜该用专项工具还是用专项工具。4.3 和真人手测的对比有人会问既然它能自动探索是不是可以替代人工测试我个人的答案是不能至少现在不能。Agent适合的场景是我已经知道要做什么只是不想写死操作路径而真正优秀的人类测试人员最值钱的不是执行而是判断一个看起来正常的页面其实是错的——这种基于产品理解和业务常识的模糊判断Agent还远远做不到。但反过来看Agent和人工相比有个巨大优势一致性。人工测试员下午三点和下午六点的状态不一样而Agent每一次执行都是同一个水平。把大量重复的冒烟测试路径交给Agent人去做高风险的深度探索这是我目前觉得性价比最高的分工。5. 真机环境实操坑与调优记录5.1 截图与坐标偏移问题真机环境比我预想的要复杂不少最典型的是坐标偏移。默认情况下Agent看到的是屏幕截图的坐标空间而我一开始没有处理设备分辨率结果在高分屏上点位经常点偏。解决办法是做坐标空间归一化把截图缩放到一个标准尺寸传给模型模型输出的相对坐标再乘以缩放比例映射回原始分辨率。这个映射逻辑是ARTEMIS运行稳定性的第一道关卡值得在接入手动确认一遍。其次是设备旋转。竖屏任务的截图传到模型里没问题一旦任务涉及横屏场景模型输出的坐标就会按竖屏的坐标空间理解。我的做法是强制任务开始前统一设备方向避免横竖屏切换导致Agent混乱。5.2 任务描述怎么写才不容易翻车同为自然语言指令写得好不好执行效果天差地别。我的经验是三个原则目标要收敛。不要写检查设置有没有问题要写打开设置检查Wi-Fi开关能否打开再关闭。模糊目标会让Agent自己发挥最后返回一堆没用的观察。一次一个任务。长任务拆成多个短任务分别执行、分别校验出了问题也好定位是哪一段失败。避免依赖外部条件。任务描述里尽量不要涉及需要登录态的账号、需要联网的外部资源除非你专门准备了测试账号和稳定网络。5.3 循环卡死与最大步数我在真机上遇到过Agent在同一步反复尝试的情况比如弹窗出现后它点了一个位置弹窗没消失它又点了相同位置反复几次。排查下来原因多半是动作执行后截图状态没有变化而Agent又没有收到动作无效的反馈。解决办法分三层第一层设置合理的最大步数任务卡住直接判失败绝不能无限循环第二层启用截图对比逻辑执行动作后如果检测到截图几乎无变化立即阻止相同动作的二次执行第三层在prompt里明确告诉Agent如果某个动作执行两遍没有效果必须换一种方式。这三层叠加之后循环卡死的问题基本可控。5.4 多设备并行与CI集成思路ARTEMIS单机跑通只是第一步测试基础设施的常态是要在一批真机上同时跑。我的做法是用一个简单的设备池脚本轮询每个ADB设备逐个分配任务跑完后统一收集结果。结合Jenkins或者GitLab CI用定时任务触发多设备冒烟测试跑完把Agent日志和截图作为测试报告归档。有几个细节提醒第一设备数量多的时候USB供电能力要跟上否则手机边充边跑越跑越卡第二每台设备在任务开始前都要做一次系统状态重置关弹窗通知、清理后台进程避免前一个任务残留影响下一个第三如果设备型号参差不齐建议按分辨率分组跑避免坐标映射逻辑在高低分屏上混用而出错。最后再说说我对这个方向的理解。ARTEMIS这套东西最有价值的不是某一个模型或者某一段代码而是它把一个测试任务从确定性的脚本执行变成了一个观察-决策-执行的智能体循环。这意味着UI测试的自动化程度开始从录什么就回放什么往你说个目标我来想办法的方向迁移。对我这种被脚本维护折磨了很久的人来说这个方向是让人兴奋的。当然现在它离成熟还有距离需要有人继续补校验机制、补动作类型、补设备兼容性。如果你也在搞Android真机测试我建议你找个空闲的真机把ARTEMIS跑起来用一个最简单的任务去感受一下Agent的执行过程。那种亲眼看着它自己在屏幕上点来点去、反复尝试直到完成目标的感觉确实和以前跑脚本完全不一样。

Google开源ARTEMIS：AI Agent驱动的Android真机UI自动化测试实践

相关推荐

实时数仓架构演进与核心技术解析

Wallpaper Engine mpkg文件解析与MP4导出全指南

十字链表与邻接多重表：有向图与无向图的高效存储方案

更多资讯

无需验证器的推理革命：RLPR框架如何让大模型实现自我进化

LTX-2与ComfyUI集成实战指南：从零搭建专业音视频生成工作流

36.6%解决率逼近GPT-4o：SWE-Dev-9B如何改写开源代码模型格局

【强化学习基础（6）】强化学习的应用：从游戏到机器人

2. 编程语言-Java-编程技巧

Krea 2 Identity Edit：5个AI图像编辑功能如何改变你的创作方式？

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？