Open-AutoGLM能否用于APP测试？自动化验证实战案例

你是不是也遇到过这样的场景？开发了一个新功能，需要反复在手机上点击、滑动、输入，进行回归测试，枯燥又耗时。或者，产品经理提了一个新需求，你想快速验证一下在真实手机上的交互流程是否顺畅，但又不想手动操作。

今天，我们就来聊聊一个能彻底改变这种工作方式的“神器”——Open-AutoGLM。它不是一个简单的自动化脚本工具，而是一个能“看懂”手机屏幕、听懂人话，并自动帮你完成操作的AI智能体。本文将带你从零开始，实战演练如何用它来为你的APP进行自动化测试和验证。

1. Open-AutoGLM：一个能“看见”和“操作”手机的AI

在深入技术细节之前，我们先搞清楚Open-AutoGLM到底是什么，以及它为什么能用于APP测试。

简单来说，Open-AutoGLM（特别是其Phone Agent组件）是一个基于大模型的手机端AI智能助理框架。它的核心能力可以概括为三点：

1. 多模态理解：它能像人一样，“看懂”手机屏幕上的内容。无论是文字、按钮、图标还是复杂的UI布局，它都能通过视觉语言模型进行识别和理解。
2. 自然语言交互：你不需要编写复杂的脚本。只需要用大白话告诉它你的目标，比如“打开小红书，搜索‘周末露营’相关的笔记，并点赞前三条”。
3. 自动化执行：理解你的意图和屏幕内容后，它会自动规划出一系列操作步骤（点击、滑动、输入等），并通过ADB（Android调试桥）在真实手机或模拟器上执行这些操作。

那么，这和APP测试有什么关系呢？关系太大了！传统的UI自动化测试（如Appium）依赖于预先编写好的、基于元素定位的脚本。一旦UI改动，脚本就可能失效，维护成本高。而Open-AutoGLM的思路是“目标驱动”和“意图理解”。

对于测试而言，这意味着：

• 测试用例即自然语言：你的测试用例可以写成“从首页登录，进入个人中心修改头像，然后退出登录”。AI会自己想办法完成。
• 对UI变更更鲁棒：只要AI能“看懂”新界面上的“登录”按钮在哪，它就能点，不依赖于固定的ID或XPath。
• 探索性测试：你可以给出一个模糊的指令，如“浏览一下这个电商APP，看看有没有明显的UI错位或交互卡顿”，让AI去自主探索。

接下来，我们就通过一个完整的实战案例，看看如何搭建环境并让AI为我们工作。

2. 实战准备：搭建你的AI测试机器人

要让AI控制手机，我们需要完成两个部分的准备：在云端部署负责“思考”的模型服务，以及在本地电脑配置负责“操控”的控制端。本次实战我们聚焦于更常见的本地控制端部署。

2.1 硬件与环境清单

在开始之前，请确保你准备好了以下几样东西：

• 一台电脑：Windows 10/11 或 macOS 均可。本文将主要以Windows为例，macOS步骤类似。
• 一部安卓手机：系统版本需在Android 7.0以上。强烈建议使用一台专门的测试机，因为过程中需要开启开发者权限。
• Python环境：建议安装Python 3.10或以上版本。
• 网络：电脑和手机需要在同一局域网下（比如连接同一个Wi-Fi），以便后续使用更灵活的Wi-Fi调试。

2.2 第一步：打通电脑与手机的连接（ADB配置）

AI控制手机的基础是ADB。我们需要在电脑上安装并配置好它。

1. 下载ADB工具包：访问Android开发者官网或使用搜索引擎查找“Platform-Tools”下载。解压到一个你容易找到的目录，例如 C:\platform-tools。
2. 配置系统环境变量（Windows）：
   • 右键点击“此电脑” -> “属性” -> “高级系统设置” -> “环境变量”。
   • 在“系统变量”区域，找到并选中Path变量，点击“编辑”。
   • 点击“新建”，将你解压ADB的路径（如 C:\platform-tools）添加进去。
   • 点击“确定”保存所有更改。
3. 验证安装：打开命令提示符（CMD）或PowerShell，输入 adb version 并回车。如果显示出版本信息，说明配置成功。

2.3 第二步：设置你的安卓手机

现在，我们需要让手机允许来自电脑的调试控制。

1. 开启开发者选项：进入手机的“设置” -> “关于手机”，连续点击“版本号”7次，直到出现“您已处于开发者模式”的提示。
2. 开启USB调试：返回设置，找到新出现的“开发者选项”。进入后，找到并开启“USB调试”开关。
3. 安装ADB键盘（关键步骤）：为了让AI能在手机上输入文字，我们需要一个特殊的输入法。
   • 在手机浏览器中搜索并下载 ADBKeyboard.apk 文件进行安装。
   • 安装后，进入“设置” -> “系统” -> “语言与输入法” -> “虚拟键盘”。
   • 找到“ADB Keyboard”并启用它。
   • 在“默认输入法”中，将其切换为“ADB Keyboard”。

