Maestro AI 测试实战：从一句话描述到跨平台 UI 测试脚本-开发者社区

Maestro AI 测试实战：从一句话描述到跨平台 UI 测试脚本

【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro

一条登录流程的 UI 测试，你上次改定位器是什么时候？如果答案是"上次需求一动就炸"，那么 Maestro 的 AI 测试能力值得认真看一眼：它把"描述你要验证什么"这件事交给了大模型，脚本只保留最关键的意图。Maestro 本身是一个移动 UI 自动化工具，用 YAML 描述操作流程；而它的 maestro-ai 模块让这份 YAML 里可以出现自然语言断言，还能让 AI 直接替你判断截图里有没有视觉缺陷。

🧠 一句描述是怎么变成可执行步骤的

不用上来就画架构图，跟着一次调用走一遍更清楚。

你写下一句"页面上应该有一只可爱的兔子"，Maestro 把这句话连同当前屏幕截图交给模型，模型返回判断结果，执行器据此决定测试通过还是失败。这里 maestro-ai 是"库 + 演示应用"的双重身份：作为库，它封装了与 OpenAI、Anthropic 两家模型的对话逻辑，你只需要一个环境变量注入密钥；作为演示应用，它提供独立的命令行入口，方便你单独调试提示词、查看模型的原始返回。

另一边，MCP 服务器负责"动手"的部分。它向模型暴露了一组工具：list_devices、take_screenshot、run、inspect_screen、cheat_sheet、list_cloud_devices、run_on_cloud、get_cloud_run_status——设备管理、截图、跑流程、查文档，模型要做什么都得通过这几个入口。模型说"我需要看一眼当前屏幕"，MCP 就去抓截图；说"帮我跑 setup/flows 里的某个流程"，MCP 就执行并回传结果。

别小看这套评估机制。项目里有一份 MCP 的 LLM 评估配置 full-evals.yaml，它给每类任务配了"模型评分员"（LLM-Judge）：模型的回答会被另一个模型按评分标准打分，并设了明确的通过阈值，从 0.6 到 1.0 视任务而定，达不到标准就算失败。换句话说，AI 的每次决策都有质检，而不是"模型说行就行"。

🎬 三个你大概率马上会用的场景

先让 AI 替你看图。视觉回归测试过去要么像素比对、要么人工巡检。Maestro 在 demo 应用的工作区里就有一个现成用例：先启动应用并清掉状态，点进 Defects 测试页，然后一行assertNoDefectsWithAI让模型判断"这屏有没有渲染崩坏、文字截断"，再补一句自然语言断言确认关键画面存在。

- launchApp: clearState: true - tapOn: Defects Test - assertNoDefectsWithAI: optional: true - assertWithAI: A picture of a cute bunny is visible

效果就是：截图异常时测试直接红掉，而"兔子在不在画面里"这种传统断言很难写的事，变成了一句话。

让 AI 替你写断言。这是改动定位成本最低的一块。你不用关心控件树长什么样，直接把验收标准写成人话，Maestro 会结合界面层级去验证。

- launchApp: clearState: true - assertWithAI: optional: true assertion: A login screen is visible

就这么简单。界面改版后，只要"能看到登录屏"这件事还成立，断言就不需要动。

跨平台不用改两遍。项目自带的维基百科工作区是最直观的例子：android-flow.yaml 和 ios-flow.yaml 描述的是同一套验收意图，配合 subflows/ 里的平台子流程处理启动差异。Android 的"返回键"和 iOS 的"边缘滑动返回"这类平台特有交互，被隔离在各自子流程里，主流程保持平台无关。测试工程师不用在两套脚本之间来回翻译需求。

⚙️ 不稳和太贵，Maestro 怎么扛

问题：移动端 UI 测试出了名的"毛刺多"，而每次调大模型又是一笔真金白银的 API 开销。

应对：稳定性上，extendedWaitUntil 让你给元素查找单独放宽超时（demo 用例里从 100ms 到 90 秒都有），避免"页面还没渲染完就判死"；retry命令则给易失败步骤套上重试，内置状态稳定检测（约 40ms 的 settle 判断），重试前先确认界面不再变动。成本上，设计思路是三级过滤：重复场景复用历史分析结果，简单断言路由到 Haiku 级别的轻量模型，只对界面变化区域做增量分析来压缩 Token。

对你的实际影响：CI 里的 AI 断言不会因为一次动画没播完而误报，账单也不会因为"每张截图都问一遍 GPT"而失控。想本地体验的话，两条命令够用了：

./gradlew :maestro-ai:installDist export MAESTRO_CLI_AI_KEY=your_key_here

🔭 这意味着什么

多模态、自修复、开发者协同，这三件事听起来分散，指向的其实是同一个方向：测试脚本的寿命开始和"界面长相"解耦。当 AI 能理解语音交互、能在 UI 变动后自己分析新结构并更新定位策略、能在 Maestro Studio 里根据你的一句话直接生成并调试用例时，UI 测试维护就从"每次发版后的救火"变成"偶尔抽查"。这意味着移动 UI 自动化的瓶颈，正从"写脚本的人"转移到"描述需求的人"——而后者，恰恰是每个开发都擅长的事。

以前是改一行 UI、翻遍测试目录找定位器；以后大概率是改完 UI，跑一遍测试，看 AI 有没有挑出毛病。

贡献入口：CONTRIBUTING.md