一份 YAML 脚本跑通 Android、iOS 与 Web:Maestro UI 自动化测试快速上手指南

发布时间:2026/9/11 12:23:12
一份 YAML 脚本跑通 Android、iOS 与 Web:Maestro UI 自动化测试快速上手指南 一份 YAML 脚本跑通 Android、iOS 与 WebMaestro UI 自动化测试快速上手指南【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro如果你同时在维护 Android、iOS 和 Web 三套 UI 测试多半体会过同一行断言要抄三遍、一个定位符改动全线崩的滋味。Maestro 是一个用 YAML 脚本驱动的 UI 自动化测试框架让同一份 flow 能在模拟器、真机和浏览器里直接跑起来。这篇文章按我实际落地的过程从装环境到写脚本、从登录演练到排错尽量给你能照做的步骤而不是一堆概念名词。一个改了三遍的登录用例让我重新看待跨平台测试去年我们有个电商 App登录页的记住密码复选框偶尔加载慢点一下就报元素未找到。为了压住它我在三个平台各塞了一堆 sleepAndroid 用 Espresso 的 wait、iOS 用 XCTest 的 polling、Web 又回到 Selenium 的 WebDriverWait。三套代码三套等待逻辑复选框一改版三处都要动。更麻烦的是三个平台的定位策略还不一样——Android 认 resource-id、iOS 认 accessibility label、Web 认 CSS 选择器同一个登录按钮我记着三套写法。那种感觉不是写测试是维护三份翻译稿。真正卡住效率的不是写第一条用例而是第 N 条改动时你不知道还要同步改几处。Maestro 是什么一份 flow三端复用Maestro 的思路很克制把一次 UI 交互写成一行 YAML 命令launchApp、tapOn、inputText、assertVisible交给解释器直接执行不用编译。它不替代底层而是在 Android、iOS、Web 之上做统一抽象——你写点击文本为 登录 的元素它负责在各端去匹配对应的控件。等待也是内置的断言和交互会反复轮询直到元素就绪或超时所以大多数动态页面不用再手写 sleep。对 Flutter、React Native 这类跨端框架尤其友好因为它们的控件文本在两端本就一致。五分钟跑通第一个测试安装与最小脚本环境只要一个前置Java 17 或更高先java -version确认。安装本身是一条命令macOS、Linux、WindowsWSL通用curl -fsSL https://get.maestro.mobile.dev | bash maestro --version装完就能跑。我的习惯是先拿一个系统自带的 App 当练手不依赖自己项目的构建。下面这份最小脚本用 Android 的联系人 App七行就能验证点、填、断是否都通appId: com.android.contacts --- - launchApp - tapOn: Create new contact - tapOn: First Name - inputText: John - tapOn: Last Name - inputText: Snow - tapOn: Save保存到flow.yaml然后maestro test flow.yaml。看到流程跑完、断言通过就说明 CLI、设备、元素匹配这条链路是通的。仓库里 e2e/workspaces/web/ 下还有一批现成的样例 flow 可以直接拿来试适合你还没写好第一条用例时先照着跑。三种 YAML 写法点、等、算跑通最小脚本后真正常用的其实是三类写法各给个短例。基础交互就是上面那份最小脚本的形态tapOn按文本或id:定位inputText填进当前焦点框assertVisible确认出现。定位尽量用用户能看到的文本而不是内部控件树这样 UI 迭代时更抗变更。条件分支用来对付有时出现、有时不出现的元素比如验证码。注意optional: true可以让某一步找不到时不报错- if: visible: 验证码 then: - inputText: 123456 else: - tapOn: 跳过数据处理解决每次要一个不同的值这类需求。Maestro 允许用runScript跑一段脚本再把结果通过${output.xxx}注入后续步骤随机邮箱、动态查询词都这么来- runScript: scripts/getQuery.js - inputText: ${output.result} - assertVisible: ${output.result}把登录的正反流程串成一条线理解了上面三种写法就能把一条完整的登录链路写下来。正常流程从清状态启动开始逐项填账号密码最后断言首页元素一共不到十行appId: com.example.ecommerce --- - launchApp: clearState: true - tapOn: 我的账户 - tapOn: Username - inputText: standard_user - tapOn: Password - inputText: secret_sauce - tapOn: 登录 - assertVisible: 我的订单异常流程复用同一段头部只改账号和最后的断言——这也是同一份逻辑三端复用最省事的地方改动集中在几行- tapOn: Username - inputText: locked_out_user - tapOn: 登录 - assertVisible: 您的账户已被锁定两段可以拆成两个 flow 文件、用标签区分positive/negative也可以放进同一个 flow 里顺序执行。我一般拆文件因为一个失败不该连累另一个的结果统计。跑不通时先查这三处流程报Element not found别急着加 sleep我按这个顺序排查命中率最高设备到底连没连上。先maestro list-devices确认 CLI 看得见目标设备或模拟器Web 端则要确认页面服务已经起好否则launchApp会对一个无效端口成功报错却指向无关的元素。你写的文本和界面真实节点对得上吗。用maestro print-hierarchy把当前视图树打出来逐字核对你要点的文本、id:是否一致——大小写和全角空格是最常见的坑。YAML 本身或超时问题。maestro check-syntax flow.yaml先排除语法确认是还没加载出来再加timeout而不是无限等待。仓库里这些子命令的实现都能在 maestro-cli/src/main/java/maestro/cli/command/ 下对照排错时能帮你确认参数名没写错。实在看不出来maestro record会带你可视化地走一遍你看到的控件就是它要匹配的控件比对着报错猜要快得多。适合谁用一句话收个尾如果你要的是一份脚本同时覆盖移动端和 Web、少维护底层差异、少和等待机制搏斗Maestro 这套 YAML 驱动的方案就够用了要是你的测试还停在纯单元层它也不是必需品。上手门槛主要在把想验证的步骤写清楚而不是学一门测试语言。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考