1. 项目概述：当大模型遇上自动化测试

最近在折腾一个挺有意思的项目，核心就一句话：用Qwen3-32B这个大家伙，去驱动OpenClaw，完成对一个Web界面的全流程自动化验证。听起来是不是有点“让AI去测试AI工具”的套娃感？但实际做下来，发现这远不止是一个简单的技术缝合，而是对当前“AI+自动化”模式的一次深度压力测试和可行性验证。

简单来说，OpenClaw是一个基于大语言模型（LLM）的智能体框架，它能理解你的自然语言指令，然后像真人一样去操作浏览器，点击、输入、滚动、判断。而Qwen3-32B，是通义千问推出的一个320亿参数的大模型，能力相当强悍，尤其在代码、逻辑和长文本理解上表现突出。这个项目的目标，就是把Qwen3-32B作为OpenClaw的“大脑”，让它去完整地跑一遍某个Web应用（比如一个后台管理系统）的核心业务流程，从登录、导航到增删改查，最后验证结果是否正确。

这解决了什么问题？传统的UI自动化测试，无论是用Selenium还是Playwright，都需要测试工程师编写大量脚本，定义精确的元素定位器和操作逻辑。一旦页面结构有变动，维护成本很高。而“大模型驱动”的思路，是希望用自然语言描述测试场景和预期，让AI自己去理解页面、规划操作、执行并验证。它适合对AI应用开发、测试左移、智能体落地感兴趣的同学，无论是想探索LLM在真实场景中的边界，还是为复杂Web应用寻找更灵活的自动化解决方案，这个项目都能给你带来一手经验。

2. 核心思路与技术选型解析

2.1 为什么是OpenClaw + Qwen3-32B？

这个组合并非随意搭配，背后有清晰的考量。首先看 OpenClaw ，它本质上是一个将LLM指令转化为浏览器操作的执行引擎。与需要自己从头搭建Agent逻辑相比，OpenClaw提供了几个关键优势：一是内置了网页内容理解能力（通过DOM解析和视觉模型），能“看到”页面上的按钮、输入框和文本；二是提供了动作执行层，可以直接调用浏览器API进行操作；三是设计了反思和重试机制，当操作失败时能尝试其他路径。这为我们省去了最复杂的底层交互搭建工作。

而选择 Qwen3-32B 作为驱动模型，则基于以下几点判断：

1. 强大的指令遵循与规划能力 ：32B参数规模在开源模型中属于第一梯队，对于“请登录系统，找到用户管理页面，创建一个名为‘测试用户’的账号”这类多步、复杂的自然语言指令，它的分解和规划能力远强于小参数模型。
2. 出色的代码与结构化数据理解 ：Web页面的DOM树本质是结构化数据，Qwen3-32B在代码和JSON等格式的理解上表现优异，能更好地解析OpenClaw从页面抓取的信息。
3. 长上下文支持 ：全流程测试涉及多个页面状态和操作历史，需要模型有足够的上下文窗口来记住“之前做了什么”和“现在要做什么”。Qwen3-32B支持128K上下文，足以容纳冗长的会话历史。
4. 可控的成本与部署灵活性 ：相比调用GPT-4等闭源API，本地或私有化部署Qwen3-32B虽然对硬件有要求（至少需要2张A100或等价的GPU），但数据更安全，且没有持续调用费用，适合进行大量、反复的测试实验。

注意：模型选型是动态的。也可以考虑Qwen2.5-32B-Instruct、DeepSeek-V2等同类优秀模型。关键在于评估模型的指令遵循、规划以及对你特定测试页面元素（如中文按钮文本）的理解能力。

2.2 项目架构与数据流设计

整个系统的运行遵循一个清晰的闭环：

用户输入测试用例（自然语言） -> OpenClaw封装为Prompt -> Qwen3-32B生成操作指令 -> OpenClaw执行浏览器操作 -> 获取页面新状态/结果 -> 反馈给Qwen3-32B进行验证与下一步决策 -> ... -> 输出测试报告

这个流程中，最关键的耦合点在于 OpenClaw如何与Qwen3-32B对话 。OpenClaw默认可能适配特定模型的API格式。我们需要确保传递给Qwen3-32B的Prompt包含所有必要信息：当前的页面URL、截屏或DOM摘要、可操作的元素列表、历史操作记录，以及最终的测试目标。

另一个设计重点是 验证机制 。传统自动化测试通过断言（assert）来验证。在这里，我们依赖Qwen3-32B的“判断力”。例如，在创建用户后，我们需要模型去检查用户列表是否出现了新条目，或者提示信息是否为“创建成功”。这需要我们在Prompt中明确告知模型什么是“成功”的标准（例如：“如果看到‘操作成功’的绿色提示框，或者在新页面的表格第一行找到用户‘测试用户’，则任务成功”）。

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

