基于GLM-4.7-Flash与OpenClaw的AI驱动UI自动化测试实践

1. 项目概述：当大模型开始“动手”测试

最近在折腾一个挺有意思的项目，叫OpenClaw。简单来说，它让大语言模型（比如GLM-4.7-Flash）不再只是“动嘴皮子”，而是能真正“动手”去操作电脑界面，完成一系列自动化测试任务。这听起来有点像科幻电影里的场景，但现在已经能实实在在地跑起来了。我花了些时间，把GLM-4.7-Flash模型接入了OpenClaw框架，让它驱动浏览器，模拟真人点击、输入、滚动，并对页面结果进行智能验证。整个过程，从环境搭建到脚本调试，踩了不少坑，也积累了一些心得。

这个项目的核心价值在于，它试图解决传统UI自动化测试的一个老大难问题：维护成本高。传统的基于Selenium或Appium的脚本，严重依赖页面元素的定位器（如XPath、CSS Selector）。一旦前端UI改版，哪怕只是一个按钮的ID变了，整个测试脚本就可能“瘫痪”，需要人工去逐个修复定位器。而OpenClaw的思路是，让AI“看懂”屏幕，用自然语言（比如“点击登录按钮”）来驱动操作，并由AI来判断操作结果（比如“验证登录成功后的欢迎语”）。这样一来，测试逻辑更贴近人类直觉，对UI变化的适应性理论上会更强。

它特别适合那些UI变动频繁、但又对功能稳定性要求高的项目，比如快速迭代的SaaS应用、内部管理系统，或者需要验证复杂交互流程的场景。如果你正在为自动化测试脚本的脆弱性头疼，或者对AI如何落地到具体工程实践感兴趣，那接下来的内容应该能给你一些直接的参考。

2. 核心思路：让AI成为“测试执行员”

传统的自动化测试，本质上是“录制与回放”或“脚本编程”。工程师需要精确地告诉计算机：“去找到这个ID为‘submit-btn’的元素，然后点击它。” 这种方式非常精确，但也非常脆弱。OpenClaw引入大模型，是想把指令从“精确的坐标或定位器”升级为“模糊的自然语言描述”，把验证从“字符串完全匹配”升级为“语义理解匹配”。

2.1 架构拆解：OpenClaw如何工作

OpenClaw的架构可以理解为一个“大脑”（大模型）指挥一个“手脚”（浏览器控制器）在工作。整个流程是一个闭环：

1. 观察（Observation）：OpenClaw通过浏览器驱动（如Playwright）获取当前页面的完整状态。这不仅仅是HTML源码，更关键的是通过OCR（光学字符识别）技术获取屏幕上的可视文本，以及通过计算机视觉对UI元素进行截图和描述。这一步是为了给“大脑”提供尽可能丰富的上下文信息，模拟人类测试员眼睛看到的东西。
2. 思考（Planning）：将当前页面状态（截图、文本、可能的操作元素列表）和测试目标（如“完成用户登录”）一起，构造为一个提示词（Prompt），发送给GLM-4.7-Flash模型。模型的任务是分析当前状况，并决定下一步应该执行什么操作。例如，模型可能会输出：“当前在登录页面，识别到用户名输入框、密码输入框和登录按钮。下一步应是在用户名框输入‘test_user’。”
3. 执行（Action）：OpenClaw解析模型返回的指令，将其转化为Playwright等底层驱动能理解的具体命令，如page.fill(‘input[placeholder=”用户名”]’, ‘test_user’)。这里有一个关键点：OpenClaw需要将模型描述的“用户名输入框”映射到页面中真实的那个输入框元素。这通常通过结合元素的视觉特征、文本标签、ARIA属性等多模态信息来实现。
4. 验证（Verification）：执行操作后，再次进入“观察”阶段，获取新的页面状态。然后，将新的状态和预期结果（如“页面应显示‘欢迎，test_user’”）再次提交给模型。模型需要判断当前页面是否满足了预期。它可能回答：“页面顶部出现了‘欢迎，test_user’的导航栏，登录成功。” 这个判断是基于语义的，而不是简单的字符串匹配。

这个循环持续进行，直到完成整个测试用例。GLM-4.7-Flash在这里扮演了“测试策略制定者”和“结果评判官”的双重角色。

2.2 为什么选择GLM-4.7-Flash？

在众多大模型中，我选择GLM-4.7-Flash作为驱动核心，主要基于几个实际工程考量：

