1. 项目概述：当UI测试遇上大模型

最近在搞自动化测试的朋友，估计都听过一个词叫“AI驱动测试”。这玩意儿听起来挺玄乎，但说白了，就是让AI来帮你点点点、看看看，判断页面对不对。我折腾了快一个月，把阿里云开源的OpenClaw和通义千问的Qwen3.5-9B模型给搭了起来，专门用来跑UI自动化测试。实测下来，这组合确实有点东西，它不像传统的脚本那样死板，而是能“看懂”页面，然后“思考”下一步该点哪里、输入什么。

传统UI自动化，无论是用Selenium、Playwright还是Appium，核心都是写脚本：定位元素、执行操作、断言结果。脚本一多，维护成本就上来了，页面改个class名、ID，脚本可能就全挂了。而OpenClaw+Qwen3.5的思路是，你只需要告诉它“去登录页面，用账号test@example.com和密码123456登录”，它就能自己分析当前页面有哪些输入框、按钮，并执行操作。背后的“大脑”就是Qwen3.5-9B这个大语言模型，它负责理解你的自然语言指令，并生成对应的操作序列。

这个方案特别适合两类场景：一是快速验证核心业务流程，比如新版本上线前，让AI把主路径全跑一遍；二是处理那些元素定位不稳定、经常变动的页面，AI的视觉理解和推理能力有时比写死的XPath/CSS选择器更鲁棒。当然，它也不是银弹，速度上肯定比不上优化好的传统脚本，但对追求测试智能化和降低维护成本的同学来说，绝对值得深入玩一玩。

2. 核心组件解析：OpenClaw与Qwen3.5-9B是如何协同的

要搞明白这个方案，得先拆开看两个核心部分各自是干什么的，以及它们是怎么“握手”的。

2.1 OpenClaw：AI驱动的自动化执行器

OpenClaw你可以把它理解为一个“AI测试助手”的框架或者运行时环境。它本身不包含AI模型，但提供了一套标准的接口和协议（比如兼容MCP，即Model Context Protocol），让外部的AI模型（如Qwen3.5）能够“指挥”它去操作电脑。

它的工作流程是这样的：你通过命令行、API或者配置文件给OpenClaw一个任务描述，比如“在浏览器中打开百度，搜索OpenClaw”。OpenClaw会把这个描述，连同当前的屏幕截图、可操作的元素信息（通过无障碍访问接口或浏览器驱动获取）一起，打包成一个“上下文”（Context），然后发送给你配置好的AI模型（这里是Qwen3.5-9B）。AI模型分析这个上下文后，会返回一个具体的操作指令，比如“在地址栏输入 www.baidu.com 并回车”、“在搜索框输入‘OpenClaw’”、“点击‘百度一下’按钮”。OpenClaw收到指令后，再通过底层驱动（如Playwright）去执行这些原子操作。

所以，OpenClaw的核心价值在于 标准化 和 执行 。它定义了一套AI模型与真实操作系统/浏览器交互的“语言”，并负责把AI的“想法”落地为真实的鼠标点击和键盘输入。目前它支持Web、桌面应用甚至手机应用的自动化，潜力很大。

2.2 Qwen3.5-9B：任务规划与理解的“大脑”

Qwen3.5-9B是通义千问团队开源的一个90亿参数的大语言模型。在这个组合里，它扮演的是“指挥官”和“分析师”的角色。它的输入是自然语言任务+屏幕信息，输出是结构化的操作指令。

为什么是Qwen3.5-9B，而不是其他模型？首先，9B的参数量对于本地部署来说是一个甜点，对GPU显存要求相对友好（例如，INT4量化后大约需要6-8GB显存），推理速度也尚可。其次，Qwen系列模型在中文理解和代码/推理任务上表现一直不错，这对于解析中文测试需求和生成准确的操作指令至关重要。最后，它的开源协议友好，方便我们集成和二次开发。

模型的能力直接决定了测试的智能程度。一个好的“大脑”需要能：

  1. 准确理解意图 ：把“登录”这个指令，映射到“寻找用户名输入框、密码输入框和登录按钮”这一系列子目标。
  2. 强大的视觉-语言理解 ：能“看懂”截图，识别出哪个区域是按钮，哪个是输入框，并结合OCR技术读取文字标签。
  3. 逻辑规划能力 ：当操作失败（比如点了没反应），能尝试其他方案，比如检查是否有弹窗，或者换一种定位方式。

2.3 协同工作流拆解

