基于Open-AutoGLM的零代码移动端UI自动化测试实战指南

1. 项目概述：当AI学会“看”手机屏幕

如果你也和我一样，曾经被繁琐、重复的手机操作搞得焦头烂额——比如每天要在十几个App里签到打卡，或者需要定期检查某个商品的价格波动，甚至只是想自动化完成一些简单的UI测试——那么，你肯定幻想过有一个“数字替身”能帮你搞定这一切。过去，这需要你学习Appium、编写复杂的脚本、处理各种元素定位和异常情况，门槛高得吓人。

但现在，情况变了。Open-AutoGLM的出现，让“用自然语言指挥AI操作手机”从科幻走进了现实。它本质上是一个专为移动设备设计的视觉语言模型（VLM），能够像人一样“看懂”手机屏幕，理解你的指令，并执行点击、滑动、输入等操作。而围绕它构建的生态工具，比如我们今天要深入拆解的AutoGLM-GUI，则将这个强大的能力封装成了一个开箱即用、甚至“零代码”的图形化生产力工具。

这个项目的核心价值，就是彻底降低了移动端自动化的门槛。你不再需要是专业的测试开发工程师，也无需和adb shell input tap x y这样的命令打交道。你只需要用人类最自然的方式告诉它：“去美团帮我点一杯霸王茶姬的伯牙绝弦，少冰，加珍珠”，它就能尝试去完成。这对于UI测试、日常任务自动化、甚至是一些创意性的批量操作来说，无疑是一场效率革命。

2. 核心思路拆解：从“脚本执行”到“视觉理解”的范式转移

传统的移动端自动化，无论是基于uiautomator2还是Appium，其核心逻辑都是“元素定位”。工程师需要预先知道目标按钮或文本框的resource-id、xpath或坐标，然后编写脚本去查找并操作它。这种方式稳定、精确，但极度脆弱——App的一次UI改版就可能导致整个脚本失效，维护成本高昂。

Open-AutoGLM代表的是一种全新的“视觉驱动”范式。它的工作流程可以概括为：观察（See）-> 思考（Think）-> 行动（Act）。

1. 观察（See）：模型实时获取手机屏幕的截图（或视频流），将其作为视觉输入。
2. 思考（Think）：模型结合你的自然语言指令（如“打开微信”），以及当前的屏幕画面，进行多模态推理。它需要理解屏幕上哪些是按钮、哪些是输入框、哪些是文本，并判断下一步该做什么。这个过程完全模拟了人类操作手机时的认知过程。
3. 行动（Act）：模型输出一个结构化的动作指令，比如Tap(坐标)、Swipe(起始坐标, 结束坐标)、Input(文本)。这个指令通过ADB（Android调试桥）发送到手机执行。

AutoGLM-GUI在这个范式之上，做了几件至关重要的事情，使其变得真正“可用”：

• 抽象化：它将复杂的模型调用、ADB通信、设备管理封装在一个直观的Web界面后面。用户面对的不再是命令行和API，而是一个聊天窗口和一个手机屏幕预览。
• 工程化：它解决了设备连接（支持USB和WiFi，特别是Android 11+的无线扫码配对）、会话管理、任务调度（定时任务）、历史记录等工程问题，让自动化可以7x24小时稳定运行。
• 场景化：通过引入“分层代理模式”和“Workflow工作流”，它区分了简单任务和复杂任务，并允许用户将成功的操作序列保存为模板，一键复用。

注意：这种“视觉理解”模式并非万能。它的精度和成功率受限于模型对当前屏幕的理解能力。对于UI元素极其相似、动态内容过多或需要复杂逻辑判断的场景，它可能会“犯糊涂”。因此，它最适合的是流程相对固定、UI元素辨识度高的重复性任务。

2.1 两种核心工作模式解析

AutoGLM-GUI提供了两种主要的Agent（智能体）工作模式，对应不同的任务复杂度。