• 响应速度与成本：“Flash”版本通常意味着在保持不错能力的前提下，推理速度更快，API调用成本更低。在自动化测试这种需要频繁调用模型进行“观察-思考”循环的场景下，延迟和成本是必须考虑的因素。长时间的等待会让测试失去意义。
• 多模态与指令跟随能力：虽然GLM-4.7-Flash可能不是参数最大的，但其在指令跟随、上下文理解和基础的多模态（结合文本和图像信息）任务上表现均衡。我们的Prompt需要清晰描述包含文本和图像信息的混合上下文，并要求模型输出结构化的下一步动作，这对模型的指令理解精度要求很高。
• API可用性与稳定性：对于项目部署，一个提供稳定、易用API的服务至关重要。这避免了自建模型服务的复杂性和硬件成本，让开发者能更专注于测试逻辑本身。

注意：模型的选择不是一成不变的。这个架构是模型无关的（Model-agnostic）。你可以根据实际需求，替换为其他支持视觉或多模态理解的模型，如GPT-4V、Claude 3.5 Sonnet等。GLM-4.7-Flash在这里是一个在性能、成本和效果上取得不错平衡的起点。

3. 环境搭建与核心配置实战

理论讲完，我们进入实战环节。要让OpenClaw跑起来，需要搭建一个包含“控制中心”和“执行环境”的完整系统。

3.1 基础环境准备

我的实验环境是一台Ubuntu 22.04的云服务器，当然在Windows或macOS上通过Docker部署也是主流选择。以下是核心组件：

1. Python环境：OpenClaw核心是Python编写的。建议使用Python 3.9+，并使用venv或conda创建独立的虚拟环境。

   # 创建并激活虚拟环境 python -m venv openclaw-env source openclaw-env/bin/activate # Linux/macOS # openclaw-env\Scripts\activate # Windows

2. 安装OpenClaw：目前OpenClaw项目更新活跃，建议从官方GitHub仓库克隆最新代码。

   git clone <OpenClaw官方仓库地址> cd openclaw pip install -e . # 以可编辑模式安装，方便修改代码 # 或者根据requirements.txt安装依赖 pip install -r requirements.txt

   这里可能会遇到一些依赖冲突，特别是与PyTorch、CUDA版本相关的。一个常见的坑是Playwright的浏览器下载。需要运行playwright install来安装它所需的Chromium、Firefox等浏览器二进制文件。
3. 安装浏览器驱动与OCR工具：OpenClaw依赖Playwright进行浏览器操控。同时，为了从屏幕截图中提取文字，需要OCR引擎。Tesseract是一个免费开源的选择。

   # 安装Playwright及浏览器 pip install playwright playwright install chromium # 通常安装Chromium就够了 # 安装Tesseract OCR (Ubuntu示例) sudo apt update sudo apt install tesseract-ocr # 如果需要中文识别，安装语言包 sudo apt install tesseract-ocr-chi-sim # 简体中文

3.2 GLM-4.7-Flash API接入配置

这是连接“大脑”的关键一步。你需要一个GLM-4.7-Flash的API访问权限（例如，通过智谱AI开放平台获取）。配置通常在一个环境变量文件或配置文件中进行。

在OpenClaw的项目目录下，我创建了一个.env文件来管理敏感信息：

# .env 文件内容示例 OPENAI_API_BASE=https://open.bigmodel.cn/api/paas/v4/ # 假设GLM-4.7-Flash兼容OpenAI API格式 OPENAI_API_KEY=your_glm_api_key_here MODEL_NAME=glm-4-flash # 根据平台提供的实际模型名称填写

在OpenClaw的代码中，需要修改模型调用部分，使其指向正确的API端点并使用你的密钥。通常需要找到类似agent.py或llm_client.py的文件，修改其中初始化OpenAI客户端的地方：

# 示例代码片段，需根据OpenClaw实际代码结构调整 import os from openai import OpenAI client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_API_BASE") ) def call_glm_model(prompt, image_base64=None): messages = [{"role": "user", "content": prompt}] if image_base64: # 构造包含图像信息的消息内容，格式需参考GLM API文档 messages[0]["content"] = [ {"type": "text", "text": prompt}, {"type": "image_url", "image_url": {"url": f"data:image/jpeg;base64,{image_base64}"}} ] response = client.chat.completions.create( model=os.getenv("MODEL_NAME"), messages=messages, max_tokens=500 ) return response.choices[0].message.content

实操心得：不同大模型的多模态API输入格式可能有细微差别。GLM-4.7-Flash的API可能对图像数据的编码（如base64前缀data:image/jpeg;base64,）或消息结构有特定要求。务必仔细查阅对应平台的API文档，这是调试初期最容易出错的地方。可以先用一个简单的“描述这张图片里有什么”的Prompt进行测试，确保图像信息能被模型正确接收和理解。

3.3 OpenClaw核心配置文件解析

OpenClaw的行为由配置文件控制。一个典型的config.yaml可能包含以下关键部分：