3.1 OpenClaw部署与模型接入

OpenClaw的部署有多种方式，这里以 Docker部署 为例，最为简洁。首先，确保你的服务器或本地机器安装了Docker和NVIDIA Container Toolkit（如果要用GPU加速模型推理）。

# 1. 拉取OpenClaw镜像
docker pull openwebui/openclaw:latest

# 2. 运行容器，关键在环境变量配置
docker run -d \
  --name openclaw \
  --gpus all \  # 如果使用GPU
  -p 3000:8080 \  # 将容器内8080端口映射到本机3000
  -e OPENCLAW_MODEL_PROVIDER="vllm" \  # 指定模型服务后端
  -e OPENCLAW_MODEL_NAME="Qwen/Qwen3-32B-Instruct" \  # Hugging Face模型ID
  -e VLLM_API_BASE="http://your-vllm-server:8000/v1" \  # 指向你的Qwen3-32B推理服务
  -e OPENCLAW_BROWSER_TYPE="chromium" \
  openwebui/openclaw:latest

这里的关键是 VLLM_API_BASE 。你需要先单独部署一个Qwen3-32B的推理服务。推荐使用 vLLM ，它对Transformer模型推理做了极致优化，吞吐量高。

# 在一台有GPU的机器上部署vLLM服务
pip install vllm
# 启动服务，指定模型。注意模型需要提前从Hugging Face下载好。
python -m vllm.entrypoints.openai.api_server \
  --model /path/to/your/Qwen3-32B-Instruct \
  --served-model-name Qwen3-32B-Instruct \
  --port 8000 \
  --tensor-parallel-size 2  # 根据你的GPU数量调整

这样，OpenClaw就会通过OpenAI兼容的API格式，将请求发送到你的vLLM服务，调用Qwen3-32B模型。

3.2 测试目标Web应用准备

为了演示，我们假设测试一个简单的开源后台管理系统，比如 Django Admin 或 Forestry 。你需要将其在本地或测试环境运行起来。关键是要确保OpenClaw能访问到该应用的地址（如 http://localhost:8000/admin ）。

更重要的准备工作是 梳理测试用例 。我们不能给模型一个模糊的指令。需要将“全流程验证”拆解成原子化的、可被模型理解的任务。例如：

• 任务1（登录） ： “访问 http://localhost:8000/admin ， 在用户名输入框填入‘admin’， 在密码输入框填入‘admin123’， 点击‘登录’按钮。”
• 任务2（导航） ： “登录成功后，在左侧导航栏找到并点击‘用户’或‘Users’菜单项。”
• 任务3（创建） ： “在用户列表页面，点击‘添加用户’或‘Create’按钮。在表单中，将‘用户名’字段填为‘test_user_001’，‘邮箱’填为‘test@example.com’，然后点击页面底部的‘保存’按钮。”
• 任务4（验证） ： “保存后，请检查页面是否出现‘用户创建成功’的提示信息，并回到用户列表，确认第一条或最新一条数据的用户名是‘test_user_001’。”

将这些用例结构化（例如用YAML或JSON存储），便于后续批量执行和结果比对。

3.3 OpenClaw技能（Skill）与提示词工程

OpenClaw的“技能”是其强大之处，你可以自定义技能来封装常用操作或复杂逻辑。对于我们的测试场景，可以创建几个关键技能：

1. 断言技能 ： 虽然依赖模型判断，但我们可以提供一个技能，让模型调用它来“正式记录”一个验证点。例如，技能 assert_text_present(text) ，内部逻辑是让模型在当前页面查找指定文本，如果找到，则在测试报告中记录一条成功断言。
2. 表单填充技能 ： 针对目标应用的表单结构，可以创建智能填充技能。模型只需调用 fill_form({“username”: “test”, “email”: “test@example.com”}) ，技能内部会尝试匹配标签和输入框，提高操作准确性。

提示词工程是灵魂 。发给Qwen3-32B的初始指令（System Prompt）需要精心设计：

你是一个专业的Web自动化测试助手。你将通过OpenClaw控制浏览器。
你的目标：严格遵循用户的测试指令，完成对指定Web应用的操作流程。
规则：
1. 在每一步，你都会收到当前的页面截图描述和可点击元素列表。
2. 你必须基于当前页面状态和最终目标，决定下一步最合适的操作（如click, type, scroll等）。
3. 操作必须精确。优先使用元素ID，其次是唯一的文本内容。
4. 每次操作后，等待页面加载完成（你会收到新状态）。
5. 当用户要求验证时，仔细检查页面内容，给出明确的“验证通过”或“验证失败”的结论，并引用页面上的文本证据。
6. 如果操作失败或页面不符合预期，请描述问题并尝试另一种可行的操作路径。

