OpenClaw自动化测试：GLM-4.7-Flash驱动浏览器回归验证

1. 为什么选择OpenClaw做自动化测试？

去年接手一个遗留的Web项目时，我遇到了典型的测试困境——每次代码改动后，都需要手动执行47个关键路径的回归测试。某次凌晨3点，我在重复点击第38个测试用例时突然想到：既然AI能理解自然语言，为什么不让它帮我操作浏览器？

这就是我探索OpenClaw自动化测试的起点。与传统基于Selenium的测试框架不同，OpenClaw的核心优势在于：

1. 自然语言驱动：直接告诉AI"测试登录功能，输入错误密码应显示红色警告"，而不需要编写xpath定位代码
2. 动态适应能力：当页面DOM结构变化时，AI能通过视觉理解找到"类似登录按钮的元素"
3. 智能结果判断：不仅检查元素是否存在，还能识别"这个错误提示的红色不够明显"等主观质量缺陷

特别在使用GLM-4.7-Flash模型后，我发现其响应速度比常规大模型快3倍以上，这对需要高频交互的测试场景至关重要。

2. 环境搭建与模型配置

2.1 基础环境准备

我的测试环境配置如下：

• 硬件：MacBook Pro M1/16GB（GLM-4.7-Flash对硬件要求较低）
• 系统：macOS Sonoma 14.5
• 浏览器：Chrome 125+（需启用远程调试端口）

# 启动Chrome调试端口
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

2.2 OpenClaw与GLM-4.7-Flash对接

通过ollama部署GLM-4.7-Flash后，在~/.openclaw/openclaw.json中配置模型端点：

{
  "models": {
    "providers": {
      "ollama-glm": {
        "baseUrl": "http://localhost:11434",
        "api": "openai-completions",
        "models": [
          {
            "id": "glm-4-7-flash",
            "name": "GLM-4.7-Flash",
            "contextWindow": 128000,
            "maxTokens": 4096
          }
        ]
      }
    }
  }
}

验证配置是否生效：

openclaw models list
# 应看到glm-4-7-flash状态为available

3. 构建自然语言测试框架

3.1 测试用例生成

我在项目根目录创建test_cases文件夹，每个测试用例用Markdown编写：

# 登录功能测试
## 测试目标
验证错误密码场景的UI反馈

## 操作步骤
1. 访问/login页面
2. 在用户名栏输入"testuser"
3. 在密码栏输入"wrongpassword" 
4. 点击登录按钮

## 预期结果
- 页面应显示红色文字提示"密码错误"
- 提示信息应在输入框下方3-5像素处
- 登录按钮应变为禁用状态

OpenClaw会将这些Markdown转换为可执行操作序列，关键优势在于：

• 非技术人员也能编写用例
• 可以描述模糊需求（如"红色文字"而非具体的RGB值）
• 支持添加视觉验收标准

3.2 页面元素智能定位

传统测试脚本最脆弱的部分是元素定位。当开发把id="loginBtn"改成data-testid="submit-button"时，所有测试都会失败。而OpenClaw采用混合定位策略：

1. 优先尝试传统定位：通过ID/class等属性查找
2. 视觉辅助定位：截图后让AI识别"看起来像登录按钮的元素"
3. 语义理解定位：寻找"用于提交表单的主要按钮"

实际测试中，即使开发将登录按钮从<button>改为<div role="button">，测试仍能继续运行。

3.3 结果验证与报告

测试完成后，OpenClaw会生成包含三种验证结果的报告：

1. 结构化验证：DOM元素是否存在、属性值是否正确
2. 视觉验证：截图对比基准图片的PSNR值
3. 语义验证：AI判断"这个错误提示是否足够醒目"

示例报告片段：

## 登录功能测试结果
✅ 密码错误提示文字存在（实际值："密码错误"）  
⚠️ 文字颜色为#FF3333，与标准#FF0000有轻微差异  
❌ 提示信息位置偏差8px（预期3-5px）

4. 实战中的经验与优化

4.1 Token消耗控制

初期测试时，每个操作步骤都调用大模型导致成本飙升。通过以下策略降低90%的Token消耗：

1. 操作记忆化：对成功过的操作生成xpath缓存
2. 步骤批处理：将"输入用户名→输入密码→点击登录"合并为单个"登录操作"
3. 本地小模型：用GLM-4.7-Flash处理简单步骤，仅复杂场景调用大模型

// 在配置文件中启用缓存
{
  "skills": {
    "testing": {
      "enableCaching": true,
      "batchSimpleSteps": true 
    }
  }
}

4.2 稳定性提升技巧

遇到最棘手的问题是"闪烁现象"——元素还没加载完成AI就尝试操作。我的解决方案是：

1. 智能等待：AI会监测"页面是否停止网络请求"+"主要元素是否可见"
2. 重试机制：对失败操作自动尝试替代方案（如先滚动再点击）
3. 环境隔离：每个测试用例启动新的浏览器上下文

# 启动测试时添加隔离参数
openclaw test run --isolate --retry 3

4.3 与CI/CD集成

虽然OpenClaw定位是个人工具，但我成功将其接入GitHub Actions：

name: OpenClaw Test
on: [push]
jobs:
  test:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - run: |
          brew install ollama
          ollama pull glm-4-7-flash
          npm install -g openclaw
          openclaw test run --headless

关键点是：

• 使用macOS runner确保浏览器兼容性
• 在无GUI模式下仍可通过截图进行视觉验证
• 通过--threshold 85设置验收分数阈值

5. 适合与不适合的场景

经过三个月实践，我认为OpenClaw特别适合：

1. 快速迭代的项目：当DOM结构频繁变动时，传统测试脚本维护成本极高
2. 视觉验收测试：验证UI是否符合设计稿的"感觉"
3. 探索性测试：临时增加"测试支付流程的所有边界条件"这类非预设用例

而不适合：

1. 性能测试：AI操作速度远低于专业工具
2. 超精确验证：如"像素级对齐"需求
3. 企业级流水线：缺乏完善的权限管理和审计功能

---

获取更多AI镜像

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