# config.yaml 示例 agent: llm: "glm-4-flash" # 指定使用的模型 max_steps_per_task: 50 # 单个任务最大执行步骤，防止死循环 headless: false # 调试时设为false，可以看到浏览器操作过程；正式运行可设为true action_space: # 定义AI可以执行的动作类型，如点击、输入、滚动等 allowed_actions: ["click", "type", "scroll", "hover", "go_back", "wait"] observation: screenshot: true use_ocr: true ocr_lang: "chi_sim+eng" # 指定OCR识别语言 extract_elements: true # 是否尝试提取页面可交互元素信息 task: # 测试任务的起点和目标 start_url: "https://example.com/login" objective: "成功登录系统，并进入仪表盘页面。登录用户名为‘demo’，密码为‘password123’。"

这个配置文件是控制AI测试员行为的“宪法”。max_steps_per_task非常重要，它像一把保险锁，防止AI在某个步骤陷入困惑（比如找不到按钮）时无限尝试，耗尽资源。在调试阶段，务必把headless设为false，亲眼看着AI操作，是定位问题最快的方式。

4. 测试任务设计与Prompt工程技巧

有了运行环境，接下来就是设计测试任务。这不仅仅是给出一个URL，更重要的是如何向AI清晰地描述任务和验证标准。

4.1 编写有效的测试目标（Objective）

测试目标的描述质量，直接决定AI执行的效率和成功率。糟糕的指令会让AI像无头苍蝇。

• 反面例子：“测试登录功能。” （过于模糊，AI不知道从哪里开始，用什么账号，验证什么）
• 正面例子：“从 https://example.com 开始。使用用户名‘test_user’和密码‘Test@123’登录系统。登录成功后，你应该被重定向到一个包含‘仪表盘’或‘Dashboard’标题的页面，并且页面顶部菜单中应显示用户名‘test_user’。请完成登录并验证这些元素存在。”

好的目标应包含：

1. 明确的起点：start_url。
2. 具体的操作数据：用户名、密码、搜索关键词等。
3. 清晰的成功标准：用自然语言描述验证点，如“页面应包含‘订单提交成功’的提示信息”。可以包含多个验证点。
4. 必要的上下文约束：例如“请勿使用忘记密码功能”。

4.2 构造系统提示词（System Prompt）

系统提示词是植入AI“大脑”的底层指令，定义了它的角色和行为规范。OpenClaw通常会有默认的系统提示，但我们可能需要针对GLM-4.7-Flash进行微调。核心要点包括：

• 角色定义：“你是一个专业的网页自动化测试助手。”
• 能力范围：“你可以观察屏幕截图和OCR提取的文本，分析当前网页状态。”
• 行动规范：“你的每一步输出必须是一个具体的、可执行的动作，且只能从以下列表中选择：[click, type, scroll, wait, go_back]。对于type动作，必须同时提供要输入的文本。”
• 输出格式：“你的响应必须是严格的JSON格式：{"action": "click", "description": "点击登录按钮"}或{"action": "type", "text": "hello world", "description": "在搜索框输入关键词"}。”
• 思考链鼓励：“在输出最终动作前，请先简要分析当前页面和你下一步行动的理由。”（这可以通过Few-Shot示例在Prompt中实现）

注意事项：强制规定输出格式是稳定性的关键。大模型生成的自然语言可能多变，但通过Prompt将其约束为固定的JSON结构，下游程序才能可靠地解析。你可以在系统提示中提供一两个完整的思考-行动示例（Few-Shot Learning），能显著提升模型输出的规范性和准确性。

4.3 设计观察信息（Observation）的组装

每次循环，我们需要给模型组装当前的“观察”。这通常是一个结合了文本和图像的多模态Prompt。例如：

【当前页面观察】 屏幕文本摘要： - 页面顶部显示“欢迎登录” - 中间有两个输入框，分别有“邮箱/用户名”和“密码”的提示文字。 - 下方有一个蓝色按钮，文字是“登录”。 - 底部有一行小字“还没有账号？立即注册”。 当前页面截图：[附上Base64编码的截图] 【历史操作】 你刚刚打开了登录页面。 【当前任务目标】 使用用户名“demo”和密码“password123”登录系统，并验证登录后页面包含“主面板”字样。 【请思考并行动】 请分析当前页面状态，并决定下一步做什么。你的响应必须是上述JSON格式。

将OCR提取的文本清晰罗列，有助于模型快速定位关键信息，尤其是在截图分辨率不高或元素密集时。

5. 执行流程与关键环节调试

配置和任务设计好后，就可以启动测试了。运行命令通常很简单：

python run_task.py --config config.yaml

但真正的挑战在于调试AI执行过程中的各种“诡异”行为。