2.1.1 经典模式（单模型/Open AutoGLM）这是最直接的模式，也是Open-AutoGLM项目的原生形态。单个autoglm-phone视觉模型包揽了从理解任务、规划步骤到观察执行的全过程。

• 优点：配置最简单，响应直接，适合目标明确、步骤少的“快进快出”型任务。例如：“打开设置”、“截屏”、“回到桌面”。
• 缺点：对于需要多步推理、中途可能需要调整策略的复杂任务，单模型可能会陷入“短视”决策，比如在某个页面找不到元素时，它可能只会盲目点击，而不是退出去尝试其他路径。

2.1.2 分层代理模式（Layered Agent）这是AutoGLM-GUI引入的增强模式，采用了更接近人类“指挥官-执行者”的协作架构。

• 规划层（Planner）：通常由一个更强的、擅长推理和规划的LLM（如GPT-4、Claude 3）担任。它不直接“看”屏幕，而是接收任务描述和执行层的文字观察报告。它的职责是进行任务拆解和制定高级策略。例如，接到“帮我订一份外卖”的任务后，它会规划出：“1. 打开美团；2. 搜索餐厅；3. 选择菜品；4. 下单支付”等子步骤。
• 执行层（Executor）：由autoglm-phone这类视觉模型担任。它只负责接收规划层下达的原子指令（如“点击搜索框”），观察屏幕，执行具体操作，并将结果（成功/失败、当前屏幕的文本描述）反馈给规划层。
• 工作流：规划层通过工具调用（如chat(device_id, “打开美团”)）来驱动执行层。你可以在AutoGLM-GUI的界面上清晰地看到每一次工具调用的请求和返回结果。
• 优点：非常适合复杂、多轮交互的任务。规划层可以基于执行层的反馈动态调整计划。例如，当执行层反馈“搜索框未找到”时，规划层可以决定“先点击底部的‘首页’标签再试试”。整个过程更透明、更可控，也更容易调试和优化。
• 缺点：配置稍复杂（需要两个模型API），且由于多了层间通信，单步耗时可能略长。

选择哪种模式？我的经验是：从经典模式开始，遇到复杂任务屡屡失败时，再切换到分层代理模式。对于UI测试而言，如果你测试的是某个固定流程（如登录、下单），经典模式通常足够；如果你需要测试一个包含多种分支路径（如商品搜索、筛选、比价）的场景，分层代理模式更能胜任。

3. 零代码UI测试四步秘诀实战

下面，我将结合一个完整的UI测试场景——“测试某电商App的登录流程”，来拆解这四步秘诀。假设我们手头有一台Android测试机（或模拟器）。

3.1 第一步：环境搭建与设备连接——打好地基

“零代码”不代表零配置。一个稳定可靠的环境是后续所有操作的前提。

1. 部署AutoGLM-GUI服务：你有多种选择，对于UI测试这种可能需要长期运行、反复执行的场景，我强烈推荐Docker部署。

# 1. 拉取官方docker-compose配置 curl -O https://raw.githubusercontent.com/suyiiyii/AutoGLM-GUI/main/docker-compose.yml # 2. 启动服务（使用host网络模式，这对设备发现至关重要） docker-compose up -d

启动后，在浏览器访问http://你的服务器IP:8000即可看到Web界面。Docker部署的优势在于环境隔离、一键启停、易于迁移，非常适合在测试服务器或CI/CD环境中运行。

2. 配置模型API：这是AI的“大脑”。你需要一个OpenAI兼容的API服务来驱动autoglm-phone模型。对于国内用户，最方便的是使用智谱AI或ModelScope的托管服务。

• 智谱BigModel：在AutoGLM-GUI的设置页面，填入：
  • Base URL:https://open.bigmodel.cn/api/paas/v4
  • Model:autoglm-phone
  • API Key: 你的智谱API Key
• ModelScope：
  • Base URL:https://api-inference.modelscope.cn/v1
  • Model:ZhipuAI/AutoGLM-Phone-9B
  • API Key: 你的ModelScope API Key

