Maestro 移动UI自动化教程一份 YAML 跑通 Android 与 iOS 的跨平台测试【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro很多团队的移动UI自动化用例是这样的同一段登录逻辑Android 得用 Espresso 写一遍、iOS 用 XCTest 再写一遍还得防着界面动画没加载完就断言、一跑就飘。Maestro 就是冲着这个痛点来的——它是一款开源的移动UI自动化测试框架让你用一份 YAML 写测试流程同一份用例即可在 Android、iOS 和 Web 上统一跑靠解释式执行引擎自动等待省掉大量手写 sleep 和平台分支代码。 三行命令跑通首个 Maestro 测试先确认系统里有 Java 17 及以上java -version再用一条命令装好 CLI# 安装macOS / Linux / Windows WSL curl -fsSL https://get.maestro.mobile.dev | bash # 运行某个流程 maestro test flow.yaml建一个最小流程flow.yaml跑起来看效果appId: com.android.contacts --- - launchApp - tapOn: Create new contact - inputText: John - assertVisible: Johnmaestro test flow.yaml执行后CLI 会连上设备、装好应用、按顺序执行每一步最后给出通过或失败。流程无需编译改完 YAML 直接重跑——这是它和 Appium 那套先构建再跑最大的差别。Maestro 常用命令速查表先认识最常用的几个其余用到再翻官方文档命令作用最小示例launchApp启动目标应用- launchApptapOn点击元素或坐标- tapOn: SaveinputText向焦点输入文本- inputText: JohnassertVisible断言元素出现- assertVisible: DoneassertNotVisible断言元素消失- assertNotVisible: Loadingscroll滚动到目标出现- scrollrunFlow复用另一个 YAML- runFlow: login.yaml 逐行拆解一个仓库里的真实流程命令认识了看个真实例子更直观。仓库里 e2e/workspaces/wikipedia/subflows/onboarding-android.yaml 是处理 Wikipedia 首次启动引导页的流程很短但每一步都值得讲appId: org.wikipedia --- - launchApp: clearState: true - tapOn: id: org.wikipedia:id/fragment_onboarding_forward_button - tapOn: id: org.wikipedia:id/fragment_onboarding_forward_button - tapOn: id: org.wikipedia:id/fragment_onboarding_done_buttonclearState: true每次启动都清空应用状态保证一定停在引导页。最容易踩的坑就是不加它——上次已过了引导这次直接进首页后面所有点击全部扑空。用id而不是文案定位引导页下一页按钮在不同语言、不同版本里文案会变靠text匹配迟早挂id是开发写死的资源名稳定得多。连点三次forward_button引导是固定的三页写死次数比循环直到消失更可控页数将来会变再换回按文案或条件判断。收尾点done_button末页按钮 id 不同别偷懒复用前一个这里最易看错 id 点空。让用例不 flaky 的三招飘来飘去的用例八成出在这三处# 1) 定位优先 id / 稳定文案别依赖 index - tapOn: id: com.example:id/save # 2) 等待与断言用 assertVisible 顶替固定 sleep - assertVisible: 登录成功 - assertNotVisible: Loading # 3) 参数化env 注入同一文件跑多组数据 - inputText: ${USERNAME}定位能用id就用id退一步用长期不变的文案尽量避开index——列表一插入元素索引就错位。等待与断言Maestro 每步都会自动等待元素就绪把等待表达成assertVisible/assertNotVisible别写sleep猜时长猜短了飘、猜长了慢。参数化把账号、地址这类变量用${VAR}引用配合env注入同一份流程就能跑多组数据不用一组账号复制一份 YAML。仓库里 android-advanced-flow.yaml 用runScript加${output.result}就是动态取值的写法。 什么时候该从 CLI 升级到 Studio 和 CloudCLI 覆盖单机日常回归已经够用。当你开始手工排查元素Studio 提供可视化录制与元素检查不用反复跑 CLI 猜选择器或用例多到本地跑一轮要等很久Cloud 在分布式设备上并行执行、环境确定、带完整报告时再考虑往上走。两者都围绕同一套 YAML切换成本很低不必一开始就上。把 Maestro 接入 GitHub Actions把回归挂到 CI 上push 即跑最小配置长这样name: Maestro on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - run: curl -fsSL https://get.maestro.mobile.dev | bash - run: maestro test ./flows/移动端还得在 CI 里起模拟器/仿真器这一步比配置本身更花时间但一旦跑通每次提交都能自动拦一道 UI 回归。收益很实在一份 YAML 通吃 Android、iOS 与 Web用例不再因等待和定位写得随意而飘。接下来三件事就能落地把最常被复测的三条主路径登录、下单、支付先搬成 YAML 跑起来用runFlow把公共步骤抽成子流程再挑一个流程接入 CI让每次 push 自动回归。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Maestro 移动UI自动化教程：一份 YAML 跑通 Android 与 iOS 的跨平台测试
Maestro 移动UI自动化教程一份 YAML 跑通 Android 与 iOS 的跨平台测试【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro很多团队的移动UI自动化用例是这样的同一段登录逻辑Android 得用 Espresso 写一遍、iOS 用 XCTest 再写一遍还得防着界面动画没加载完就断言、一跑就飘。Maestro 就是冲着这个痛点来的——它是一款开源的移动UI自动化测试框架让你用一份 YAML 写测试流程同一份用例即可在 Android、iOS 和 Web 上统一跑靠解释式执行引擎自动等待省掉大量手写 sleep 和平台分支代码。 三行命令跑通首个 Maestro 测试先确认系统里有 Java 17 及以上java -version再用一条命令装好 CLI# 安装macOS / Linux / Windows WSL curl -fsSL https://get.maestro.mobile.dev | bash # 运行某个流程 maestro test flow.yaml建一个最小流程flow.yaml跑起来看效果appId: com.android.contacts --- - launchApp - tapOn: Create new contact - inputText: John - assertVisible: Johnmaestro test flow.yaml执行后CLI 会连上设备、装好应用、按顺序执行每一步最后给出通过或失败。流程无需编译改完 YAML 直接重跑——这是它和 Appium 那套先构建再跑最大的差别。Maestro 常用命令速查表先认识最常用的几个其余用到再翻官方文档命令作用最小示例launchApp启动目标应用- launchApptapOn点击元素或坐标- tapOn: SaveinputText向焦点输入文本- inputText: JohnassertVisible断言元素出现- assertVisible: DoneassertNotVisible断言元素消失- assertNotVisible: Loadingscroll滚动到目标出现- scrollrunFlow复用另一个 YAML- runFlow: login.yaml 逐行拆解一个仓库里的真实流程命令认识了看个真实例子更直观。仓库里 e2e/workspaces/wikipedia/subflows/onboarding-android.yaml 是处理 Wikipedia 首次启动引导页的流程很短但每一步都值得讲appId: org.wikipedia --- - launchApp: clearState: true - tapOn: id: org.wikipedia:id/fragment_onboarding_forward_button - tapOn: id: org.wikipedia:id/fragment_onboarding_forward_button - tapOn: id: org.wikipedia:id/fragment_onboarding_done_buttonclearState: true每次启动都清空应用状态保证一定停在引导页。最容易踩的坑就是不加它——上次已过了引导这次直接进首页后面所有点击全部扑空。用id而不是文案定位引导页下一页按钮在不同语言、不同版本里文案会变靠text匹配迟早挂id是开发写死的资源名稳定得多。连点三次forward_button引导是固定的三页写死次数比循环直到消失更可控页数将来会变再换回按文案或条件判断。收尾点done_button末页按钮 id 不同别偷懒复用前一个这里最易看错 id 点空。让用例不 flaky 的三招飘来飘去的用例八成出在这三处# 1) 定位优先 id / 稳定文案别依赖 index - tapOn: id: com.example:id/save # 2) 等待与断言用 assertVisible 顶替固定 sleep - assertVisible: 登录成功 - assertNotVisible: Loading # 3) 参数化env 注入同一文件跑多组数据 - inputText: ${USERNAME}定位能用id就用id退一步用长期不变的文案尽量避开index——列表一插入元素索引就错位。等待与断言Maestro 每步都会自动等待元素就绪把等待表达成assertVisible/assertNotVisible别写sleep猜时长猜短了飘、猜长了慢。参数化把账号、地址这类变量用${VAR}引用配合env注入同一份流程就能跑多组数据不用一组账号复制一份 YAML。仓库里 android-advanced-flow.yaml 用runScript加${output.result}就是动态取值的写法。 什么时候该从 CLI 升级到 Studio 和 CloudCLI 覆盖单机日常回归已经够用。当你开始手工排查元素Studio 提供可视化录制与元素检查不用反复跑 CLI 猜选择器或用例多到本地跑一轮要等很久Cloud 在分布式设备上并行执行、环境确定、带完整报告时再考虑往上走。两者都围绕同一套 YAML切换成本很低不必一开始就上。把 Maestro 接入 GitHub Actions把回归挂到 CI 上push 即跑最小配置长这样name: Maestro on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - run: curl -fsSL https://get.maestro.mobile.dev | bash - run: maestro test ./flows/移动端还得在 CI 里起模拟器/仿真器这一步比配置本身更花时间但一旦跑通每次提交都能自动拦一道 UI 回归。收益很实在一份 YAML 通吃 Android、iOS 与 Web用例不再因等待和定位写得随意而飘。接下来三件事就能落地把最常被复测的三条主路径登录、下单、支付先搬成 YAML 跑起来用runFlow把公共步骤抽成子流程再挑一个流程接入 CI让每次 push 自动回归。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考