5.1 典型执行流程分解

以登录任务为例，一次成功的执行流程如下：

1. 初始化：OpenClaw启动浏览器，导航至start_url（登录页面）。
2. 首次观察：对登录页面截图，运行OCR获取所有文本，生成第一次观察Prompt。
3. 第一次决策：GLM-4.7-Flash收到Prompt，分析后输出：{"action": "type", "text": "demo", "description": "在用户名输入框中输入‘demo’"}。
4. 第一次执行：OpenClaw解析指令。这里有个关键步骤：元素定位。它需要把“用户名输入框”这个描述，映射到页面上真实的<input>元素。它可能结合OCR文本“邮箱/用户名”的位置、输入框的视觉特征（通过截图分析）、以及HTML属性来综合判断，然后调用Playwright执行page.fill(‘input[type=”text”]:near(:text(“邮箱/用户名”))’, ‘demo’)。
5. 循环继续：输入用户名后，再次截图观察。模型看到用户名已填入，下一步输出输入密码的动作。如此循环，直到点击登录按钮。
6. 最终验证：点击登录后，进入新页面。模型观察新页面，判断是否出现“主面板”等目标文本。如果判断成功，则任务完成；如果未发现，它可能会尝试继续操作（如等待、刷新）或最终报告失败。

5.2 调试与优化：解决AI的“迷惑”行为

在实际运行中，AI测试员经常会做出令人费解的操作。以下是我遇到的一些典型问题及解决思路：

问题1：AI在输入框里重复输入。

• 现象：AI在用户名框输入后，下一次观察又再次输入，覆盖了之前的内容。
• 根因：OCR识别可能不稳定，或者模型在观察中未能正确感知到输入框内已存在文本（尤其是带掩码的密码框）。
• 解决：
  • 增强观察：在组装给模型的文本摘要时，明确加入“用户名输入框当前内容为：‘demo’”这样的信息。这需要OpenClaw在OCR后，对输入框等元素的状态进行专门提取。
  • 修改动作空间：暂时禁止type动作对非空输入框操作，或设计一个clear_and_type的组合动作。
  • Prompt优化：在系统提示中强调：“在输入前，请先确认输入框是否已有内容。如果已有内容且正确，则无需再次输入。”

问题2：AI点击了错误或不可点击的元素。

• 现象：AI试图点击一个纯文本标题，或者一个被遮挡的按钮。
• 根因：模型仅从文本和视觉上判断“这像是一个按钮”，但缺乏对HTML元素可交互性的理解。
• 解决：
  • 丰富观察信息：除了OCR文本，将Playwright提取的可交互元素列表（如所有button、a、input及其属性）也提供给模型。例如：“可点击元素：1. 按钮，文本‘登录’，ID=‘submit-btn’；2. 链接，文本‘注册’...”。
  • 后置过滤：在模型输出点击动作后，执行前，用程序检查目标元素是否确实可点击（is_enabled()和is_visible()），如果不可点击，则将此动作标记为无效，重新请求模型决策。

问题3：AI陷入死循环，比如反复刷新页面。

• 现象：任务长时间不结束，AI在“刷新-观察-刷新”的循环中。
• 根因：模型始终认为未达到任务目标，而“刷新”是它知识库中一种常见的“尝试解决问题”的手段。
• 解决：
  • 设置步数限制：这就是max_steps_per_task的作用，强制中断。
  • 细化成功标准：将“登录成功”描述得更具体、更唯一。例如，不仅是“包含‘主面板’”，而是“URL变为/dashboard，且页面主要标题为‘主面板’”。
  • 引入负面指令：在Prompt中明确告知：“如果遇到页面无响应或找不到目标，请先尝试等待5秒，而不是刷新页面。”

问题4：验证阶段，模型对成功与否的判断过于“宽松”或“严格”。

• 现象：页面明明登录失败了，AI却报告成功；或者页面有细微差别（如多了个欢迎横幅），AI就报告失败。
• 根因：模型对“语义相符”的理解与人类有偏差。
• 解决：
  • 提供对比示例：在系统提示中，给出成功和失败的判断示例。例如：“成功案例：页面出现‘欢迎回来，张三’。失败案例：页面出现‘用户名或密码错误’。即使页面有‘欢迎’二字，但后面跟的是错误信息，也应判定为失败。”
  • 分步验证：将一个大目标拆解为多个原子化的验证点，让模型逐一判断。例如，先验证“URL是否正确”，再验证“关键欢迎语是否存在”。

6. 性能评估与实战经验总结

经过一段时间的实验，我对这种AI驱动的自动化测试模式有了更深的体会。

6.1 优势与潜力

• 抗UI变更能力强：这是最大亮点。前端将登录按钮从id=”login-btn”改成了>