实操心得：初期测试或预算有限时，可以优先使用ModelScope，它提供了一定的免费额度。对于企业级高频测试，建议使用智谱的付费服务，稳定性和响应速度更有保障。如果追求极致可控和成本，也可以自行使用vLLM部署开源模型，但这需要一定的运维能力。

3. 连接Android设备：这是与物理设备交互的桥梁。无线连接是自动化测试的黄金标准，它解放了USB端口，也便于远程管理。

• 对于Android 11+设备（推荐）：
  1. 在手机上开启“开发者选项”和“无线调试”。
  2. 确保手机和运行AutoGLM-GUI的电脑/服务器在同一局域网。
  3. 在AutoGLM-GUI Web界面，点击左下角“+”->“添加无线设备”->“配对设备”。
  4. 用手机扫描屏幕上生成的二维码，即可完成配对并自动连接。这个过程完全无需数据线。
• 对于Android 10及以下或模拟器：
  1. 先用USB线连接一次，执行adb tcpip 5555开启无线调试端口。
  2. 拔掉USB线，在AutoGLM-GUI界面输入手机的IP地址和端口（如192.168.1.100:5555）进行连接。

连接成功后，左侧设备列表会出现你的设备，右侧会显示实时手机屏幕。至此，你的“AI测试工程师”已经就位。

3.2 第二步：任务定义与Workflow创建——将测试用例“说”出来

传统的UI测试需要编写脚本，而现在，你只需要用自然语言描述测试场景。但“描述”本身也有技巧，直接关系到AI执行的成败。

1. 定义清晰的测试任务：糟糕的指令：“测试登录功能”。 良好的指令：“在XX电商App的登录页面，使用账号testuser@example.com和密码Test123456完成登录，并验证登录成功后是否跳转到了首页。”

为什么后者更好？它明确了：

• 初始状态：位于“XX电商App的登录页面”。（如果不在，AI需要先打开App并导航到登录页）
• 操作序列：输入账号 -> 输入密码 -> 点击登录按钮。
• 预期结果/验证点：跳转到“首页”。（AI可以通过观察页面标题或特定元素是否存在来间接验证）

2. 创建可复用的Workflow：在AutoGLM-GUI中，你可以将上述成功的指令保存为“Workflow”。点击左侧的Workflows图标，创建一个名为“测试-电商App登录”的Workflow，将详细的指令粘贴进去。这样，下次执行时，只需选择这个Workflow并点击运行，无需再次输入。

避坑技巧：在创建最终Workflow前，务必在Chat界面手动执行几次，观察AI的执行路径。你可能会发现一些需要优化的点。例如，AI可能会在输入密码后，先去点击了“显示密码”的小眼睛图标（因为它“看到”了这个可交互元素）。这时，你需要在指令中增加约束：“直接在密码输入框输入密码，不要点击‘显示密码’按钮”。通过多次调试，你的指令会越来越精准，Workflow的稳定性也会大幅提升。

3.3 第三步：执行与监控——让AI跑起来，并看懂它在做什么

点击“发送”或执行Workflow后，真正的魔法开始了。此时，你需要学会如何监控和解读AI的行为。

1. 观察实时推理与操作流：AutoGLM-GUI的界面会实时显示两样东西：

• AI的思考过程：在聊天区域，AI会以文字形式输出它的“想法”，例如：“当前屏幕是桌面。用户要求打开XX电商App。我正在寻找该App的图标。” -> “找到了图标，位于屏幕第二行第一个。我将点击它。”
• 屏幕操作与反馈：在手机预览画面中，你会看到AI的点击位置会出现一个涟漪动画，并且有“成功”或“失败”的短暂提示。屏幕内容也会随之变化。

2. 理解AI的决策逻辑：当测试失败时（比如登录按钮没找到），不要急于否定。仔细看AI的思考过程。它可能因为以下原因失败：

