零基础实战用 Maestro 从零跑通第一个跨平台 UI 自动化用例【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro凌晨一点CI 里那条登录测试又红了而本地明明刚才是绿的。你盯着日志里那句Element not found页面在真机上还好好显示着用例却就是找不到。如果你也被这种偶发失败折磨过可以试试Maestro一个开源的跨平台 UI 自动化测试框架你用一份 YAML 用例描述测试步骤同一份用例可以在 Android、iOS、Web 上运行框架内置的智能等待还会替你盯住没加载出来的元素。按这篇教程从头走到尾你手上会有一条在真模拟器上跑通的登录流程用例外加把它改稳、改到 Web 端的具体做法。先看最终成品一条 8 行的登录用例 在装任何东西之前先看看你要做出的东西长什么样——整个测试就是一个几行长的 YAML 文件appId: com.example.shop tags: - login --- - launchApp: clearState: true - tapOn: 登录 - inputText: standard_user - inputText: secret_sauce - tapOn: 确认登录 - assertVisible: 我的订单就这么几行启动应用、输入账号密码、点进订单页、验证页面出现全部完成。下面从环境开始把这条用例从头走到尾。环境一步装好并验证前置条件只有一个Java 17 或更高版本Maestro 本身是 Java 写的跑它需要 JVM 在场。macOS、Linux、WindowsWSL都行共三步java -version确认当前环境的 Java 版本不低于 17低于就先把 JDK 升到 17 再往下走。curl -fsSL https://get.maestro.mobile.dev | bash export PATH$PATH:$HOME/.maestro/bin第一条命令下载并执行官方安装脚本第二条把安装目录挂进当前终端的PATH让 shell 能找到maestro命令——新开终端时记得重复这一步或把export写进你的 shell 配置。maestro --version能打印出版本号环境就算就绪了。到这一步不需要装 SDK、不需要配驱动安装就是一个二进制。逐行拆解最小可运行用例长什么样回到上面那条用例它的结构分两半---之前是头部之后是步骤。头部声明被测目标。appId写应用的包名iOS 应用则是 bundle id——这一步告诉 Maestro 要驱动哪个应用tags给用例打标签后续可以按标签筛选运行比如把所有login标签的用例挑出来单独跑。launchApp负责把应用拉起来。这里的clearState: true值得留意它会清掉应用上一次的运行状态再启动保证每次测试都从一张白纸开始避免残留的登录态、购物车这类脏数据干扰结果。tapOn按文本定位元素。你写的是文本为『登录』的元素不是屏幕坐标也不是层层嵌套的选择器路径。定位基于元素上可见的文本与语义信息所以页面换肤、排版微调时只要文案还在用例就还成立——这也是同一份 YAML 能同时跑在 Android、iOS、Web 三个端上的原因。inputText把文本填进当前激活的输入框。连续两条inputText分别对应用户名和密码不需要额外指定填进哪个框。assertVisible是断言也是全篇最关键的一步。它等文本为我的订单的元素出现出现才算通过等待耗尽没出现就报失败。注意这个等待是框架自动做的智能等待——你不需要手写sleep也不用猜页面要加载多久。读下来你会发现整条用例就是一句白话启动应用 → 点登录 → 输账号密码 → 提交 → 验证到了订单页。如果流程里需要分支用if/then/else表达。比如某个弹窗只在特定状态下出现就可以写成当同意按钮可见时点击它否则跳过——判断条件通常就是某个元素是否可见。让用例跑稳红灯的两种病因 用例跑通之后真正折磨人的是两种失败偶尔变红和死活找不到元素。它们成因不同解法也不同。偶尔变红把等待写明确这条断言本地十次红一次多数时候是页面重渲染、网络慢半拍这类时序问题不是逻辑写错了。两个手段可以明确等待的行为- retry: maxRetries: 2 commands: - assertVisible: 加载完成 - assertVisible: text: 支付成功 timeout: 15000retry把不稳的步骤包起来整组最多重试maxRetries次timeout把单条断言的等待上限从默认值拉长到 15 秒单位毫秒。但要说清楚边界这是等得更久不是无限等。超了时仍然变红问题就不在等待时长而在断言本身或前置步骤——继续加码等待只是把失败推迟不会把失败修好。仓库里e2e/workspaces/simple_web_view/webview.yaml就是这个思路的真实例子对一个偶发被吞掉的点击套retry再接extendedWaitUntil把等待上限拉到 90 秒并配上说明标签。找不到元素按成本从低到高的排查顺序Element not found 大多数时候不是元素真的消失而是定位条件给得太死。按排查成本从低到高走三步换成模糊匹配。文本里带单号、时间戳这类动态内容时别整串精确匹配用contains只钉住其中一段- tapOn: text: contains: 订单用父子层级限定范围。页面上有多个同文本元素两个提交时加parent把搜索范围限到指定父容器里目标立刻唯一。确认前置状态成立。页面可能根本没翻到正确位置或应用状态被前一条用例污染了。给launchApp加上clearState: true在干净环境里重跑一次问题消失说明要显式固定初始状态。同一用例上 Web换一个头部就够 移动端和 Web 端的差别只在头部那一行移动端用appId声明包名Web 端改用url字段直接指向页面地址后面的launchApp、tapOn、inputText与移动端完全同构——逻辑只写一遍元素在各端找得到就行。仓库里e2e/workspaces/web/simple.yaml就是一份现成的 Web 用例头部是url: https://www.saucedemo.com/之后输入用户名密码、点 Login断言商品列表出现和前面那条登录用例的结构一一对应。另外提一句如果用例要反复造随机测试数据比如注册接口需要一个不重样的邮箱用inputRandomEmail、inputRandomNumber这类命令在运行时现场生成不必把测试数据写死在用例里。交接前对照这份清单收尾一条用例能跑和可以交给别人或 CI 的用例集之间还差几件事。逐条打勾☑单平台连续 10 次全绿在 Android 或 iOS 模拟器上连跑 10 遍零失败。☑负向分支已覆盖用一个会被拒绝的账号跑通断言的是错误提示出现而不是用例卡死。☑Web 版本改写完成同一套步骤用url头部跑通浏览器端。☑偶发失败的断言已加retry或timeout且观察 20 次以上不再单独变红。☑随机数据不落盘账号、邮箱等测试数据用运行时生成不写死在用例里。五条全勾上之后真正值得盯的目标就一个同一条 Maestro 用例在 Android、iOS、Web 三个端上轮流跑稳定变绿——到那时这份 YAML 才配叫跨平台。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考