ARTICLE · 1092718

安卓测试不用写脚本了:谷歌开源 ARTEMIS,一句话驱动真机

发布时间：2026-09-28 19:28:20 最近访问：2026-09-28 19:27:30

做安卓自动化测试，最让人崩溃的是哪一刻？我猜不是写用例，是脚本写到一半，产品把 UI 改了。一行 `driver.find_element_by_id("btn_submit")`，界面一改版，id 没了，脚本红一片。这还只是原生控件。碰到 Canvas 画出来的图表、Compose 重写的按钮、Flutter 自绘的列表——元素树里压根没有它们的 id，XPath 也抓不到，最后只能靠坐标硬点，换个分辨率又全错。于是很多测试人的一天，变成了「人肉点手机」：装包、点开、登录、看有没有异常弹窗、截图、记 Bug……这些重复动作，占了安卓测试大半的工时。上周，Google 把一个可能改变这个局面的工具开源了。

先把这个工具认全

工具全名叫 ARTEMIS，是 Google 的 Pixel Test Engineering（PTE）Fusion 团队做的，开源在 `github.com/google/artemis`，Apache 2.0 协议，完全免费，还带中文文档（`README_CN.md`）。它的目标一句话就能说清：你不需要写脚本，用一句话描述要测什么，它自己操作真机跑完，再把截图和日志带回来。官方演示里，给它下了一个跨 App 的复合任务：

在地图里规划旧金山的多站路线、记下总时长，再打开 YouTube 播放一首 Coldplay 的歌。

它真的自己完成了——中间要跨两个 App、多次点击、读屏、判断。传统脚本做这种事，光写「等待元素出现」的重试逻辑，就能写吐。

图片来源于Github.

两种跑法：一个求快，一个求证据

ARTEMIS 提供了两种模式，一句话概括：Flash 求快，Pro 求证据。

看出门道了吗？Pro 模式在「动手前」会先校验目标、「动完手」会留证据。这正是测试最看重的东西——不能 AI 说「测完了」你就信，得能复盘它每一步干了什么。

它为什么敢碰「自绘界面」：三层渐进定位

安卓测试最头疼的自绘 UI（Canvas / Compose / Flutter），ARTEMIS 靠一套「三层渐进定位」来对付：1. 先读无障碍树 + OCR：约 150 毫秒、零 token 消耗，能覆盖 85% 以上的常规操作——原生控件用这一层就够了；2. 再上视觉模型：第一层找不到元素时退回视觉模型，专门对付自绘控件；3. 最后用沙箱 CV 探针：判断按钮是「可点」还是「置灰」、进度条到哪了，这些肉眼难判的像素级状态。这套「结构优先、视觉兜底」的思路，其实给所有做移动端自动化的人提了个醒：别再死磕一种定位方式了，让 AI 像人一样「先看结构、看不清再看画面」。

一条命令，先跑起来

上手真的很简单。环境要求就两样：一台开了 USB 调试的安卓真机（或模拟器）+ Python 3.12+。拉下代码，一条命令：

更狠的是它原生支持 MCP（Model Context Protocol）。装一下：

就能把「真机」接到 Claude Code、Cursor、Windsurf、Codex、Antigravity 这些 AI 编程环境里。你在 IDE 里直接说：

把最新代码打成 APK 装到手机上，用测试账号登录，检查登录后有没有异常弹窗，把截图发回来。

它就自己完成，顺带把 Logcat 崩溃栈和关键帧截图带回来。这个场景，才是它真正值钱的地方：把「真机验证」从「写完代码之后再找人点」，变成「写代码的同一时间，AI 顺手就验了」。

拆开看，就一条三段链路

把 ARTEMIS 的工作流拆开，是一条清清楚楚的三段链路：

注意中间那一步——它每一步都留了「操作轨迹」。这意味着 AI 测完之后，你能回放它到底点了哪、为什么这么点。这对测试的意义，比「测得快」大得多。

说清楚：它现在还不是「银弹」

官方说，`ARTEMIS` 在 `AndroidWorld` 基准上（20+ 常用 App、100+ 多步任务）完成率超过 99%。这里我要补一句实在话：这是官方在 benchmark 上宣称的成绩，不等于你在自家 App 上也能稳定拿到 99%。它更像一个「上限」的证明——说明「AI 驱动真机」这条路，已经从「能走通」走到了「能跑高分」。真要用，得拿你们自己的 App 先小范围验证。几个边界，必须说清楚：1）它补的是「探索式 / 跨 App / 自绘 UI / 长流程」的短板，不是要取代 Espresso、uiautomator2、Appium。高频回归这种要快、要稳、要零云成本的场景，传统框架依然是首选——ARTEMIS 每次都要调大模型，有 token 成本和延迟。2）99% 是 benchmark 成绩，不是商业 App 的保证。3）银行、支付类 App 风控严，容易触发验证码；部分即时通讯的自动发消息也有限制。4）目前只支持 Android，iOS 还在规划中。5）用云视觉/语言模型时，截图和界面数据会发给模型供应商——别拿有真实客户数据的主力机直接接，要用专用测试机 + 脱敏数据。

我们看见了它，但这次不推课

看到这里，你可能以为我们要推新课了。说实话，我们第一时间把它从头到尾研究了一遍，也确实被它震了一下——因为它标志着一件事：移动端自动化测试，正在从「脚本驱动」走向「意图驱动」。过去是人告诉机器「点哪个控件」，未来是人告诉机器「我想验证什么」，剩下的交给 AI。但今天这篇，我们不推课。原因很实在：ARTEMIS 是开源免费的，环境要求也不高（一台安卓机 + Python 3.12+），有动手能力的测试工程师，照着 README 半天就能跑起来。一个你现在就能自己上手的开源工具，我们如果立刻包装成收费课程卖给你，那不是在教你，是在收你的「信息差焦虑税」。而且它才刚开源，生态还在快速迭代（比如社区已经在讨论它的代码署名问题）。这个阶段，我们更愿意把它当成「AI 测试」大趋势里的一个重要观察点，持续盯着，等它和生态一起成熟。我们的态度是：技术要第一时间看见、第一时间验证、第一时间告诉你；但要不要变成课程，得等它真的沉淀出稳定的、体系化的方法论再说。这也是我们做一线软件测试培训的底线：不追着每一个新工具割韭菜，只把真正值得学的东西，做成体系教给你。

那现在，你该做什么

1. 去 `github.com/google/artemis` 看 README（有中文文档）；2. 找一台闲置安卓机，开启 USB 调试，跑一遍那条 `uv run artemis run ...` 命令；3. 先拿你们 App 里「跨 App、自绘 UI、长流程」这类传统脚本最难啃的场景试。AI 不会取代测试工程师。但一个「只会照着写好的脚本点执行」的测试工程师，和一个「能用一句话让 AI 驱动真机、还看得懂它留下的操作轨迹」的测试工程师，三年后的处境，会完全不同。你现在做安卓自动化，用的是什么框架？有没有被自绘 UI 和频繁改版折磨过？评论区聊聊，我挑几个有代表性的问题，下篇专门拆。