做 Android 应用测试的同学这两年应该都有同一个感受测试脚本越来越能写但应用也越来越复杂。传统 UI 自动化在稳定性和覆盖面上经常力不从心尤其是真机测试——厂商 ROM、屏幕尺寸、系统版本、权限弹窗这些排列组合出来场景多到让人绝望。Google 开源的 ARTEMIS 给了另一个思路把 AI Agent 接进来用大语言模型驱动一个能在真实 Android 设备上自主探索、点击、输入、滑动、杀后台、再爬起来的测试“实习生”。这篇文章我结合实际跑通的经验把 ARTEMIS 的原理、搭建、踩坑和调优思路一次讲清楚适合正在做质量保障、自动化测试或者对 AI Agent 在移动端落地感兴趣的团队和个人。1. 真机测试的困境与 ARTEMIS 的切入点1.1 传统真机测试之痛先聊聊大家最熟悉的痛。很多团队的移动端自动化还在用 Page Object 那一套把登录按钮、搜索框、确认弹窗一个个写成定位器然后按顺序串成用例。这套东西在版本迭代不频繁、页面结构稳定的场景下没问题但遇到两个情况就开始崩一是页面结构天天改Android 的 resource-id 经常因为团队重构而变二是需要覆盖的机型、系统版本太多脚本在不同 ROM 上表现完全不一样。我见过最典型的案例一套 Appium 脚本在 Miui 上跑得好好的换到 ColorOS 上就全部找不到元素。原因不一定是定位器写错而是某些国产 ROM 对 WebView、悬浮窗和权限弹窗的处理方式不一样。于是团队只能不断加条件判断脚本越来越臃肿维护成本直奔测试开发人力的上限。除了元素定位的脆弱性传统方案在探索性测试上几乎是空白。你当然可以写随机点击脚本来做 Monkey 测试但 Monkey 没有任何“理解”能力它不会因为看到一个登录页而输入正确的账号密码更不会因为某个页面可能存在漏洞而优先尝试它。结果就是 Monkey 跑了几十万次有效路径覆盖依然很低崩溃大多发生在登录后、支付前、设置页这些需要组合操作的深层页面。真机测试的大头其实在“人肉”。每个版本发布前测试同学拿着真机按用例表走一遍耗时几小时甚至一两天反馈链路还长。很多小团队根本没有精力做系统的机型兼容测试只能在用户反馈后被动补测。传统的图像识别、脚本录制工具也都有各自的硬伤录制的脚本重放率低截图对比对动态页面无能为力。1.2 ARTEMIS 到底解决了什么ARTEMIS 的出现本质上是把“人能理解页面、然后动手操作”这一能力用 AI Agent 的方式搬到了真机上。它不是一个录制回放工具也不是简单的随机点击工具而是让模型实时感知设备屏幕内容理解当前界面是什么状态然后自己决定下一步做什么。它解决的核心问题有三类。第一脚本适应性问题。传统脚本的核心依赖是元素定位而 ARTEMIS 走的是“视觉 语义”的路线。即使 resource-id 变了只要按钮还是那个按钮模型就能通过截图和 UI 层级推断出它的位置和用途不需要为每次改版重写脚本。第二探索覆盖问题。因为模型每次都能看到当前屏幕在做决策它可以像人一样沿着业务路径走从启动页走到登录页再到各个主 Tab还能主动尝试深层入口。第三反馈闭环问题。ARTEMIS 不仅会点还会看结果如果点击后页面崩溃、白屏或无响应它能捕获异常上下文把截图、logcat 堆栈、操作序列完整保存下来形成可复现的缺陷报告。我实际跑下来最大的感受是ARTEMIS 的定位不是替代现有的 UI 自动化框架而是补上了“探索型测试”这块空白干的是测试团队里新同学入职前三个月在做的事——对着一台真机到处点点点发现奇怪行为。区别在于 ARTEMIS 手上的不是经验而是对当下屏幕状态的理解。2. ARTEMIS 核心工作原理拆解2.1 感知层设备在“看”ARTEMIS 的感知层非常直白截屏 布局层级。每一次决策之前它会先拿一张当前屏幕的截图同时抓取一份当前 Activity 的 UI 层级树通过 UIAutomator 的 dump 或 AccessibilityService 能力把这两部分信息压缩后交给大语言模型。这里有个关键点模型并不会直接看整张高清原图那样费 token 又不提升理解效果。在常见实现里图像会被等比缩放甚至做最简单的显著性裁剪布局 dump 也不会全量发送因为一个复杂列表页的层级树可能有上千行 XML。ARTEMIS 的做法通常是把层级树截断到最近的可交互节点并附上 bounds 坐标、content-desc、resource-id 等信息。为什么感知层要同时保留“截图 层级”而不是只靠截图因为单靠截图模型很难精确知道“这条边距是多少”“这个手指要滑多少像素”误触概率很高。而层级树提供了可点击元素的精确边界框模型可以据此计算点击坐标。反过来只靠层级树也不行因为很多动态绘制内容比如 Canvas 上的图表、WebView 内部的页面在层级树里是空白。所以两条腿走路互相兜底。感知层还有一个工程上的细节值得注意抓取层级的时机。如果页面正在加载动画或弹窗刚出现dump 出来的状态往往很脏比如空节点、透明遮罩层、奇怪的组合。更稳妥的做法是在截屏后等待一小段时间或者连续抓两次取最后一次稳定状态。这个看起来不是核心 AI 的事但直接影响模型决策质量。2.2 推理与决策层LLM 在“想”感知层把“当前世界状态”送去给模型推理层负责产出决策。ARTEMIS 的核心循环特别简单观察 - 思考 - 行动 - 再观察。每一轮模型输出的不是一个完整的测试计划而是下一个动作的预测比如“在坐标 (510, 1320) 单击登录按钮”“在输入框输入 testexample.com”“从底部向上滑动半屏”。这种单步决策的设计很有讲究。如果让模型直接生成一个“完整回归计划”并假设每一步都能严格执行一旦中间 UI 出现意外后续所有动作都会失准。而单步决策把智能用在了刀刃上模型永远基于最新一帧像素状态来决策容错性高。用开车来类比传统脚本像赛车手按赛道图跑圈ARTEMIS 则像老司机边看路边打方向路况变了也能随机应变。在动作设计中ARTEMIS 的动作空间一般包含三类点击类单击、长按、输入类文本输入、删除清空、导航类返回、滑动、滚动、按 Home、切后台。动作目标不能只是“我想点按钮”这种语义描述还必须带上坐标或元素引用这是为了对接 UIAutomator 的执行接口。决策时还会引入约束条件。比如测试某个电商应用时可以设置“不要点击退出登录”“不要进入支付确认页”这些约束以指令形式附加在系统提示词里防止模型在无边界探索时把应用状态搞脏。我试过不加约束结果模型第二次循环就把应用语言切成了英文后面测试路径全变了。2.3 执行与反馈层手脚和眼睛模型输出一个动作之后剩下的活交给了执行层。ARTEMIS 通过 ADB 通道驱动真实设备adb shell input tap x y、adb shell input swipe x1 y1 x2 y2 duration、adb shell input text ...坐标全部直接落到下层接口。对于 UIAutomator 判定为不可点击的节点则需要先滚动到可视区域这本身也是一个动作序列。执行层之后是反馈层这部分最容易被忽略但恰恰最影响效果。ACTION 执行完ARTEMIS 需要回答三个问题页面变了吗变到哪儿了过程中有没有异常发生它会把新截图和旧截图做对比结合新的 UI 层级判断是否发生了跳转还会监听logcat里的 ActivityManager、AndroidRuntime 相关日志检测是否出现了崩溃、ANR、内存溢出。反馈内容的丰富度直接决定学习的有效性。如果只告诉模型“没有崩溃”它很难知道刚才的操作到底有没有意义。但如果同时告诉它“当前页面标题是购物车出现了一个 Toast 提示”模型的下一步决策就会准确得多。这些反馈最终会汇入两个地方。短期反馈用于当前探索会话的下一步决策避免在同一页面上反复横跳长期反馈则写成 trace 日志和结构化记录用于测试结束后生成报告、统计动作分布、还原失败现场。整个流程闭环之后ARTEMIS 才真正像一个“边操作边记录”的真人测试员。2.4 记忆机制短期与长期记忆别小看记忆机制它是决定 AI Agent 测试效率上限的隐形功臣。大家都有过这种经历人工测试时你会记得刚才已经试过“设置页的开关”所以下一轮会去点“关于手机”而不是反复在同一个页面原地打转。ARTEMIS 同样需要这种记忆否则模型每次只能看当前屏幕很容易陷入局部循环。短期记忆记录的是当前会话内访问过的页面和已经执行过的动作通常以“页面签名 动作摘要”的形式保存。页面签名可以由顶层 Activity 类名和关键 content-desc 组合而成动作摘要则记录诸如“点击了设置 选择语言 切换到 English”。当模型规划动作时系统会把这套历史作为一个上下文片段注入提示词让模型产生“这件事刚才做过了换一个吧”的判断。长期记忆则可以跨会话复用。比如在同一个应用的多轮冒烟测试中ARTEMIS 可以记录哪些模块出现过不稳定现象、哪些操作序列最容易触发崩溃下一次测试时模型会优先回到那些高风险区域。注意这里说的“长期记忆”不一定是复杂向量库早期实现用 JSON 文件存历史轨迹就够用。不过当测试规模大到需要跨设备、跨版本沉淀经验时那就要考虑独立的 skill 库或 memory service 了。3. 从0到1搭建一个自己的 ARTEMIS 环境3.1 硬件与软件准备清单先泼一盆冷水ARTEMIS 的准入门槛不算低尤其是真机环境。你至少需要一台支持 USB 调试的 Android 设备——最好别用太老的系统版本建议 Android 10 以上否则某些现代控件和 WebView 在层级 dump 里表现不完整。Android 模拟器可以用但模拟器对一些传感器、多窗口、真机弹窗场景模拟不到位有条件还是直接真机。软件层面需要准备的东西按大类分Java、Android SDK 平台工具、Python 3.9 以上环境、以及一个大语言模型的调用 Endpoint。ARTEMIS 默认设计上可以对接多个模型服务你可以用 Google 的 Gemini API也可以配置本地部署的开源模型。如果团队对数据敏感强烈建议走本地化部署把测试截图和设备状态控制在内部环境避免把业务截图流传出去。还需要强调一点这不是一个“开箱即装”的工具链。ARTEMIS 会依赖adb、uiautomator等系统组件安装前最好把 Android SDK platform-tools 路径加到系统 PATH 里。我在第一次配置时因为漏了 SDK 环境变量卡在adb: command not found上浪费了不少时间。3.2 环境配置实操整个环境配置可以分为四步。第一步是拉取仓库并进入目录。git clone https://github.com/google/artemis.git cd artemis第二步是安装语言依赖。ARTEMIS 的核心是 Python 包需要把项目内要求的依赖一次性装齐。建议使用虚拟环境python3 -m venv venv source venv/bin/activate pip install -r requirements.txt第三步是配置模型 Endpoint。项目主配置文件一般在config/目录下你需要把 API Key、模型名称和 Base URL 填进去。用 Gemini 的话把 Key 配置到环境变量里更安全如果接本地模型则要确保模型服务地址可从执行机访问。第四步是连接设备并确认可用adb devices这一步会列出已连接设备如果看到unauthorized需要先在手机上解锁并允许 USB 调试授权。确认设备 ok 后再运行一个冒烟命令验证 UIAutomator 是否可用adb shell uiautomator dump /sdcard/window_dump.xml能拿到 XML 文件说明基础链路没问题。在实际项目里我遇到过uiautomator dump在某些页面直接超时的情况尤其是有 WebView 和复杂动画的页面这时候需要加大 ADB 超时时间或者用 ARTEMIS 实现里的重试逻辑。3.3 测试任务配置ARTEMIS 的使用方式不是“双击运行”而是为每个测试目标编写一个任务配置。配置内容直接决定了模型探索的边界和时长。我总结一个最小配置的常见形态app: package: com.example.app launch_activity: .MainActivity deep_link: test: max_steps: 80 # 单次探索最多动作数 timeout_seconds: 1800 # 会话超时 action_rounds: 20 # 每轮携带的动作条数 constraints: block_packages: [] # 不允许跳转到的应用包名 block_text: [退出登录, 注销账号, 确认支付] # 禁止点击的文本 execution: device_serial: emulator-5554 screenshot_quality: 0.7 dump_timeout_ms: 3000这里的block_text很关键它是安全护栏。我记得第一次跑实验时模型在优惠券页面看到一个“永久删除”按钮差点就点下去了。后来我养成了习惯凡是涉及不可逆操作的文本全部写进黑名单宁可漏测也不能让模型把用户数据搞坏。另外还要考虑应用启动方式。如果应用支持 deep link建议配上这样可以直接从业务子页面进入测试探索覆盖面会大得多。如果不支持就指定launch_activity让系统负责拉起应用。3.4 首次运行实操记录任务配置好之后启动命令一般长这样python main.py --config config/example.yaml --report-dir ./reportsARTEMIS 会先拉起设备上的应用然后进入观察-行动循环。第一次跑的时候建议打开--verbose日志模式这样你能在终端看到每一轮模型输入的状态摘要和输出动作。我当时的实际体验是模型先看到启动页等待片刻后点击“开始使用”然后到权限弹窗点击“允许”再进入主界面开始逐个 Tab 探索。第一轮跑完的报告通常包含三样东西动作序列 JSON每一步的操作、坐标、耗时、异常列表崩溃、ANR、白屏记录、页面覆盖清单访问过的 Activity 和 Page Title。有一个很容易踩的坑首次运行模型可能会非常“愣”在同一个页面上反复输入回车、滑动或者干脆连续点同一个位置。我分析下来这多半是 UI 层级里存在大量无 content-desc 的空白节点模型从截图上看不出区别只能靠猜。为了减少这种事建议在配置里开启“动作去重”选项同时把一些常见误触区域比如状态栏、导航栏从动作空间里剔除。4. 关键参数与调优方向4.1 动作空间为什么限制了反而更快看到标题你可能会疑惑AI Agent 不应该越自由越好吗我的实测结论是限制动作空间收益远大于损失。一个未加限制的 ARTEMIS 实例理论上可以单击屏幕任意坐标、随意滑动、随时按 Home但这些动作大部分对业务测试没有价值反而会大量消耗 token、增加异常概率。合理的动作空间应该像一道“护栏”让模型在不踩线的范围内自由发挥。比如限制滑动距离为屏幕高度的 1/3 到 1/2点击只允许落在有可交互节点的区域输入只允许落在 EditText 的 bounds 内。这样做的结果是决策成功率明显提升因为模型不需要从 3000 个随机坐标里蒙答案。我建议你在调优时把动作空间划分成“常用动作”和“探索动作”两类。常用动作包括单击、文本输入、返回探索动作包括长按、多指缩放、横竖屏切换。先用常用动作集跑覆盖再用探索动作集做专项攻击测试分开能明显提升报告可读性也便于定位问题。4.2 上下文窗口与决策质量大语言模型的上下文窗口是有限的ARTEMIS 每轮决策又需要同时携带截图、UI 节点、历史摘要、约束条件。一旦超过模型的上下文上限轻则报错重则模型直接丢失前面的约束做出危险动作。所以上下文管理和压缩不是优化项而是必选项。ARTEMIS 的常规做法是把 UI 层级树压缩。一个完整 dump 可能有几百个节点但真正可点击、可输入的交互节点通常只有几十个所以先用过滤器把不可见、不可交互的节点筛掉再对每个节点保留 id、class、content-desc、bounds基本能缩小到十分之一。截图同样需要压缩。我跑下来的经验是把截图缩放到宽度 400px 左右同时输出为 JPEG质量和 PNG 几乎无差别token 开销却少一半。另外历史摘要不要全量拼接只保留最近几轮的页面签名和动作摘要更早的历史直接丢弃或转化成“已访问页面”列表这能显著减少噪音让模型更专注于当下的屏幕状态。4.3 奖励模型与探索策略如果只让模型随便点ARTEMIS 很容易变成“高级版 Monkey”虽然不会瞎点但也不会主动往深层页面钻。想让它在有限步数内访问更多页面、触发更多潜在缺陷就得有一个 Reward 信号来引导探索方向。常见的奖励信号包括页面状态变化与否。如果动作后页面发生了变化标题变化、Activity 变化、UI 树变化给正分如果动作后页面纹丝不动给负分如果发生崩溃触发强惩罚并记录。模型在做规划时会倾向于选择高奖励的路径这和强化学习里奖励最大化的思路类似。ARTEMIS 在探索策略上通常结合贪婪和随机。多数时间它按模型的高置信度动作走偶尔加入随机动作扰动目的是跳出局部页面循环。这个“偶尔”的比例建议不要超过 10%。我试过调到 30%结果测试会话瞬间失控模型不断执行无意义的随机滑屏覆盖率反而下降了。如果你想把探索更聚焦还可以配置“辅助目标页面”。比如告诉模型“本测试关注用户注册流程”它会有意识地往注册相关界面走。这种方式比完全开放式的探索效率高不少适合每个版本迭代的定向回归。4.4 和传统测试框架如何共存ARTEMIS 不是一个推翻重来的工具更适合和现有自动化体系配合使用。我目前推荐的组合方式是这样传统 UI 自动化负责稳定路径的回归测试每天跑ARTEMIS 负责上线前和版本变更后的探索性测试每周跑两轮重点发现框架脚本没有覆盖到的深层问题。代替方案上Appium、Maestro 这类工具依然是主流因为它们和 CI/CD 集成成熟、断言丰富。ARTEMIS 现阶段更适合当“侦察兵”——先让它把应用翻一遍把可疑路径和崩溃点找出来然后人工核验把确认有效的路径固化成 Appium 或 Maestro 用例。好处很明显团队可以用机器去补足最耗人力的“发散性探索”让测试工程师把时间花在分析 ARTEMIS 报告、设计针对性用例上。这其实是一种人机协作的工作流而不是简单的工具替换。5. 实战中常见问题与排查技巧5.1 设备连接与执行层问题真机测试里最烦人的永远不是 AI 策略而是设备本身。下面这个速查表是我压箱底的东西按出现频率排过序。现象可能原因解决思路adb devices显示 offlineUSB 线不稳定或授权被撤销重新插拔撤销 USB 调试授权后重新允许uiautomator dump超时页面动画、WebView 或服务过载增加 dump 超时或先执行input keyevent 4返回稳定页面点击无响应但程序没报错目标节点不在当前窗口焦点或有遮罩层查看层级树中的窗口范围先关闭遮罩或点击遮罩外区域input text无效焦点不在输入框先通过adb shell input tap聚焦输入框再发送文本系统弹窗拦截操作权限弹窗、系统更新弹窗在配置中启用自动处理弹窗策略或前置脚本里统一授权设备连接这块我吃过最大的亏是 USB 供电不足。测试执行到一半设备突然离线整个 agent 循环卡死在 ADB 等待上。后来我在所有都跑真机的工位上放了一个带独立供电的 USB Hub问题基本绝迹。这种问题在文档里不写但在实际团队里特别常见。5.2 页面感知层问题感知层最大的敌人是“看不到”。ARTEMIS 在三种页面上表现比较弱WebView/H5 页面、React Native 和 Flutter 页面、原生 Canvas 绘制页面。这些页面的共同特征是 UI Automator 层级树信息严重缺失甚至只能拿到一个空壳节点模型在没有任何节点坐标的情况下很难精确操作。针对这些问题我的经验是分而治之。如果是 WebView可以在应用侧开启 WebView 调试模式让 ARTEMIS 走 Chrome DevTools Protocol 来感知页面内容如果是 Flutter 页面则需要复用在 Flutter 端开启无障碍语义树。这两种方案的接入成本都不大但能大幅提升感知质量。还有一类容易被忽视的是“动态加载弹窗”。比如页面刚打开时有一个 3 秒的倒计时广告弹窗模型在截屏中看到了它可是等到执行点击时弹窗已经自动消失了于是点击落空整个决策链被打断。处理思路是感知层加入“稳定性等待”——检测页面是否仍在加载、是否有计时器倒计时等界面稳定后再让模型决策。5.3 LLM 决策层问题模型层面的问题比工程层面的问题更难定位因为它们不是报错而是“决策跑偏”。我遇到次数最多的有三类无意义点击、环境干扰幻觉、目标漂移。无意义点击的表现是模型在两个页面之间来回跳比如一会儿进设置一会儿返回主界面循环三五次之后才往下走。排查后发现问题出在我的动作去重配置太弱模型每轮看到的都是最新截图很难意识到刚才已经做过同样的操作。对症下药是增强短期记忆摘要并把“最近动作列表”注入到提示词里。环境干扰幻觉尤其容易出现在设备弹出系统级提示时。比如电池优化弹窗模型会误认为这是应用内弹窗花很多步数去处理它。建议在系统提示词中添加上下文说明明确指出哪些系统级 UI 应当被忽略而不是交互。目标漂移表现为最初设定的探索目标是“购物流程”但跑了 20 步之后模型开始关注“个人资料设置”。这不一定算坏事但如果希望保持目标专注可以定期把“当前用户任务目标”放回提示词的核心位置并且每 5 步检查一次是否偏离。我实践下来这样做之后任务完成率明显提升。5.4 结果验证与覆盖率统计测试跑完了不能只看“有没有崩溃”。我第一轮跑 ARTEMIS模型跑了 80 步崩溃 0 个页面倒是访问了不少。可你要问它“业务主流程覆盖了吗”我根本没底。所以结果验证环节必须有而且要在配置阶段就想清楚。覆盖率统计可以从两个维度来Activity 覆盖和关键页面标题覆盖。前者可以通过 logcat 里的 Activity 跳转日志拿到后者需要在感知层维护一个“已访问页面标题”列表。跑完测试之后拿着这些数据对比应用的主要功能清单就能知道哪里没测到。崩溃结果也不能只看有没有 FATAL。Android 上很多问题不崩但会让体验很差比如 ANR、内存泄漏导致的卡顿、App 静默崩溃直接闪回桌面但无堆栈。ARTEMIS 如果只监听FATAL EXCEPTION会漏掉至少一半的缺陷。建议同时开启ActivityManager的 ANR 日志过滤以及监控进程存活状态一旦目标进程消失就立即截取当时的 logcat 和截图。另外强烈建议把动作序列的关键帧截图做成一组“语义快照报告”按时间线排列。这样人工 review 的时候不用重跑一遍也能还原当时发生了什么。这种报告拿去跟开发对线说服力远超一句“AI 说这里有问题”。6. 我的实操体会与后续玩法如果想用 ARTEMIS 落地我最大的建议是别一上来就跑全量生产应用先挑一个复杂度中等、且有已知 bug 的历史版本做“复现测试”。如果 ARTEMIS 能在几分钟内找到那个已知问题说明链路是通的你也就有了信心继续推进。第二个建议是不要把 ARTEMIS 当黑盒工具。它的效果非常依赖 prompt 和约束配置而不同应用、不同业务路径的配置策略差异极大。电商应用要多管权限弹窗和新用户引导工具类应用要多防误操作社交应用要特别关注内容流加载和内存占用。这些东西没人能替你做只能在一次次真实测试中积累。我测试过的团队里落地效果最好的状态是每天夜里自动跑一轮 ARTEMIS第二天早晨测试工程师拿到一份包含新增崩溃、可疑路径、覆盖热点的报告上午集中精力处理前一天的敏感路径再用回归脚本验证。整个周期从传统探索测试的按周计缩短到按天计。未来可玩的方向也很多。比如把 ARTEMIS 输出的失败轨迹转成 Maestro 可执行的回归用例让探索出的问题能固化沉淀再比如在不同品牌的真机云平台上批量部署 ARTEMIS把机型兼容测试也自动化起来还可以把 ARTEMIS 的长期记忆接上缺陷管理系统每次测试都自动关联历史 bug 状态最终形成一个越跑越聪明的内置测试大脑。这个过程不会一蹴而就但每一步都能看到实际回报。