• 屏幕理解偏差：它可能把“注册”按钮误认为是“登录”按钮。这说明当前屏幕的UI设计对模型来说存在歧义。
• 元素状态问题：登录按钮可能是灰色的（不可点击状态），但模型没有识别出这种状态差异。
• 网络或加载延迟：AI点击后，页面没有立即响应，AI在等待超时后可能误判为操作失败或执行了错误的后继操作。

3. 利用“立即打断”功能：这是v1.5版本非常实用的一个功能。当AI正在执行一个明显错误的操作序列时（比如陷入了点击循环），你可以立即点击“停止”按钮（通常在1秒内响应），中断当前任务，避免它进一步“搞破坏”。这在调试阶段至关重要。

3.4 第四步：规模化与集成——从单次测试到测试体系

单个测试用例的成功只是开始。UI测试的核心价值在于回归和监控，这就需要规模化和集成。

1. 使用定时任务进行回归测试：假设我们每天需要验证核心登录流程是否正常。我们可以在AutoGLM-GUI的“定时任务”页面，创建一个Cron任务。

• Cron表达式：0 2 * * *（表示每天凌晨2点执行）
• 选择设备：你的测试机
• 任务内容：选择之前创建好的“测试-电商App登录”这个Workflow。

这样，每天凌晨，AI都会自动执行一遍登录测试，并将结果记录在“对话历史”中。你第二天只需要查看历史记录，就能知道测试是否通过。

2. 多设备并发测试：如果你需要测试App在不同型号、分辨率或系统版本的手机上的兼容性，可以连接多台设备。AutoGLM-GUI支持同时管理多台设备，并为每台设备维护独立的会话。你可以为每台设备创建相同的定时任务，或者依次手动执行Workflow，实现并发或串行的兼容性测试。

3. 集成到CI/CD流程（进阶）：虽然AutoGLM-GUI本身是图形化工具，但其底层通过MCP（Model Context Protocol）暴露了HTTP API。这意味着你可以将其集成到自动化流水线中。

• 思路：在CI服务器（如Jenkins、GitLab CI）上，同样通过Docker部署AutoGLM-GUI服务并连接好测试机。当代码合并触发构建后，CI脚本可以通过调用AutoGLM-GUI的MCP接口（/mcp端点），向其发送测试指令（如“执行Workflow ‘XXX’”），并获取执行结果日志。
• 关键点：你需要编写一个简单的脚本，作为CI流程和AutoGLM-GUI MCP接口之间的桥梁。这需要一些额外的开发工作，但一旦打通，就能实现“提交代码 -> 自动构建 -> 自动进行AI视觉UI测试 -> 生成测试报告”的完整闭环。

4. 常见问题与实战避坑指南

在实际使用中，你一定会遇到各种问题。下面是我踩过坑后总结出的经验。

4.1 连接与设备问题

问题1：无线调试配对失败或设备列表不显示。

• 排查：首先确认手机和服务器在同一网段（IP前三位相同）。防火墙是否放行了ADB端口（通常为5555）。对于Docker部署，务必使用--network host模式，否则容器内的服务可能无法通过多播（mDNS）发现手机。
• 解决：如果二维码配对不行，尝试老方法：USB连接后adb tcpip 5555，再无线连接IP。对于模拟器（如Android Studio AVD），AutoGLM-GUI通常能自动发现，确保模拟器已启动。

问题2：AI操作速度慢，或经常“发呆”。

• 原因：延迟主要来自三部分：1) 屏幕截图和传输；2) 模型API响应；3) 网络延迟。
• 优化：
  • 降低截图分辨率：在设置中尝试调低屏幕流的分辨率，能显著加快截图和传输速度。
  • 使用本地或低延迟模型API：如果使用云端API，选择地理位置上更近的节点。有条件可以自建模型服务。
  • 优化指令：避免过于复杂、开放的指令。指令越明确，AI思考耗时越短。

4.2 模型与执行问题

问题3：AI总是点错地方，或者找不到元素。