当前测试应用：员工管理系统 (http://localhost:8000)
最终验证目标：成功创建一名新员工并能在列表中找到。
现在，开始执行第一个任务：登录系统。

这个Prompt设定了角色、规则、上下文和目标，能极大提升模型行为的稳定性和准确性。

4. 全流程测试执行与问题实录

4.1 登录与导航环节的典型挑战

启动测试后，第一个任务“登录”就可能会遇到问题。即使给了明确的URL和账号密码，模型也可能“犯傻”。常见情况有：

1. 元素定位偏差 ： 模型可能试图点击一个看起来像按钮的 <div> ，而不是真正的 <button> 或 <input type="submit"> 。这是因为OpenClaw提供的元素列表可能包含多个可交互候选，模型选择了置信度不高但描述匹配的那个。

• 解决方案 ： 在OpenClaw的配置中，可以调整其提供给模型的元素筛选策略，例如优先提供带有标准ARIA角色（ button , link ）或特定属性（ id , data-testid ）的元素。同时，在Prompt中强调“优先使用具有明确语义的角色或ID”。

2. 等待与异步加载 ： 点击登录后，页面可能跳转或异步加载。如果模型在页面完全加载前就试图进行下一步操作（如寻找导航菜单），会失败。

• 解决方案 ： 利用OpenClaw的内置等待机制，或自定义技能。例如，创建一个 wait_for_navigation(预期URL或标题关键词) 技能，让模型在关键操作后调用，强制等待直到条件满足。

3. 验证码或二次验证 ： 如果测试环境有这类障碍，纯UI自动化几乎无法绕过。这属于测试环境的特殊处理，需要在测试前关闭，或为模型设计一个“手动干预”的断点。

4.2 数据操作与状态验证的实践

进入核心的数据操作流程，比如创建一条记录，挑战更大。以创建用户为例：

步骤一：找到创建入口 。模型需要理解“添加用户”可能对应“Add User”、“新建”、“Create”、“+”图标等多种表现形式。我们的Prompt里提到了这些同义词会有帮助，但更可靠的是在应用开发阶段就为关键元素加上测试专用的属性，如 data-testid="create-user-btn" 。如果没有，则依赖模型对图标和上下文的理解能力。

步骤二：填写表单 。这是最容易出错的环节。一个表单可能有必填项、选填项、下拉框、日期选择器等。

• 下拉框处理 ： 模型需要先“点击”下拉框，然后在弹出的选项列表中“点击”目标项。这需要两个连续且精准的操作。实践中发现，如果下拉框选项是动态加载的，模型可能在选项弹出前就执行了下一步点击，导致失败。需要在技能层面实现一个 select_dropdown(element_label, option_text) 的复合操作，内部处理好点击和等待的逻辑。
• 日期选择 ： 让模型操作日期控件极其困难。最佳实践是，如果前端使用了复杂组件，在测试环境中将其替换为普通输入框，或者通过后端API直接创建数据，绕过前端UI。

步骤三：保存与验证 。点击保存后，验证是关键。

1. 成功提示验证 ： 让模型寻找“操作成功”、“User created successfully”等提示文本。这里要注意提示可能是短暂的Toast通知，几秒后消失。OpenClaw需要配置足够快的轮询频率来捕捉它，或者让模型在点击保存后立即执行“查找特定文本”的操作。
2. 列表数据验证 ： 这是更可靠的验证方式。让模型导航回列表页，并“判断列表中新出现了一条数据，且其‘用户名’字段值为‘test_user_001’”。这需要模型具备一定的表格数据解析能力。我们可以让OpenClaw将列表区域的HTML表格结构或关键文本提取出来，以更结构化的方式（如JSON）喂给模型，降低其理解难度。

4.3 执行日志与结果分析

OpenClaw会生成详细的执行日志，包括每一步模型接收到的页面信息、模型做出的决策（操作指令）、执行结果以及模型的自我评论。分析这些日志是优化整个流程的关键。

例如，日志可能显示：

[STEP 3] Model Decision: click on element with text “提交”
[ACTION] Attempted to click, but element not found or not interactable.
[MODEL REFLECTION] 点击“提交”失败。页面底部有一个更显眼的蓝色按钮，文字是“保存更改”，这可能是真正的提交按钮。我应该尝试点击它。
[STEP 3 RETRY] Model Decision: click on element with text “保存更改”
[ACTION] Success.

从这个日志可以看出，模型的反思和重试机制生效了。我们可以据此优化Prompt，强调“注意按钮的变体表述，如‘提交’、‘保存’、‘确认’等”。

最终，我们需要一个汇总报告，格式如下：

测试用例ID	用例描述	执行状态	关键步骤日志	最终验证结果	耗时
TC_LOGIN_001	使用正确凭据登录	成功	1. 访问首页 √ 2. 输入用户名 √ 3. 输入密码 √ 4. 点击登录 √	成功跳转到仪表盘，页面标题包含“Dashboard”	12s
TC_USER_CREATE_001	创建新用户	部分成功	1. 导航至用户页 √ 2. 点击添加 √ 3. 填写表单 √ 4. 点击保存 √ 5. 验证提示 ✗	用户创建成功，但未捕捉到成功Toast提示（可能消失过快）	45s

5. 踩坑经验与效能优化指南

5.1 稳定性提升：给AI测试员“降降噪”

直接让大模型操作Web界面，初期稳定性可能不足50%。通过以下方法，我们可以将其提升到80%甚至更高：

1. 页面信息过滤与增强 ： 不要将完整的、嘈杂的DOM树扔给模型。OpenClaw可以配置只提取关键区域的元素，或者为元素添加语义描述。例如，将 <button class=“btn”>Save</button> 处理成 {“action”: “click”, “description”: “一个蓝色的保存按钮”, “identifier”: “button:contains(‘Save’)”} ，能极大提升模型识别的准确率。
2. 操作原子化与技能封装 ： 将“创建一个用户”这样的高层任务，在调用模型之前，就由测试框架拆解成一系列已知的、稳定的低层技能调用。例如，框架自己知道创建用户需要先调用 navigate_to(“用户管理”) ，再调用 click_create_button() ，然后调用 fill_form_with_data(data) 。模型只在遇到未知页面或需要决策时才介入。这是一种“规划层”与“执行层”的分离，混合了传统脚本的稳定性和AI的灵活性。
3. 设置操作超时与重试策略 ： 在OpenClaw或外层封装脚本中，为每一步操作设置合理的超时时间（如30秒）。如果超时，自动重试该步骤，或触发模型的反思流程。对于点击后页面加载慢的情况，这非常有效。

5.2 验证环节的可靠性设计

依赖模型的自然语言理解来做验证，是最大的不确定性来源。必须设计双重甚至三重验证机制：

1. 结构化数据验证 ： 这是最可靠的。在测试的后端，通过数据库查询或API调用，直接检查数据是否被正确创建或修改。这可以与UI操作并行或在其之后执行，作为“黄金标准”。
2. 多模型交叉验证 ： 对于关键的UI验证点（如成功提示），可以让Qwen3-32B做出判断后，再用一个轻量级的、专门训练过的文本分类模型（或另一个大模型如GLM）对页面截图或关键文本区域进行二次判断。只有两者都认为成功，才判定为通过。
3. 明确且具体的成功标准 ： 给模型的验证指令必须像法律条文一样精确。避免使用“检查是否成功”这种模糊表述。要用：“如果页面顶部出现包含‘成功’字样的绿色横幅，并且横幅文本中包含‘用户’和‘创建’这两个词，则判定为成功；否则，判定为失败。”

5.3 成本与性能的平衡术

Qwen3-32B本地推理对GPU资源要求高，一次复杂的多步测试可能会产生数十次模型调用，耗时几分钟。在追求稳定性的同时，也要考虑效率。

1. 缓存与记忆 ： 对于重复的、不变的页面（如登录页），模型的分析结果可以缓存。下次遇到相同页面状态时，直接使用缓存的操作建议，跳过模型推理。
2. 使用小模型处理简单决策 ： 并非所有步骤都需要32B大模型。对于“点击登录按钮”这种极其明确的操作，可以训练或使用一个百亿参数以下的小模型，甚至基于规则来判断，从而大幅降低整体延迟和资源消耗。构建一个模型路由层，根据任务复杂度分派给不同规模的模型。
3. 并行执行独立用例 ： 如果测试环境支持，可以启动多个OpenClaw浏览器实例，并行执行不同的测试用例，充分利用GPU的并行计算能力。

经过一系列调优，我们最终可能得到一个混合架构：稳定的导航和表单操作用预定义的技能脚本完成，只在遇到新页面、复杂验证或异常处理时才唤醒Qwen3-32B。这样既保证了核心流程的稳定性，又保留了AI处理边界情况的能力。

这个项目做下来，最深的一点体会是，现阶段让大模型完全替代人工编写测试脚本还不现实，但它作为一个强大的“增强工具”和“探索性测试员”已经绰绰有余。它特别适合用来快速覆盖那些变动频繁、逻辑复杂的长流程场景，或者生成初始的测试脚本骨架。最大的收获不是做出了一个多稳定的测试机器人，而是通过这个过程，深刻地理解了当前多模态大模型在理解图形界面、进行序列决策时的强项与短板，这些认知对于设计下一代AI原生应用或测试工具，有着直接的价值。如果真要投入生产，一个务实的建议是：从最核心、最稳定的一两个业务流程开始，用“AI辅助+人工校验”的模式跑通闭环，积累Prompt和技能库，再逐步扩大范围，别想着一口吃成胖子。