如何用 Maestro AI 移动 UI 自动化测试少写脚本、少维护【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro上线前 UI 改版定位元素的回归脚本批量失效这是很多团队做移动 UI 测试时最熟悉的窘境。Maestro 的 AI 能力把一部分找元素、写断言的活交给了大模型你用一句话描述页面状态AI 移动 UI 测试就能判断对不对。这篇分享讲我们实际跑通它的过程以及它哪里不稳、钱花在哪。它到底解决什么问题结论Maestro 的 AI 模块把描述界面状态这件事从写选择器变成了写一句话覆盖两类场景——自然语言断言assertWithAI和视觉缺陷检测assertNoDefectsWithAI。原理上它做两件事把页面的信息喂给多模态大模型再让模型回答这句话对不对这张图有没有毛病。它的边界也要讲清楚元素级的精确操作比如点哪个按钮、输入什么文本仍然是 Maestro 的传统命令AI 主要接手模糊的验证和看画面这一步。AI 模块的实现在 maestro-ai/src/同时是一个库和一个演示程序识别 OpenAI 或 Anthropic 的密钥后自动走对应厂商的接口。最短路径跑通第一个 AI 测试结论一条命令链加一个 YAML 文件5 分钟内可以出第一个 AI 移动 UI 测试用例。前提只有一个有 OpenAI 或 Anthropic 的 API Key。以下命令连续执行即可——克隆仓库、设置环境变量 MAESTRO_CLI_AI_KEY、构建 AI 模块、再跑一次自带截图的演示git clone https://gitcode.com/GitHub_Trending/ma/maestro cd maestro export MAESTRO_CLI_AI_KEYsk-... ./gradlew :maestro-ai:installDist ./maestro-ai/build/install/maestro-ai-demo/bin/maestro-ai-demo --help然后新建一个用例文件这是它能跑的最小形态appId: com.example.myapp --- - launchApp: clearState: true - tapOn: 开始使用 - assertWithAI: assertion: 主界面显示正常包含导航菜单跑通之后下一步就可以把现有脚本里最不稳定的一条断言换成这种写法对比一下失败率。三个用例各说一件事下面三个用例每个只说清一件事AI 断言适合放在流程的哪一步。登录流程用 AI 断言代替逐控件校验需求验证登录后落到了正确页面。用传统断言你通常要写三到四个控件检查页面微调一处就挂- launchApp: { clearState: true } - tapOn: 登录 - inputText: { onText: 用户名, text: demo } - tapOn: 提交 - assertWithAI: assertion: 已进入首页顶部显示用户名一句顶部显示用户名覆盖了头像、昵称等多处控件的变化这类用例日常维护基本可以省掉。视觉缺陷检测看画面而不是看控件树需求确认这一屏没有渲染错乱、文字截断、元素重叠。控件树里每个节点都正常不代表用户看到的画面正常这正是assertNoDefectsWithAI的用武之地- launchApp: { clearState: true } - tapOn: 缺陷测试 - assertNoDefectsWithAI: optional: true - assertWithAI: 界面上显示了一张兔子图片仓库的演示应用里专门有一张缺陷测试页e2e/workspaces/ 下也有整套工作区可以参考跑一遍就能直观看到模型怎么挑毛病。注意optional: true的用法先让它只记录、不判死观察一段时间再收紧。跨平台一份用例Android 和 iOS 都跑需求同一个登录回归双端各跑一遍。AI 的介入点在于断言按用户看到的画面描述不写平台专属的控件名所以同一份 YAML 在两个平台语义一致- launchApp: { clearState: true } - tapOn: 登录 - assertWithAI: assertion: 登录页包含用户名、密码输入框和提交按钮平台相关的启动参数和权限弹窗处理交给 Maestro 的平台适配层你在用例里不用分叉两套脚本。它会在哪里不稳怎么控制成本先说不好的部分大模型看图不是像素级精确同一屏两次判断可能不一致多模态调用有网络延迟也按 token 计费所以 AI 断言天然比文本断言慢、贵。✅ 我们的策略很明确粗验证交给 AI细校验留给传统断言关键数字、金额这类内容绝不交给感觉。对稳定性有两层机制值得注意。一是等待用extendedWaitUntil把元素查找的超时拉长动画、慢网络导致的假失败会少很多。二是失败策略- extendedWaitUntil: visible: 提交按钮 timeout: 30000 label: 等待登录页加载完成 - assertNoDefectsWithAI: optional: trueoptional: true表示这条 AI 断言不通过时只记录、不判死适合观察期等结果稳了再拿掉。成本上我们控制了三件事一重复断言复用历史结果同一界面反复跑不重复烧 token二模型分级简单判断用小模型拿不准的再升级到大模型三按需开启只在关键界面开 AI 检查而不是每个页面都扫一遍。做到这三条AI 移动 UI 测试的账单基本可控。⚠️ 另外建议把 API 用量接到监控里跑一段时间看哪条用例最烧钱。接下来能去哪两个方向都有仓库依据不画饼。第一个是 MCP 工具链Maestro 把设备列表、截图、点按、输入、文档查询、流程执行这些能力封装成标准工具供 agent 调用agent 自己决定先截图还是先查文档。相关工具定义在 maestro-cli/src/main/java/maestro/cli/mcp/tools/测试目录下还有完整的工作流评估full-evals里面用 LLM-Judge 给工具选得对不对打分阈值 0.8。对我们来说这意味着以后可以让 agent 替你编排用例而不只是人写 YAML。第二个方向是多模态输入。AI 模块现在接收截图做断言同一套接口结构可以扩展到其他输入形式仓库里 AI 断言和缺陷检测两条链路也都留了按 prompt 注入自定义检查项的口子。至于自动修脚本目前没有现成开关更现实的路径是AI 告诉你哪里变了人来改那一行。一句话行动挑一条你最旧的回归用例把其中最不稳的元素定位改成一条 assertWithAI明天早上跑一次看结果再决定迁移多少。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何用 Maestro AI 移动 UI 自动化测试少写脚本、少维护【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro上线前 UI 改版定位元素的回归脚本批量失效这是很多团队做移动 UI 测试时最熟悉的窘境。Maestro 的 AI 能力把一部分找元素、写断言的活交给了大模型你用一句话描述页面状态AI 移动 UI 测试就能判断对不对。这篇分享讲我们实际跑通它的过程以及它哪里不稳、钱花在哪。它到底解决什么问题结论Maestro 的 AI 模块把描述界面状态这件事从写选择器变成了写一句话覆盖两类场景——自然语言断言assertWithAI和视觉缺陷检测assertNoDefectsWithAI。原理上它做两件事把页面的信息喂给多模态大模型再让模型回答这句话对不对这张图有没有毛病。它的边界也要讲清楚元素级的精确操作比如点哪个按钮、输入什么文本仍然是 Maestro 的传统命令AI 主要接手模糊的验证和看画面这一步。AI 模块的实现在 maestro-ai/src/同时是一个库和一个演示程序识别 OpenAI 或 Anthropic 的密钥后自动走对应厂商的接口。最短路径跑通第一个 AI 测试结论一条命令链加一个 YAML 文件5 分钟内可以出第一个 AI 移动 UI 测试用例。前提只有一个有 OpenAI 或 Anthropic 的 API Key。以下命令连续执行即可——克隆仓库、设置环境变量 MAESTRO_CLI_AI_KEY、构建 AI 模块、再跑一次自带截图的演示git clone https://gitcode.com/GitHub_Trending/ma/maestro cd maestro export MAESTRO_CLI_AI_KEYsk-... ./gradlew :maestro-ai:installDist ./maestro-ai/build/install/maestro-ai-demo/bin/maestro-ai-demo --help然后新建一个用例文件这是它能跑的最小形态appId: com.example.myapp --- - launchApp: clearState: true - tapOn: 开始使用 - assertWithAI: assertion: 主界面显示正常包含导航菜单跑通之后下一步就可以把现有脚本里最不稳定的一条断言换成这种写法对比一下失败率。三个用例各说一件事下面三个用例每个只说清一件事AI 断言适合放在流程的哪一步。登录流程用 AI 断言代替逐控件校验需求验证登录后落到了正确页面。用传统断言你通常要写三到四个控件检查页面微调一处就挂- launchApp: { clearState: true } - tapOn: 登录 - inputText: { onText: 用户名, text: demo } - tapOn: 提交 - assertWithAI: assertion: 已进入首页顶部显示用户名一句顶部显示用户名覆盖了头像、昵称等多处控件的变化这类用例日常维护基本可以省掉。视觉缺陷检测看画面而不是看控件树需求确认这一屏没有渲染错乱、文字截断、元素重叠。控件树里每个节点都正常不代表用户看到的画面正常这正是assertNoDefectsWithAI的用武之地- launchApp: { clearState: true } - tapOn: 缺陷测试 - assertNoDefectsWithAI: optional: true - assertWithAI: 界面上显示了一张兔子图片仓库的演示应用里专门有一张缺陷测试页e2e/workspaces/ 下也有整套工作区可以参考跑一遍就能直观看到模型怎么挑毛病。注意optional: true的用法先让它只记录、不判死观察一段时间再收紧。跨平台一份用例Android 和 iOS 都跑需求同一个登录回归双端各跑一遍。AI 的介入点在于断言按用户看到的画面描述不写平台专属的控件名所以同一份 YAML 在两个平台语义一致- launchApp: { clearState: true } - tapOn: 登录 - assertWithAI: assertion: 登录页包含用户名、密码输入框和提交按钮平台相关的启动参数和权限弹窗处理交给 Maestro 的平台适配层你在用例里不用分叉两套脚本。它会在哪里不稳怎么控制成本先说不好的部分大模型看图不是像素级精确同一屏两次判断可能不一致多模态调用有网络延迟也按 token 计费所以 AI 断言天然比文本断言慢、贵。✅ 我们的策略很明确粗验证交给 AI细校验留给传统断言关键数字、金额这类内容绝不交给感觉。对稳定性有两层机制值得注意。一是等待用extendedWaitUntil把元素查找的超时拉长动画、慢网络导致的假失败会少很多。二是失败策略- extendedWaitUntil: visible: 提交按钮 timeout: 30000 label: 等待登录页加载完成 - assertNoDefectsWithAI: optional: trueoptional: true表示这条 AI 断言不通过时只记录、不判死适合观察期等结果稳了再拿掉。成本上我们控制了三件事一重复断言复用历史结果同一界面反复跑不重复烧 token二模型分级简单判断用小模型拿不准的再升级到大模型三按需开启只在关键界面开 AI 检查而不是每个页面都扫一遍。做到这三条AI 移动 UI 测试的账单基本可控。⚠️ 另外建议把 API 用量接到监控里跑一段时间看哪条用例最烧钱。接下来能去哪两个方向都有仓库依据不画饼。第一个是 MCP 工具链Maestro 把设备列表、截图、点按、输入、文档查询、流程执行这些能力封装成标准工具供 agent 调用agent 自己决定先截图还是先查文档。相关工具定义在 maestro-cli/src/main/java/maestro/cli/mcp/tools/测试目录下还有完整的工作流评估full-evals里面用 LLM-Judge 给工具选得对不对打分阈值 0.8。对我们来说这意味着以后可以让 agent 替你编排用例而不只是人写 YAML。第二个方向是多模态输入。AI 模块现在接收截图做断言同一套接口结构可以扩展到其他输入形式仓库里 AI 断言和缺陷检测两条链路也都留了按 prompt 注入自定义检查项的口子。至于自动修脚本目前没有现成开关更现实的路径是AI 告诉你哪里变了人来改那一行。一句话行动挑一条你最旧的回归用例把其中最不稳的元素定位改成一条 assertWithAI明天早上跑一次看结果再决定迁移多少。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
