Maestro AI 测试实战从一句话描述到跨平台 UI 测试脚本【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro一条登录流程的 UI 测试你上次改定位器是什么时候如果答案是上次需求一动就炸那么 Maestro 的 AI 测试能力值得认真看一眼它把描述你要验证什么这件事交给了大模型脚本只保留最关键的意图。Maestro 本身是一个移动 UI 自动化工具用 YAML 描述操作流程而它的 maestro-ai 模块让这份 YAML 里可以出现自然语言断言还能让 AI 直接替你判断截图里有没有视觉缺陷。 一句描述是怎么变成可执行步骤的不用上来就画架构图跟着一次调用走一遍更清楚。你写下一句页面上应该有一只可爱的兔子Maestro 把这句话连同当前屏幕截图交给模型模型返回判断结果执行器据此决定测试通过还是失败。这里 maestro-ai 是库 演示应用的双重身份作为库它封装了与 OpenAI、Anthropic 两家模型的对话逻辑你只需要一个环境变量注入密钥作为演示应用它提供独立的命令行入口方便你单独调试提示词、查看模型的原始返回。另一边MCP 服务器负责动手的部分。它向模型暴露了一组工具list_devices、take_screenshot、run、inspect_screen、cheat_sheet、list_cloud_devices、run_on_cloud、get_cloud_run_status——设备管理、截图、跑流程、查文档模型要做什么都得通过这几个入口。模型说我需要看一眼当前屏幕MCP 就去抓截图说帮我跑 setup/flows 里的某个流程MCP 就执行并回传结果。别小看这套评估机制。项目里有一份 MCP 的 LLM 评估配置 full-evals.yaml它给每类任务配了模型评分员LLM-Judge模型的回答会被另一个模型按评分标准打分并设了明确的通过阈值从 0.6 到 1.0 视任务而定达不到标准就算失败。换句话说AI 的每次决策都有质检而不是模型说行就行。 三个你大概率马上会用的场景先让 AI 替你看图。视觉回归测试过去要么像素比对、要么人工巡检。Maestro 在 demo 应用的工作区里就有一个现成用例先启动应用并清掉状态点进 Defects 测试页然后一行assertNoDefectsWithAI让模型判断这屏有没有渲染崩坏、文字截断再补一句自然语言断言确认关键画面存在。- launchApp: clearState: true - tapOn: Defects Test - assertNoDefectsWithAI: optional: true - assertWithAI: A picture of a cute bunny is visible效果就是截图异常时测试直接红掉而兔子在不在画面里这种传统断言很难写的事变成了一句话。让 AI 替你写断言。这是改动定位成本最低的一块。你不用关心控件树长什么样直接把验收标准写成人话Maestro 会结合界面层级去验证。- launchApp: clearState: true - assertWithAI: optional: true assertion: A login screen is visible就这么简单。界面改版后只要能看到登录屏这件事还成立断言就不需要动。跨平台不用改两遍。项目自带的维基百科工作区是最直观的例子android-flow.yaml 和 ios-flow.yaml 描述的是同一套验收意图配合 subflows/ 里的平台子流程处理启动差异。Android 的返回键和 iOS 的边缘滑动返回这类平台特有交互被隔离在各自子流程里主流程保持平台无关。测试工程师不用在两套脚本之间来回翻译需求。⚙️ 不稳和太贵Maestro 怎么扛问题移动端 UI 测试出了名的毛刺多而每次调大模型又是一笔真金白银的 API 开销。应对稳定性上extendedWaitUntil 让你给元素查找单独放宽超时demo 用例里从 100ms 到 90 秒都有避免页面还没渲染完就判死retry命令则给易失败步骤套上重试内置状态稳定检测约 40ms 的 settle 判断重试前先确认界面不再变动。成本上设计思路是三级过滤重复场景复用历史分析结果简单断言路由到 Haiku 级别的轻量模型只对界面变化区域做增量分析来压缩 Token。对你的实际影响CI 里的 AI 断言不会因为一次动画没播完而误报账单也不会因为每张截图都问一遍 GPT而失控。想本地体验的话两条命令够用了./gradlew :maestro-ai:installDist export MAESTRO_CLI_AI_KEYyour_key_here 这意味着什么多模态、自修复、开发者协同这三件事听起来分散指向的其实是同一个方向测试脚本的寿命开始和界面长相解耦。当 AI 能理解语音交互、能在 UI 变动后自己分析新结构并更新定位策略、能在 Maestro Studio 里根据你的一句话直接生成并调试用例时UI 测试维护就从每次发版后的救火变成偶尔抽查。这意味着移动 UI 自动化的瓶颈正从写脚本的人转移到描述需求的人——而后者恰恰是每个开发都擅长的事。以前是改一行 UI、翻遍测试目录找定位器以后大概率是改完 UI跑一遍测试看 AI 有没有挑出毛病。贡献入口CONTRIBUTING.md文中代码示例均来自项目内实际测试套件e2e/demo_app/、e2e/workspaces/ 与 maestro-cli/src/test/mcp/可直接在对应工作区运行验证。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Maestro AI 测试实战：从一句话描述到跨平台 UI 测试脚本
Maestro AI 测试实战从一句话描述到跨平台 UI 测试脚本【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro一条登录流程的 UI 测试你上次改定位器是什么时候如果答案是上次需求一动就炸那么 Maestro 的 AI 测试能力值得认真看一眼它把描述你要验证什么这件事交给了大模型脚本只保留最关键的意图。Maestro 本身是一个移动 UI 自动化工具用 YAML 描述操作流程而它的 maestro-ai 模块让这份 YAML 里可以出现自然语言断言还能让 AI 直接替你判断截图里有没有视觉缺陷。 一句描述是怎么变成可执行步骤的不用上来就画架构图跟着一次调用走一遍更清楚。你写下一句页面上应该有一只可爱的兔子Maestro 把这句话连同当前屏幕截图交给模型模型返回判断结果执行器据此决定测试通过还是失败。这里 maestro-ai 是库 演示应用的双重身份作为库它封装了与 OpenAI、Anthropic 两家模型的对话逻辑你只需要一个环境变量注入密钥作为演示应用它提供独立的命令行入口方便你单独调试提示词、查看模型的原始返回。另一边MCP 服务器负责动手的部分。它向模型暴露了一组工具list_devices、take_screenshot、run、inspect_screen、cheat_sheet、list_cloud_devices、run_on_cloud、get_cloud_run_status——设备管理、截图、跑流程、查文档模型要做什么都得通过这几个入口。模型说我需要看一眼当前屏幕MCP 就去抓截图说帮我跑 setup/flows 里的某个流程MCP 就执行并回传结果。别小看这套评估机制。项目里有一份 MCP 的 LLM 评估配置 full-evals.yaml它给每类任务配了模型评分员LLM-Judge模型的回答会被另一个模型按评分标准打分并设了明确的通过阈值从 0.6 到 1.0 视任务而定达不到标准就算失败。换句话说AI 的每次决策都有质检而不是模型说行就行。 三个你大概率马上会用的场景先让 AI 替你看图。视觉回归测试过去要么像素比对、要么人工巡检。Maestro 在 demo 应用的工作区里就有一个现成用例先启动应用并清掉状态点进 Defects 测试页然后一行assertNoDefectsWithAI让模型判断这屏有没有渲染崩坏、文字截断再补一句自然语言断言确认关键画面存在。- launchApp: clearState: true - tapOn: Defects Test - assertNoDefectsWithAI: optional: true - assertWithAI: A picture of a cute bunny is visible效果就是截图异常时测试直接红掉而兔子在不在画面里这种传统断言很难写的事变成了一句话。让 AI 替你写断言。这是改动定位成本最低的一块。你不用关心控件树长什么样直接把验收标准写成人话Maestro 会结合界面层级去验证。- launchApp: clearState: true - assertWithAI: optional: true assertion: A login screen is visible就这么简单。界面改版后只要能看到登录屏这件事还成立断言就不需要动。跨平台不用改两遍。项目自带的维基百科工作区是最直观的例子android-flow.yaml 和 ios-flow.yaml 描述的是同一套验收意图配合 subflows/ 里的平台子流程处理启动差异。Android 的返回键和 iOS 的边缘滑动返回这类平台特有交互被隔离在各自子流程里主流程保持平台无关。测试工程师不用在两套脚本之间来回翻译需求。⚙️ 不稳和太贵Maestro 怎么扛问题移动端 UI 测试出了名的毛刺多而每次调大模型又是一笔真金白银的 API 开销。应对稳定性上extendedWaitUntil 让你给元素查找单独放宽超时demo 用例里从 100ms 到 90 秒都有避免页面还没渲染完就判死retry命令则给易失败步骤套上重试内置状态稳定检测约 40ms 的 settle 判断重试前先确认界面不再变动。成本上设计思路是三级过滤重复场景复用历史分析结果简单断言路由到 Haiku 级别的轻量模型只对界面变化区域做增量分析来压缩 Token。对你的实际影响CI 里的 AI 断言不会因为一次动画没播完而误报账单也不会因为每张截图都问一遍 GPT而失控。想本地体验的话两条命令够用了./gradlew :maestro-ai:installDist export MAESTRO_CLI_AI_KEYyour_key_here 这意味着什么多模态、自修复、开发者协同这三件事听起来分散指向的其实是同一个方向测试脚本的寿命开始和界面长相解耦。当 AI 能理解语音交互、能在 UI 变动后自己分析新结构并更新定位策略、能在 Maestro Studio 里根据你的一句话直接生成并调试用例时UI 测试维护就从每次发版后的救火变成偶尔抽查。这意味着移动 UI 自动化的瓶颈正从写脚本的人转移到描述需求的人——而后者恰恰是每个开发都擅长的事。以前是改一行 UI、翻遍测试目录找定位器以后大概率是改完 UI跑一遍测试看 AI 有没有挑出毛病。贡献入口CONTRIBUTING.md文中代码示例均来自项目内实际测试套件e2e/demo_app/、e2e/workspaces/ 与 maestro-cli/src/test/mcp/可直接在对应工作区运行验证。【免费下载链接】MaestroPainless E2E Automation for Mobile and Web项目地址: https://gitcode.com/GitHub_Trending/ma/Maestro创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![Rust 编译器错误码 E0757 详解：`[ffi_const]` 与 `[ffi_pure]` 属性冲突的成因与修复](http://pic.xiahunao.cn/yaotu/Rust 编译器错误码 E0757 详解：`[ffi_const]` 与 `[ffi_pure]` 属性冲突的成因与修复)
