企业官网建设流程全解析

Maestro：用 YAML 脚本驱动 Android、iOS 与 Web 的跨平台 UI 自动化

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

同一个 App，安卓和 iOS 各维护一套 UI 测试脚本，改一次按钮文案要同步改两份，Web 端还得再写一套 Selenium 用例。Maestro 用一份 YAML 脚本统一描述测试流程，在 Android 模拟器、iOS 模拟器和浏览器上执行同一套操作与断言，把三套脚本的维护成本压成一套。

它是什么，为什么选它

一句话定位

Maestro 是一个开源的 UI 与端到端测试框架：你用人类可读的 YAML 编写测试流程，它解释执行这些命令，覆盖 Android、iOS 和 Web（含 React Native、Flutter、混合应用）三大平台，跑在模拟器、真机或浏览器上均可。

三个值得注意的特性

相比 Appium、Espresso、XCTest、Selenium 这类各占一个生态的成熟工具，Maestro 的定位是把"写跨端 E2E 脚本"这件事的门槛降到最低：语法统一为几类命令动词，学习成本以小时计。它建立在上述前者的实践经验之上，官方 README 中明确列出了这一背景。

五分钟搭好环境

前置要求只有三项：

• Java 17 或更高版本（java -version确认）
• macOS、Linux 或 Windows（WSL）
• 一个可用的模拟器、真机或浏览器

安装命令只有一条（bash）：

curl -fsSL "https://get.maestro.mobile.dev" | bash

执行后确认maestro命令可用即可，例如查看maestro --version输出的版本号。各平台的差异集中在安装渠道：

核心语法：从拉起应用到断言校验

按一个用例的生命周期看，Maestro 的语法就四类命令。

拉起应用与环境准备

appId: org.wikipedia --- - launchApp: clearState: true

appId声明被测应用，---之后是流程体。clearState: true会清掉应用既有状态再启动，让每次执行从干净环境开始——这是避免"上一条用例的登录态污染这一条"最便宜的手段。Web 应用则用url代替appId，仓库示例可参考 e2e/workspaces/web/simple.yaml。

与界面元素交互

- tapOn: "First Name" - inputText: "John" - tapOn: "Last Name" - inputText: "Snow" - tapOn: "Save"

点击、输入都以"屏幕上看得见的文本"作为定位依据，这比写id或 CSS 选择器直观，也更抗 UI 重构。除tapOn、inputText外，还有一组常用动词：swipe/swipeDirection滑动、scrollUntilVisible滚动查找、back返回、pressKey模拟按键。

条件分支与数据构造

- if: visible: "验证码" then: - inputText: "123456" else: - tapOn: "跳过"

if/then/else让脚本能跟上应用的多分支走向，而不是把"一定走到哪个页面"写死。配合launchApp: { clearState: true }固定起点，再用分支消化不可控的弹层（如隐私弹窗），比在流程外做环境约定更稳。

断言与结果校验

- assertVisible: Products - assertNotVisible: "Nothing typed yet"

assertVisible确认关键元素出现，assertNotVisible确认不该出现的元素消失了，两者配对使用能覆盖"页面跳转成功"这类完整语义。断言同样走智能等待，元素没出现会等，而不是立刻判死。

一个完整用例的拆解

以下两条用例测的是经典演示站点 saucedemo 的登录流程：正向用例预期输入正确账号密码后进入商品列表页；异常用例预期错误账号登录后停留在登录页并出现报错提示。仓库中正向脚本的完整版本见 e2e/workspaces/web/simple.yaml。

正向流程：

url: https://www.saucedemo.com/ tags: [login, positive] --- - launchApp - tapOn: Username - inputText: standard_user - tapOn: Password - inputText: secret_sauce - tapOn: Login - assertVisible: Products - assertVisible: Sauce Labs Backpack

异常流程：

url: https://www.saucedemo.com/ tags: [login, negative] --- - launchApp - tapOn: Username - inputText: locked_out_user - tapOn: Password - inputText: secret_sauce - tapOn: Login - assertVisible: E

两条用例的关键断言都在最后一行：正向看Products是否出现，异常看锁号提示是否出现。前面所有操作都是铺垫，断言行才是用例真正的验收标准——用例名和断言行对得上，失败时看一眼输出就知道断在哪里。

脚本跑不稳？先查这三处

元素找不到：定位策略的优先级

定位写法有优先级：可读文本 →id→ 坐标类兜底。文本丢失或不可见时，改用框架级id定位，例如 e2e/workspaces/wikipedia/subflows/onboarding-android.yaml 中用org.wikipedia:id/fragment_onboarding_forward_button这类稳定资源 id。对于"可能出现也可能不出现"的元素（如首次启动引导），用optional: true让它找不到时不报错：

- tapOn: text: "Non existent view" optional: true

断言偶发失败：超时怎么定

assertVisible支持显式timeout参数，慢页面把默认等待拉长而不是加 sleep，例如 e2e/workspaces/simple_web_view/webview.yaml 中给登录断言设了timeout: 90000应对 WebView 冷启动。判断标准：先观察该步骤在慢设备上的实际耗时，取 2 倍余量；如果两次运行耗时波动大，问题多半在上游步骤没断言住，而不是这里该再加超时。

- assertVisible: text: "Login" timeout: 90000

环境残留：状态清理与隔离

用例间最常见的串扰是登录态、购物车这类持久状态。做法是在launchApp时清状态，流程中途也可用独立的clearState命令复位，再重新拉起应用验证已回到初始界面，参考 e2e/workspaces/web/clear_state.yaml：

- launchApp: clearState: true # ...执行登录... - clearState - launchApp - assertNotVisible: Products

assertNotVisible: Products反向确认清理真的生效了，这一步别省。

它适合什么、不适合什么

Maestro 适合做端到端的 UI 层验证：核心链路冒烟、发版前回归、跨平台一致性比对，尤其适合团队里不全是自动化背景的成员补测试。它不适合做纯接口压测，也不擅长高频性能采样——它每次执行都是真实拉起应用，单次耗时在秒级以上，用例数量上去后需要按设备矩阵或并行执行来分摊。UI 深层组件级测试（如 Espresso 级别的视图状态验证）仍建议留给各平台原生框架，Maestro 承担跨端主线即可。

结语

回到开头那个场景：同一套登录流程，现在是一份 YAML 在三个平台上跑，改文案只改一处。脚本跑通之前，先把 README.md 里的示例 flow 跑一遍。

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