尧图网站建设 
Maestro 跨平台 UI 自动化测试实战一份 YAML 脚本一次跑通三端【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro这是一份面向 UI 测试开发者的 Maestro 实战指南。Maestro 用 YAML 描述测试步骤同一份脚本能在 Android、iOS、Web 三端运行并内置智能等待。读完你能独立做完四件事验证环境是否就绪、写出第一条可运行的登录用例、把偶发断言拉稳、看懂元素定位失败时的排查路径。全文按先建立执行模型再跑绿最后排查的顺序展开命令与字段名保留英文原形。内容预览先建立执行模型理解脚本为什么能跨端、等待为什么不用手写 sleep三条命令完成环境自检把一次真实登录行为翻译成一条 Flow元素定位从宽到紧的三层条件用 retry 与 timeout 两个旋钮拉稳偶发断言appId 与 url同一份逻辑的两种写法跑绿之前过一遍自检清单它凭什么能一份脚本跑三端在动手前先建立一个能预测的执行模型。你只需要记住两件事流程是被解释执行的元素定位走的是无障碍层而不是选择器路径。理解这两点后面遇到的多数为什么都有答案。脚本被解释执行不经过编译一条 Flow 就是一个 YAML 文件逐行解释、改完即跑。没有构建步骤也就没有改了没生效的错觉。这让迭代循环很短编辑、运行、看结果、再编辑。定位走无障碍层不写选择器路径你写的是文本为『登录』的元素而不是//LinearLayout[2]/Button这种脆弱路径。UI 改版只动内部结构时只要文本没变脚本就不需要跟着改。跨端的含义也在这里逻辑只写一遍元素在各端找得到就行。[!TIP] 判断一条脚本抗不抗改看它依赖的是文本与语义还是层级深度。越贴近用户看到的文本越稳定。环境自检三条命令确认能开工前置条件只有一个Java 17 或更高版本。用java -version确认版本号低于 17 就先升级。macOS、Linux、WindowsWSL都支持。下面三步跑官方安装脚本、把安装目录加入PATH、用版本命令确认能打印出来。看到版本号环境就算就绪。java -version curl -fsSL https://get.maestro.mobile.dev | bash maestro --version如果maestro --version报 command not found通常是 PATH 没生效补一行export PATH$PATH:$HOME/.maestro/bin再试一次即可。把登录行为翻译成一条 Flow 一条用例就是一次真实登录的逐字记录。头部声明appId移动端包名和tags---之后是逐步执行的命令。先认清四种基本动作后面所有用例都由它们组合而成。命令的四种基本动作命令作用launchApp启动应用加clearState: true可清状态tapOn点击指定文本的元素inputText输入文本assertVisible断言元素可见找不到则失败用这四种动作写出的最小登录用例如下成功标准是最后一条assertVisible变绿appId: com.example.ecommerce tags: - login - positive --- - launchApp: clearState: true - tapOn: 我的账户 - inputText: standard_user - inputText: secret_sauce - tapOn: 登录 - assertVisible: 我的订单分支用 if 处理验证码流程里要做条件判断用if / then / else。例如仅当验证码元素可见时输入验证码否则点击跳过验证。异常路径同理把输入换成锁定账号、末尾断言错误提示即可两条用例步骤结构相同只是数据不同。- if: 验证码 then: - tapOn: 验证码 - inputText: 123456 else: - tapOn: 跳过验证元素定位从宽到紧的三层条件 Element not found 通常不是元素不存在而是定位条件给得太死。按排查成本从低到高走三层能停就停。第一层把精确匹配换成模糊匹配。文本里带单号、时间这类动态内容时用contains只匹配其中一段- tapOn: text: contains: 登录第二层用 parent 收窄范围。多个元素文本相同比如两个提交时加上parent把范围限定到父容器里。第三层确认前置条件成立。页面可能根本没翻到正确位置或应用状态被污染。给launchApp加clearState: true用干净环境复现一次排除状态干扰。[!WARNING] 别一开始就加 timeout 或 sleep 来等它出现。定位不到九成是条件问题先改定位再谈等待顺序反了会掩盖真正的 bug。偶发断言两个旋钮把等待拉稳最常见的不稳定来自页面还没加载完元素没出现。Maestro 默认会自动等元素多数情况无需处理。当某条断言仍然偶尔变红有两个明确作用的旋钮。retry是带间隔重试 N 次timeout是抬高单步等待上限。注意这是等更久不是一直等——超时后依然失败就该回头检查用例本身而不是继续加码等待。- retry: maxAttempts: 3 interval: 1000 command: assertVisible: 加载完成 - assertVisible: text: 支付成功 timeout: 10000第一段让断言最多重试 3 次、每次间隔 1 秒第二段把单条断言的等待上限拉到 10 秒。若某条用例反复需要加这两个旋钮多半说明前置状态没对齐优先查clearState。一份逻辑两端的字段差异移动端和 Web 端的步骤写法完全同构差别只在头部声明。移动端用appId指包名Web 端则以url字段开头指向页面地址。仓库里的e2e/workspaces/web/simple.yaml就是一个真实示例结构如下url: https://www.saucedemo.com/ tags: - web --- - launchApp - tapOn: Username - inputText: standard_user - tapOn: Password - inputText: secret_sauce - tapOn: Login - assertVisible: Products维度移动端Web 端入口字段appId包名url页面地址元素来源无障碍层文本页面文本 / DOM步骤写法同左同左用例需要反复造随机数据时还有inputRandomEmail、inputRandomNumber这类命令运行时现生成邮箱或指定范围内的数字不必把测试数据写死在脚本里。跑绿之前的自检清单把一条用例变成能交给 CI 的稳定用例按下面顺序过一遍先在单一平台把登录跑绿再补一条负向分支锁定账号后断言错误提示然后把同一流程改写成 Web 版本、用url验证通过最后给偶发失败的断言套上retry观察是否变稳。三件事做完你就有一组最小可交接的用例集。到那时真正的下一步不是继续堆用例数量而是确认这几条在 Android、iOS、Web 三端都稳定变绿。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Maestro 跨平台 UI 自动化测试实战：一份 YAML 脚本一次跑通三端
Maestro 跨平台 UI 自动化测试实战一份 YAML 脚本一次跑通三端【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro这是一份面向 UI 测试开发者的 Maestro 实战指南。Maestro 用 YAML 描述测试步骤同一份脚本能在 Android、iOS、Web 三端运行并内置智能等待。读完你能独立做完四件事验证环境是否就绪、写出第一条可运行的登录用例、把偶发断言拉稳、看懂元素定位失败时的排查路径。全文按先建立执行模型再跑绿最后排查的顺序展开命令与字段名保留英文原形。内容预览先建立执行模型理解脚本为什么能跨端、等待为什么不用手写 sleep三条命令完成环境自检把一次真实登录行为翻译成一条 Flow元素定位从宽到紧的三层条件用 retry 与 timeout 两个旋钮拉稳偶发断言appId 与 url同一份逻辑的两种写法跑绿之前过一遍自检清单它凭什么能一份脚本跑三端在动手前先建立一个能预测的执行模型。你只需要记住两件事流程是被解释执行的元素定位走的是无障碍层而不是选择器路径。理解这两点后面遇到的多数为什么都有答案。脚本被解释执行不经过编译一条 Flow 就是一个 YAML 文件逐行解释、改完即跑。没有构建步骤也就没有改了没生效的错觉。这让迭代循环很短编辑、运行、看结果、再编辑。定位走无障碍层不写选择器路径你写的是文本为『登录』的元素而不是//LinearLayout[2]/Button这种脆弱路径。UI 改版只动内部结构时只要文本没变脚本就不需要跟着改。跨端的含义也在这里逻辑只写一遍元素在各端找得到就行。[!TIP] 判断一条脚本抗不抗改看它依赖的是文本与语义还是层级深度。越贴近用户看到的文本越稳定。环境自检三条命令确认能开工前置条件只有一个Java 17 或更高版本。用java -version确认版本号低于 17 就先升级。macOS、Linux、WindowsWSL都支持。下面三步跑官方安装脚本、把安装目录加入PATH、用版本命令确认能打印出来。看到版本号环境就算就绪。java -version curl -fsSL https://get.maestro.mobile.dev | bash maestro --version如果maestro --version报 command not found通常是 PATH 没生效补一行export PATH$PATH:$HOME/.maestro/bin再试一次即可。把登录行为翻译成一条 Flow 一条用例就是一次真实登录的逐字记录。头部声明appId移动端包名和tags---之后是逐步执行的命令。先认清四种基本动作后面所有用例都由它们组合而成。命令的四种基本动作命令作用launchApp启动应用加clearState: true可清状态tapOn点击指定文本的元素inputText输入文本assertVisible断言元素可见找不到则失败用这四种动作写出的最小登录用例如下成功标准是最后一条assertVisible变绿appId: com.example.ecommerce tags: - login - positive --- - launchApp: clearState: true - tapOn: 我的账户 - inputText: standard_user - inputText: secret_sauce - tapOn: 登录 - assertVisible: 我的订单分支用 if 处理验证码流程里要做条件判断用if / then / else。例如仅当验证码元素可见时输入验证码否则点击跳过验证。异常路径同理把输入换成锁定账号、末尾断言错误提示即可两条用例步骤结构相同只是数据不同。- if: 验证码 then: - tapOn: 验证码 - inputText: 123456 else: - tapOn: 跳过验证元素定位从宽到紧的三层条件 Element not found 通常不是元素不存在而是定位条件给得太死。按排查成本从低到高走三层能停就停。第一层把精确匹配换成模糊匹配。文本里带单号、时间这类动态内容时用contains只匹配其中一段- tapOn: text: contains: 登录第二层用 parent 收窄范围。多个元素文本相同比如两个提交时加上parent把范围限定到父容器里。第三层确认前置条件成立。页面可能根本没翻到正确位置或应用状态被污染。给launchApp加clearState: true用干净环境复现一次排除状态干扰。[!WARNING] 别一开始就加 timeout 或 sleep 来等它出现。定位不到九成是条件问题先改定位再谈等待顺序反了会掩盖真正的 bug。偶发断言两个旋钮把等待拉稳最常见的不稳定来自页面还没加载完元素没出现。Maestro 默认会自动等元素多数情况无需处理。当某条断言仍然偶尔变红有两个明确作用的旋钮。retry是带间隔重试 N 次timeout是抬高单步等待上限。注意这是等更久不是一直等——超时后依然失败就该回头检查用例本身而不是继续加码等待。- retry: maxAttempts: 3 interval: 1000 command: assertVisible: 加载完成 - assertVisible: text: 支付成功 timeout: 10000第一段让断言最多重试 3 次、每次间隔 1 秒第二段把单条断言的等待上限拉到 10 秒。若某条用例反复需要加这两个旋钮多半说明前置状态没对齐优先查clearState。一份逻辑两端的字段差异移动端和 Web 端的步骤写法完全同构差别只在头部声明。移动端用appId指包名Web 端则以url字段开头指向页面地址。仓库里的e2e/workspaces/web/simple.yaml就是一个真实示例结构如下url: https://www.saucedemo.com/ tags: - web --- - launchApp - tapOn: Username - inputText: standard_user - tapOn: Password - inputText: secret_sauce - tapOn: Login - assertVisible: Products维度移动端Web 端入口字段appId包名url页面地址元素来源无障碍层文本页面文本 / DOM步骤写法同左同左用例需要反复造随机数据时还有inputRandomEmail、inputRandomNumber这类命令运行时现生成邮箱或指定范围内的数字不必把测试数据写死在脚本里。跑绿之前的自检清单把一条用例变成能交给 CI 的稳定用例按下面顺序过一遍先在单一平台把登录跑绿再补一条负向分支锁定账号后断言错误提示然后把同一流程改写成 Web 版本、用url验证通过最后给偶发失败的断言套上retry观察是否变稳。三件事做完你就有一组最小可交接的用例集。到那时真正的下一步不是继续堆用例数量而是确认这几条在 Android、iOS、Web 三端都稳定变绿。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考