2.4 第三步：部署Open-AutoGLM控制端

控制端是运行在你电脑上的Python程序，它负责与AI模型服务通信，并向手机发送ADB指令。

打开命令行工具，执行以下命令：

# 1. 克隆项目代码到本地
git clone https://github.com/zai-org/Open-AutoGLM
cd Open-AutoGLM

# 2. 安装项目所需的Python依赖包
pip install -r requirements.txt

# 3. 以“可编辑”模式安装本项目，方便后续修改和调试
pip install -e .

至此，你的本地控制端就准备好了。

3. 连接设备与启动AI代理

环境搭建好后，让我们把手机和电脑连接起来，并给AI下达第一个指令。

3.1 连接手机到电脑

你有两种方式连接手机：USB直连和Wi-Fi无线连接。无线连接在测试时更为方便。

• USB连接（最稳定）： 用数据线将手机连接到电脑。在命令行输入：

  adb devices
  

  你会看到类似 List of devices attached 和一行设备ID的输出，这表示连接成功。

• Wi-Fi连接（更灵活，推荐）： 首先用USB线完成初次连接并授权调试。

  # 1. 将adb切换为TCP/IP模式（端口通常为5555）
  adb tcpip 5555
  # 2. 断开USB线
  # 3. 查看手机IP地址（通常在设置->关于手机->状态信息中）
  # 4. 通过IP连接手机，假设手机IP是 192.168.1.100
  adb connect 192.168.1.100:5555
  

  再次运行 adb devices，你应该能看到一个通过 192.168.1.100:5555 连接的设备。

3.2 启动你的第一个AI自动化测试任务

假设我们想测试一个短视频APP的搜索关注功能。我们不需要写一行脚本，只需要告诉AI我们的目标。

在 Open-AutoGLM 项目目录下，打开命令行，运行如下命令（请替换其中的参数）：

python main.py \
  --device-id 192.168.1.100:5555 \  # 替换为你的设备ID或IP
  --base-url http://你的模型服务器IP:端口/v1 \ # 替换为你的AI服务地址
  --model "autoglm-phone-9b" \
  "打开抖音，搜索抖音号为'dycwo11nt61d'的博主，进入他的主页并关注他。"

参数解释：

• --device-id：就是你用 adb devices 看到的那个设备标识。
• --base-url：这里需要填入一个能提供 autoglm-phone-9b 模型服务的API地址。对于初步体验，你可以使用官方提供的测试端点或自行在云服务器上部署vLLM服务（这涉及另一部分部署工作，本文暂不展开）。
• 最后的字符串：这就是你的“测试用例”。用自然语言描述你想要完成的任务。

当你运行命令后，神奇的事情发生了：AI会启动抖音（如果已安装），自动点击搜索框，输入指定的抖音号，找到用户，进入主页，并点击关注按钮。整个过程完全自动化，就像有一个无形的测试员在操作手机。

3.3 使用Python API进行更灵活的测试

除了命令行，你还可以用Python代码来编写更复杂的测试流程，集成到你的测试框架中。

from phone_agent.adb import ADBConnection, list_devices
from phone_agent.agent import PhoneAgent

# 1. 连接设备
conn = ADBConnection()
success, message = conn.connect("192.168.1.100:5555")
print(f"连接状态: {message}")

# 2. 初始化AI代理
agent = PhoneAgent(
    device_id="192.168.1.100:5555",
    base_url="http://你的模型服务器IP:端口/v1",
    model="autoglm-phone-9b"
)

# 3. 执行一系列测试任务
test_tasks = [
    "打开设置，进入‘应用管理’",
    "找到‘抖音’应用，点击进入",
    "清除该应用的全部缓存和数据",
    "返回桌面，重新打开抖音",
    "在首页向上滑动三次，观看视频",
]

for task in test_tasks:
    print(f"执行测试: {task}")
    result = agent.run(task)
    print(f"结果: {result}")
    # 这里可以添加断言，检查result中的状态或截图是否符合预期

# 4. 任务完成，断开连接
conn.disconnect("192.168.1.100:5555")

这段代码展示了一个简单的测试场景：清理APP数据后重新打开并执行一些操作。你可以在此基础上，扩展出数据校验、截图对比、性能监控等完整的自动化测试用例。

4. 在APP测试与验证中的实战应用

了解了基础操作后，我们来看看Open-AutoGLM在测试领域具体能做什么。