• 原因：这是视觉模型固有的局限性。可能是UI元素太小、太相似、颜色对比度低，或者是动态内容（如滚动列表、动画）。
• 应对策略：
  • 强化上下文：在指令中提供更精确的定位描述。例如，不说“点击登录按钮”，而说“点击屏幕底部蓝色的、写着‘登录’二字的按钮”。
  • 分步引导：对于复杂页面，不要让它一步到位。拆分成多个子指令。例如：“先向下滑动屏幕，直到看到‘热门分类’标题，然后点击标题下方的第一个图标。”
  • 使用分层代理模式：让规划层LLM来负责复杂的路径寻找和决策，执行层只做简单的“点击看见的X”操作。
  • 人工干预与记录：当AI在一个步骤卡住时，手动在屏幕上点击正确位置。这次成功的操作会被记录在对话历史中。分析这次成功操作的截图和AI当时的“想法”，能帮你理解模型的“视觉盲区”，从而优化后续的指令。

问题4：如何处理登录验证码、滑块等非标准交互？

• 现状：目前的autoglm-phone模型不擅长处理这类强交互验证。它可能识别出滑块，但无法模拟精确的拖拽轨迹。
• 变通方案：
  • 测试环境屏蔽：在测试环境中，联系开发关闭或设置万能验证码。
  • 混合模式：对于这类固定瓶颈，可以结合传统自动化。例如，用AutoGLM-GUI完成直到验证码前的所有步骤，然后通过ADB命令或其它脚本注入验证码，再由AI接手后续操作。这需要更高级的流程编排。

问题5：如何评估测试结果？

• 传统断言 vs AI验证：传统脚本有明确的assert语句。AI测试的验证更“柔性”。你需要通过指令中的“验证点”来定义成功标准，例如：“并确认页面顶部出现了‘我的订单’字样”。AI会尝试在屏幕上寻找这个文本，并以此判断任务是否成功。
• 结果复核：不能100%依赖AI的自我判断。必须结合对话历史中的屏幕截图序列进行人工复核。查看关键步骤的截图，确认操作是否符合预期。AutoGLM-GUI的对话历史功能完美支持了这一点。

4.3 成本与稳定性考量

问题6：长期运行成本高吗？

• 分析：成本=模型API调用费用。执行一个任务所需的调用次数，取决于任务步骤数和模型的“思考”次数。一个简单的“打开App->点击登录->输入账号密码”任务，可能需要3-5次模型调用。
• 建议：对于需要高频执行的定时回归测试，务必精简指令，提高单次成功率，减少重试。可以考虑在非高峰时段（如夜间）执行批量测试。对于探索性测试或新用例编写，可以手动执行以调试指令。

问题7：这套方案的稳定性如何？适合取代传统UI自动化吗？

• 定位：目前阶段，它更适合作为传统自动化测试的强力补充，而非完全替代。
• 优势场景：快速原型验证、探索性测试、对UI变化有一定容忍度的监控任务（如每日核心流程巡检）、无法获取App源码（仅能拿到APK）情况下的自动化。
• 劣势场景：需要100%精确断言、处理复杂验证逻辑、性能基准测试等。
• 最佳实践：将AI视觉测试纳入测试金字塔的较高层（如UI层）。底层（单元测试、接口测试）仍用传统稳定方法覆盖。用AI测试来覆盖那些变动相对不频繁、但手工测试又极其耗时的核心用户旅程（Core User Journey）。

最后，我想分享一点个人体会。使用Open-AutoGLM和AutoGLM-GUI进行“零代码”UI测试，最大的转变不是工具本身，而是测试思维。你从一个“脚本编写者”变成了一个“AI训练师”和“流程设计者”。你的核心工作不再是和xpath搏斗，而是学习如何与AI协作，用最有效的语言引导它完成测试。这个过程充满了挑战，但当看到AI准确地执行完一整套复杂流程时，那种成就感是无可比拟的。它可能不会让你立刻丢掉所有传统自动化脚本，但它无疑为你打开了一扇新的大门，让你能用更接近人类思维的方式，去解决UI自动化的老问题。