两者协同的完整链条如下：

  1. 任务输入 ：用户给出指令“在电商网站下单商品iPhone”。
  2. 环境感知 ：OpenClaw启动浏览器，打开网站，并捕获当前屏幕的截图和DOM树（或无障碍树）。
  3. 上下文构建 ：OpenClaw将用户指令、截图、可交互元素列表等信息，格式化为模型能理解的Prompt。
  4. 模型推理 ：Prompt被发送至本地部署的Qwen3.5-9B模型。模型分析后，输出第一步操作： {“action”: “navigate”, “url”: “https://www.example.com”} 。
  5. 指令执行 ：OpenClaw接收指令，通过Playwright驱动浏览器跳转到目标网址。
  6. 循环迭代 ：页面加载后，重复步骤2-5。模型根据新页面，输出下一步操作，如 {“action”: “click”, “selector”: “#searchBox”} , {“action”: “type”, “text”: “iPhone”} ，直到完成“搜索-选择商品-加入购物车-结算-填写地址-支付”整个流程。
  7. 断言与报告 ：OpenClaw可以在关键步骤后，根据模型对页面状态的描述或预设的断言规则，判断测试是否通过，并生成测试报告。

这个流程的关键在于 迭代 。AI不是一次性生成所有步骤，而是走一步看一步，根据实时反馈调整策略，这更接近真人测试的行为模式。

注意 ：模型的推理速度直接影响测试执行时间。Qwen3.5-9B在中等配置的机器上，一次推理可能需要数秒。因此，这个方案目前更适合冒烟测试、探索性测试或对执行时间不敏感的回归测试场景，不适合需要极快反馈的单元测试或高频流水线。

3. 环境搭建与配置实战

理论讲完了，我们来点硬的。下面是我在Ubuntu 22.04系统上，从零开始搭建OpenClaw并配置本地Qwen3.5-9B模型的完整过程。这套配置同样适用于Windows和macOS，但部分命令和路径需要调整。

3.1 基础环境准备

首先，确保你的机器有NVIDIA显卡（建议显存>=8GB用于运行模型），并安装好显卡驱动、CUDA和cuDNN。这是能本地跑动Qwen3.5-9B的前提。可以用 nvidia-smi 命令检查。

接着，安装Python（建议3.9-3.11版本）和Node.js（OpenClaw的某些组件可能需要）。然后安装关键的Python包管理工具pip和模型部署工具Ollama。

# 更新系统包
sudo apt update && sudo apt upgrade -y

# 安装Python3和pip
sudo apt install python3 python3-pip -y

# 安装Node.js (例如使用nvm)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
# 重新打开终端或执行 source ~/.bashrc
nvm install 18
nvm use 18

# 安装Ollama (用于拉取和运行Qwen3.5-9B模型)
curl -fsSL https://ollama.ai/install.sh | sh

Ollama是一个简化大模型本地部署的工具，它帮你处理了模型下载、加载和提供API接口等一系列麻烦事。

3.2 部署Qwen3.5-9B模型

Ollama安装好后，拉取Qwen3.5-9B模型就一行命令。为了平衡速度和资源占用，我选择用 qwen2.5:9b （Qwen2.5是Qwen3.5的一个版本，性能接近，有时更易获取）的4位量化版本，这能大幅减少显存占用。

# 拉取并运行Qwen2.5-9B的4位量化模型
ollama run qwen2.5:9b

第一次运行会下载约5-6GB的模型文件。下载完成后，模型会自动启动，并提供一个本地的API服务，默认通常在 http://localhost:11434 。你可以打开另一个终端，用curl测试一下：

curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:9b",
  "prompt": "你好，请介绍下你自己。",
  "stream": false
}'

如果收到一段中文回复，说明模型部署成功。

实操心得 ：如果遇到Ollama回复非常慢的问题，有几个排查方向：

  1. 检查硬件 ：确认GPU是否被正确识别和使用。可以运行 ollama ps 查看模型运行状态，或使用 nvidia-smi 查看GPU利用率。
  2. 调整参数 ：在Ollama运行时，可以尝试限制上下文长度或使用更低的量化等级（如 qwen2.5:9b-text-q4_K_M ）。命令如 ollama run qwen2.5:9b-text-q4_K_M 。
  3. 系统资源 ：确保内存和Swap空间充足。模型推理时CPU和内存压力也很大。
  4. 网络问题 ：首次下载模型确保网络通畅。如果是公司内网，可能需要配置代理（此处需注意安全规范，仅提及可能原因，不展开）。

3.3 安装与配置OpenClaw

OpenClaw的安装方式有多种，这里我选择从源码安装，以便更好地理解其结构。

# 克隆OpenClaw仓库
git clone https://github.com/open-claw/openclaw.git
cd openclaw

# 安装Python依赖 (建议使用虚拟环境)
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# 根据官方文档，可能还需要安装一些系统依赖和浏览器驱动
# 例如，确保安装了Playwright所需的浏览器
playwright install chromium

安装完成后，最关键的一步是配置OpenClaw，让它知道去哪里找我们的“大脑”（Qwen3.5模型）。OpenClaw的配置通常在一个YAML或JSON文件中。我们需要创建一个配置文件，比如 config.yaml ，指定使用本地的Ollama服务。

# config.yaml 示例
model:
  provider: "ollama" # 指定使用Ollama作为模型提供商
  base_url: "http://localhost:11434" # Ollama服务的地址
  model: "qwen2.5:9b" # 指定的模型名称
  temperature: 0.1 # 温度参数，越低输出越确定，适合自动化任务

actions:
  - type: "web" # 定义操作类型为Web
    browser: "chromium" # 使用Chromium浏览器
    headless: false # 非无头模式，方便观察调试

然后，我们可以通过命令行启动OpenClaw，并指定这个配置文件：

openclaw --config ./config.yaml

如果一切顺利，OpenClaw会启动，并等待你输入任务指令。你也可以通过其提供的REST API或SDK来以编程方式驱动它。

3.4 验证与第一个测试任务

环境搭好了，我们来跑一个最简单的任务验证整个链路是否通畅。我们可以写一个简单的Python脚本，通过OpenClaw的Python SDK（如果提供）或直接调用其命令行来执行任务。

假设OpenClaw提供了 openclaw-client 的Python包，我们可以这样写：

# test_openclaw.py
import asyncio
from openclaw_client import OpenClawClient # 假设的客户端，具体名称请查官方文档

async def run_test():
    # 连接到本地运行的OpenClaw服务
    client = OpenClawClient(base_url="http://localhost:8080") # OpenClaw服务端口
    # 执行一个简单任务
    task_id = await client.execute_task(
        instruction="打开浏览器，访问百度首页(https://www.baidu.com)，在搜索框输入‘OpenClaw’并搜索。"
    )
    print(f"任务已提交，ID: {task_id}")
    # 可以轮询或等待任务完成，获取结果和截图
    # ...

asyncio.run(run_test())

如果看到浏览器自动打开，访问百度，并输入了“OpenClaw”，那么恭喜你，整个“AI驱动UI测试”的管道就打通了。

避坑指南 ：

  1. 端口冲突 ：确保OpenClaw默认端口（如8080）和Ollama端口（11434）没有被其他程序占用。
  2. 浏览器驱动 ：Playwright安装浏览器可能因网络问题失败，可以尝试设置国内镜像源或手动下载。
  3. 模型响应格式 ：OpenClaw对模型输出的JSON格式有严格要求。如果模型返回的操作指令无法解析，需要检查OpenClaw的Prompt模板和模型微调（如果有）是否匹配。初期调试时，可以将 headless 设为 false ，仔细观察AI的每一步决策和执行情况。

4. 编写与执行AI驱动的测试用例

环境跑通了，接下来就是怎么用它来写测试。和写Selenium脚本完全不同，AI驱动测试的核心是“描述任务”，而不是“编写步骤”。

4.1 测试用例设计范式

传统的测试用例是线性的：步骤1，步骤2，步骤3... 断言。AI驱动测试的用例更像是一个个“场景描述”或“用户故事”。你需要从用户的角度，用自然语言定义测试目标。

不好的例子（传统思维） ：

1. 访问 /login
2. 定位 id=username 的输入框，输入 “user1”
3. 定位 id=password 的输入框，输入 “pass123”
4. 定位 class=submit 的按钮，点击
5. 断言页面标题包含 “Dashboard”

好的例子（AI驱动思维） ：

用例：用户登录成功
描述：使用有效凭据（用户名：user1， 密码：pass123）登录系统，验证登录后跳转到仪表盘页面。
预期：登录成功后，页面应显示“欢迎，user1”字样，并且主导航栏出现“仪表盘”链接。

甚至更抽象一点：

用例：完成一次商品购买
描述：作为一个访客，搜索“无线耳机”，从结果中选择第一个商品，加入购物车，以游客身份结算，使用测试支付方式完成支付。
预期：订单生成成功，显示订单号，并向测试邮箱发送确认邮件（可选验证点）。

你会发现，后者完全没有提及任何具体的元素定位器。如何找到搜索框、商品链接、加入购物车按钮，全部交给AI去理解和决策。这极大地提升了用例的 可维护性 和 可读性 。

4.2 通过OpenClaw执行测试

执行测试可以通过几种方式：

  1. 命令行直接执行 ： openclaw --config config.yaml --task “你的测试描述”
  2. 配置文件批量执行 ：创建一个任务列表文件（如 tasks.json ），里面包含多个测试描述，然后让OpenClaw依次执行。
  3. 集成到测试框架 ：将OpenClaw作为一个“库”集成到你的Python/Java测试框架（如pytest、JUnit）中。这样你可以利用框架的夹具（fixture）、断言和报告机制。

例如，一个简单的pytest集成可能长这样：

# conftest.py 或测试文件中
import pytest
from openclaw_client import OpenClawClient

@pytest.fixture(scope="session")
def openclaw_client():
    client = OpenClawClient(base_url="http://localhost:8080")
    yield client
    client.close()

def test_user_login(openclaw_client):
    task_result = openclaw_client.execute_task_sync(
        instruction="登录系统，用户名：test_user， 密码：Test@123。验证登录成功后顶部显示用户名。"
    )
    # 从task_result中提取信息进行断言，例如检查最终截图是否包含“test_user”文字（可通过OCR）
    assert task_result.success == True
    assert "test_user" in task_result.final_screenshot_ocr_text

4.3 断言与结果验证

这是AI驱动测试的一个挑战。传统测试中，我们在脚本里写死 assert title == “xxx” 。在AI测试中，我们无法预知AI具体会点哪里，所以断言也需要更“智能”或更“结果导向”。

常见的验证策略包括：

  • 最终状态验证 ：任务完成后，对最终页面进行OCR，检查关键文本是否出现。
  • 关键节点截图比对 ：在关键步骤（如登录后、下单后），将AI操作后的页面截图与基准截图（Golden Image）进行像素或特征比对。
  • API状态验证 ：结合后端API，在UI操作后，调用API验证数据是否正确变更（如订单是否创建）。
  • 模型自我评估 ：在给AI的Prompt中，要求它在完成任务后，用一句话描述当前页面状态或是否成功。然后解析这个描述来判断。

OpenClaw可能会提供一些内置的验证能力，或者需要我们自己扩展。一个健壮的测试用例，应该结合多种验证方式。

注意事项 ：AI测试的“不确定性”高于脚本测试。同样的指令，AI两次执行可能因为页面加载微小的延迟或渲染差异而选择略有不同的操作路径。因此，断言要侧重于 业务结果的正确性 ，而非 操作路径的一致性 。同时，需要设置合理的超时和重试机制，以应对AI“卡住”或“迷路”的情况。

5. 性能调优与稳定性提升实战

把demo跑起来只是第一步，要让这个方案能在实际项目中可用，尤其是在持续集成（CI）环境中稳定运行，性能调优和稳定性加固是绕不开的坎。我踩过不少坑，这里把最实用的经验总结给你。

5.1 模型推理速度优化

Qwen3.5-9B在本地推理，一次响应时间在几秒到十几秒不等，这对于需要执行多个步骤的UI测试来说，总耗时可能很长。优化方向如下：

  1. 模型量化 ：这是最有效的手段。除了Ollama默认的Q4_K_M，可以尝试更激进的量化，如Q3_K_M或Q2_K，能进一步减少显存和提升速度，但可能会轻微损失精度。可以通过 ollama pull qwen2.5:9b-q3_K_M 来拉取不同量化等级的模型。
  2. Prompt优化 ：给模型的指令要清晰、简洁、无歧义。避免冗长的背景描述。可以尝试在系统提示词（System Prompt）中固定一些规则，比如“优先使用最明显的按钮”、“如果操作后页面无变化，等待2秒再重试”。
  3. 上下文长度限制 ：UI测试的每一步，OpenClaw都会把截图（可能编码为base64）和DOM信息发给模型，这会导致上下文（Context）非常长，严重影响推理速度和成本。解决方案：
    • 信息压缩 ：让OpenClaw只发送关键区域的截图，或者对截图进行压缩和降分辨率。
    • 摘要DOM ：不要发送完整的DOM树，只发送带有交互属性的元素（如按钮、输入框、链接）及其关键属性（id, class, text, role）。
    • 利用模型视觉能力 ：探索使用Qwen-VL等多模态模型，可能对压缩后的截图有更好的理解能力，从而减少对DOM的依赖。但Qwen-VL-4B这类小规模视觉模型能否驱动复杂的OpenClaw任务，需要实测验证。
  4. 硬件升级 ：如果条件允许，使用更强大的GPU（如RTX 4090, A100）能直接提升推理速度。利用GPU的Tensor Core和高速显存是关键。

5.2 测试执行稳定性保障

AI模型会有“幻觉”，可能做出错误操作。提升稳定性需要从流程和策略上设计。

  1. 操作原子化与确认机制 ：不要让AI一次性规划太长的步骤。可以设计成“单步确认”模式：AI每提出一个操作（如“点击登录按钮”），OpenClaw执行前，先进行一次轻量级的验证（比如，目标元素是否存在且可点击），执行后，再等待一个稳定状态（如网络请求完成、页面跳转）后再进行下一步决策。这虽然增加了交互次数，但大大降低了连续出错的风险。
  2. 失败重试与回退策略 ：
    • 元素定位失败 ：如果AI基于截图或DOM推荐的操作无法执行（元素未找到），应触发重试机制。重试时，可以刷新页面，或者让AI换一种描述方式定位元素（如用文字内容代替CSS选择器）。
    • 操作无效 ：点击后无反应。可以设置超时，超时后让AI尝试替代方案（如检查是否有弹窗遮挡，或尝试点击相邻的类似元素）。
    • 定义安全边界 ：对于危险操作（如删除、支付），可以在配置中设置“禁区”，禁止AI执行，或需要额外的人工确认。
  3. 环境一致性 ：UI测试对环境敏感。确保测试用的浏览器版本、屏幕分辨率、测试数据（如测试账号）与AI训练/调试时保持一致。使用Docker容器来固化测试环境是一个好办法。
  4. 日志与可观测性 ：必须记录完整的交互日志，包括：每一步AI接收到的上下文（截图摘要）、AI输出的指令、执行结果、页面状态变化。当测试失败时，这些日志是排查问题的唯一依据。最好能录制屏幕操作视频。

5.3 集成到CI/CD流水线

要将这套方案用于持续集成，需要考虑以下几点：

  1. 资源管理 ：CI机器通常没有强大的GPU。有几种方案：
    • 使用CPU推理 ：Ollama支持CPU模式，但速度极慢，只适合非常简单的任务。
    • 使用云端GPU服务 ：在CI中通过API调用部署在云端GPU服务器上的模型服务。这需要解决网络和安全问题。
    • 使用更小的模型 ：寻找或微调更小、更快的专用模型，牺牲一些通用性来换取速度。
    • 分层测试策略 ：核心路径的快速回归仍用传统脚本，AI测试用于探索性测试或每周一次的深度回归，不放入每次提交都触发的流水线。
  2. 测试数据管理 ：AI测试可能需要真实的测试账号和商品数据。需要有一套稳定的测试数据构造和清理机制。
  3. 报告生成 ：将OpenClaw的执行结果（成功/失败、步骤日志、最终截图）转化为CI平台（如Jenkins, GitLab CI）能识别的测试报告格式（如JUnit XML, Allure报告）。

一个可行的CI集成脚本骨架：

#!/bin/bash
# CI脚本示例

# 1. 启动Ollama服务并加载模型
ollama serve &
OLLAMA_PID=$!
sleep 10 # 等待服务启动
ollama run qwen2.5:9b &

# 2. 启动OpenClaw服务
cd /path/to/openclaw
openclaw --config ci_config.yaml --port 8080 &
OPENCLAW_PID=$!
sleep 5

# 3. 执行测试套件
python run_ai_tests.py --suite smoke_test

# 4. 生成报告
python generate_report.py --output junit.xml

# 5. 清理
kill $OPENCLAW_PID
kill $OLLAMA_PID

6. 常见问题排查与解决方案实录

在实际部署和运行过程中，你肯定会遇到各种各样的问题。我把最常见的一些坑和解决办法整理成了下表，希望能帮你快速定位。

问题现象 可能原因 排查步骤与解决方案
Ollama服务启动失败或模型加载慢 1. 端口冲突（11434被占）
2. 磁盘空间不足
3. 模型文件损坏
4. 网络问题导致下载失败		 1. netstat -tlnp | grep 11434 检查端口，修改Ollama配置或停止冲突程序。
2. df -h 检查磁盘，清理空间。
3. 删除 ~/.ollama/models 下的对应模型文件，重新拉取。
4. 检查网络连接，尝试更换镜像源（如设置环境变量 OLLAMA_HOST 或使用代理）。
OpenClaw无法连接到Ollama 1. 配置文件中 base_url 错误
2. Ollama服务未运行
3. 防火墙阻止连接		 1. 确认 config.yaml 中 base_url 为 http://localhost:11434 （或正确的IP）。
2. 运行 ollama list 确认服务正常，或用 curl http://localhost:11434/api/tags 测试。
3. 检查本地防火墙设置，确保端口可访问。
AI模型返回的操作指令无法执行 1. 模型输出格式不符合OpenClaw预期
2. Prompt设计不佳，导致模型理解偏差
3. 页面元素状态未及时更新（如未加载完）		 1. 查看OpenClaw日志，检查模型返回的原始JSON。可能需要调整OpenClaw的解析逻辑或模型的输出格式（通过System Prompt约束）。
2. 优化任务描述，使其更精确。例如，将“点击按钮”改为“点击蓝色的、文字是‘提交’的按钮”。
3. 在OpenClaw配置中增加操作后的等待时间（ post_action_delay ），或实现“等待元素稳定”的逻辑。
测试执行速度极慢 1. 模型推理速度慢
2. 网络延迟高（如果使用远程模型）
3. 每一步都等待固定超时，即使页面已就绪		 1. 采用前文所述的模型量化、Prompt优化、上下文压缩等方法。
2. 考虑将模型部署在离执行机更近的地方，或使用本地模型。
3. 将固定等待改为智能等待（等待特定元素出现或网络空闲），减少无效等待时间。
测试结果不稳定（时而过时而不过） 1. 页面加载时间波动
2. 动态内容（如广告、推荐位）干扰AI判断
3. 模型本身的随机性（temperature参数影响）		 1. 增加稳定性等待和重试机制，而非依赖固定延时。
2. 在测试环境中屏蔽或固定动态内容。或在Prompt中明确告知AI忽略某些区域。
3. 将模型的 temperature 参数调低（如0.1），使其输出更确定。为测试用例设置随机种子（如果支持）。
无法处理验证码或复杂图形交互 AI模型（尤其是纯语言模型）无法“理解”验证码或进行拖拽等复杂操作 1. 这是当前技术的局限。在测试环境中，应直接禁用验证码，或使用万能验证码。
2. 对于复杂交互，可以将其封装为一个“技能”（Skill），让OpenClaw调用预设的脚本处理，而非依赖AI生成。OpenClaw的Skill机制正是用于扩展此类能力。
内存/显存溢出（OOM） 1. 同时运行多个测试实例，资源耗尽
2. 模型过大或上下文累积过长		 1. 限制并发测试任务数。
2. 使用量化模型。定期清理推理过程中的缓存（如果框架支持）。监控资源使用情况，在CI脚本中加入资源检查。

独家避坑技巧 ：

  • 从小处着手 ：不要一开始就尝试用AI跑完整个电商下单流程。从一个简单的“登录”或“搜索”任务开始，验证整个链路，再逐步增加复杂度。
  • 黄金路径优先 ：先用AI测试最核心、最稳定的“黄金路径”（Happy Path）。边缘case和异常流程暂时用传统脚本覆盖，更可控。
  • 人机回环（Human-in-the-loop） ：在初期，特别是调试阶段，采用“人机回环”模式。让AI每一步操作前都暂停，等待人工确认后再执行。这虽然慢，但能帮你精准定位是AI决策问题还是执行环境问题。
  • 建立元素库（可选） ：对于关键且稳定的元素（如主导航、登录框），可以提前为其定义一些语义化的名称或ID，并在Prompt中告诉AI：“你可以通过 data-testid=‘main-nav’ 来定位主导航”。这相当于给AI一张“地图”，能提高定位准确率和速度。这需要前端开发同学的配合，在代码中添加测试属性。
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

2026年AI写作辅助平台推荐：9款高效AI工具终极指南

avatar 亚马逊云科技技术品牌专区
cover

WSaiOS认知内核：一种模块化可解释人工智能操作系统核心的设计与实现

avatar 亚马逊云科技技术品牌专区
cover

TVA对具身智能领域“莫拉维克悖论“的挑战（19）

avatar 亚马逊云科技技术品牌专区