4.1 核心应用场景

1. 复杂业务流程回归测试：

   • 场景：测试一个电商APP的完整下单流程。“从首页搜索商品‘篮球’，选择第一个商品，选择尺码和颜色，加入购物车，进入购物车结算，使用测试账号登录，选择地址，提交订单。”
   • 优势：用一句话替代数十行脚本。即使商品列表UI微调，只要AI能识别“加入购物车”按钮，测试就能继续执行。

2. 跨页面功能验证：

   • 场景：验证一个社交APP的消息同步功能。“在手机A上给用户B发送消息‘Hello Test’，然后在手机B上登录用户B的账号，检查消息列表是否收到该消息。”
   • 实现：可以编写脚本，控制两个AI代理分别操作两台手机，协同完成测试。

3. 探索性/猴子测试：

   • 场景：对新上线的界面进行随机探索。“在当前页面随机点击可点击的元素，持续5分钟，记录是否有崩溃或界面异常。”
   • 优势：AI可以基于屏幕内容智能地选择可能的操作点，比完全随机的“猴子测试”更高效，更容易发现逻辑错误。

4. 兼容性测试辅助：

   • 场景：在多个不同品牌、分辨率的手机上，执行同一套核心业务流测试。
   • 优势：一份自然语言描述的测试用例，可以在多种设备上运行，无需为每种设备适配定位脚本。

4.2 一个完整的测试案例：验证APP登录模块

假设我们要测试一个APP的登录功能，包括正常登录、错误密码处理、忘记密码流程。

传统脚本化测试：需要为用户名输入框、密码输入框、登录按钮、错误提示框等元素编写定位器，并编写多个测试函数。

使用Open-AutoGLM的测试思路：

1. 编写自然语言测试用例集：

   test_cases = {
       "tc_login_success": "使用账号‘test@example.com’和密码‘123456’登录，检查是否跳转到首页。",
       "tc_login_wrong_pwd": "使用账号‘test@example.com’和错误密码‘wrong’登录，检查页面是否提示‘密码错误’。",
       "tc_forgot_pwd": "点击‘忘记密码’链接，输入邮箱‘test@example.com’发送重置邮件，检查是否收到发送成功的提示。",
   }
   

2. 执行与断言：

   • 让AI执行 tc_login_success。
   • 执行完成后，让AI对当前屏幕进行“提问”：“当前页面是首页吗？”或者“页面上是否显示了‘登录成功’的文字？”。根据AI的回答来判断测试通过与否。
   • 也可以在执行前后进行截图，通过简单的图像比对或OCR来验证结果。

3. 生成测试报告：将AI执行每一步的截图、屏幕理解和操作日志记录下来，自动生成一份可视化的测试报告。

4.3 优势与当前局限

优势：

• 门槛极低：测试人员无需精通编程和UI定位技术，用自然语言即可设计用例。
• 维护成本低：对UI变化的适应性更强。
• 意图驱动：更贴近真实用户行为，能发现一些脚本测试发现不了的交互逻辑问题。
• 快速原型验证：产品经理或开发者可以快速验证一个新流程的可行性。

当前局限与注意事项：

• 依赖大模型服务：需要稳定的模型API，可能涉及成本。本地部署大模型对硬件有要求。
• 执行速度：由于每一步都需要模型进行“观察-思考-行动”，速度不如纯脚本测试快。
• 绝对精度：在极其复杂或动态的界面上，AI可能做出错误判断。通常需要结合确认机制或关键断言。
• 初期学习成本：需要团队熟悉新的测试范式和工作流。

5. 总结与展望

通过上面的实战，我们可以看到，Open-AutoGLM为APP自动化测试打开了一扇新的大门。它将测试从“元素定位”的脚本时代，推向“意图描述”的智能时代。你不再需要告诉机器“点击ID为‘com.xxx:id/login_btn’的按钮”，而是告诉它“请登录”。

对于快速迭代的互联网产品，尤其是UI频繁变动的早期阶段，这种测试方式能大幅提升验证效率。它非常适合作为传统自动化测试框架（如Appium, Airtest）的补充，用于覆盖那些业务流程复杂、维护脚本成本高的测试场景。

如何开始？建议从一些非核心但重复的测试任务开始尝试，比如：

• 每日构建后，自动安装新包并执行核心场景冒烟测试。
• 数据清理后的APP初始化流程测试。
• 探索新版本UI，寻找明显的布局错误。

随着多模态大模型能力的持续进步，这类AI智能体在软件测试领域的应用只会越来越深、越来越广。未来，我们或许真的可以只需对AI说一句：“帮我把这个版本的所有主要功能测一遍，生成一份报告”，剩下的就交给它了。

---

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。