AI大模型赋能自动化测试：auto-wing工具实战解析与避坑指南

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

最近在测试圈子里，一个叫auto-wing的开源工具讨论度挺高。作为一个在自动化测试领域摸爬滚打了十来年的老测试，我见过太多号称“革命性”的工具，但 auto-wing 的思路确实让我眼前一亮。它本质上是一个利用大语言模型（LLM）来辅助自动化测试的 Python 库，口号是“为你的自动化测试插上AI的翅膀”。

简单来说，它解决了一个自动化测试里最头疼的老问题：UI元素定位的脆弱性。传统基于 XPath、CSS Selector 的自动化脚本，一旦页面结构微调，比如按钮的 class 名变了、div 层级调整了，脚本就立刻“瘫痪”，维护成本极高。而 auto-wing 的思路是，让 AI 去“看”界面截图，然后根据你的自然语言指令去操作和查询，比如“点击那个蓝色的登录按钮”、“在顶部搜索框输入‘手机’并回车”。这听起来是不是有点像给测试脚本装了个“眼睛”和“大脑”？它无缝集成了 Playwright、Selenium 和 Appium 这三大主流自动化框架，意味着你现有的 Web 和 App 自动化项目，可以几乎无痛地引入 AI 能力。

我花了几天时间深度把玩了这个工具，从环境搭建到写测试用例，再到剖析其内部机制和避坑。这篇文章，我就以一个一线测试开发的角度，带你彻底拆解 auto-wing，看看它到底是不是真的那么“绝”，以及在实际项目中，我们该怎么用它，又该避开哪些坑。

2. auto-wing 核心设计思路与工作原理拆解

在动手之前，我们得先搞清楚 auto-wing 到底是怎么工作的。知其然，更要知其所以然，这样才能在出问题时快速定位，也能更好地发挥它的威力。

2.1 传统自动化 vs. AI 驱动的自动化：范式转移

传统的 UI 自动化测试，我们称之为“基于坐标或属性定位的指令式编程”。测试工程师需要像侦探一样，在浏览器的开发者工具里仔细审查 DOM 结构，找到那个唯一且稳定的属性（比如>ai.ai_action(‘在商品列表中找到第一个价格低于100元的商品，并点击它的“加入购物车”按钮’)

工具内部会做以下几件事：

1. 截图：对当前页面或应用屏幕进行截图。
2. 元素检测：通过某种方式（可能是内置的CV模型或结合DOM信息）识别出截图中的可交互元素及其位置。
3. 意图理解：将你的自然语言指令和截图信息（可能包括元素坐标、视觉特征）一起发送给配置好的 LLM（如 DeepSeek、GPT-4）。
4. 规划与执行：LLM 分析指令，规划出操作步骤（如：先找到哪个区域，再点击哪个坐标），然后将这个规划转换回底层自动化框架（如 Playwright）的可执行命令。
5. 结果反馈：执行操作，并可能返回结果。

这种模式的优点是抗UI变化能力强。只要按钮的文本“加入购物车”没变，或者它的视觉位置和特征大致不变，AI 就能找到它。这更贴近真实用户的操作方式。

2.2 架构解析：它是如何连接 AI 与自动化框架的？

根据官方文档和源码分析，auto-wing 的架构可以理解为三层：

第一层：驱动适配层这是工具的基础，它封装了 Playwright、Selenium 和 Appium 的 Python 客户端。它提供了统一的接口来驱动浏览器或手机，并获取当前页面的上下文信息（如截图、有限的DOM信息）。这一层保证了工具能兼容你现有的技术栈。

第二层：AI 引擎与缓存层这是工具的核心。它负责：

• 多模型对接：封装了 OpenAI、DeepSeek、千问、豆包、Gemini 等主流大模型的 API 调用。你只需要一个 API Key，就可以切换使用。
• 提示词工程：工具内部会构造一个精心设计的系统提示词（System Prompt），将截图、可能的元素信息、你的操作指令整合成一个有效的请求发送给 LLM。这个提示词的质量直接决定了 AI 理解的准确性。
• 智能缓存：这是提升性能和降低成本的关键设计。相同的页面状态和相同的指令，其结果可能会被缓存。这意味着第二次运行同一测试时，可能无需再次调用昂贵的 LLM API，极大加快了执行速度，也节省了 token 费用。

第三层：用户接口层提供了三个核心方法供测试脚本调用：

• ai_action(instruction): 让 AI 执行一个操作指令。
• ai_query(instruction): 让 AI 根据指令查询页面信息并返回。
• ai_assert(instruction): 让 AI 对页面状态进行断言。

这套架构清晰地将 AI 能力“注入”到了传统的自动化流程中，让你可以用写自然语言注释的方式，来编写稳定的测试逻辑。

3. 从零开始：环境搭建与第一个 AI 自动化测试

理论讲得再多，不如亲手跑一遍。我们以最常用的 Playwright 为例，带你快速上手。

3.1 环境准备与依赖安装

首先确保你的 Python 版本 >= 3.10。然后，我们使用 pip 安装 auto-wing 及其可选依赖。

# 1. 安装 auto-wing 核心包 pip install autowing # 2. 安装你需要的自动化框架支持。这里我们选 Playwright pip install pytest-playwright # 安装 Playwright 浏览器内核（非常重要！） playwright install # 如果你想用 Selenium，则安装： # pip install selenium # 并下载对应的 WebDriver（如 chromedriver） # 如果你想测试 App（Android/iOS），则安装： # pip install appium-python-client # 并配置好 Appium 服务端和手机模拟器/真机

3.2 获取并配置 LLM API Key

auto-wing 的强大依赖于背后的 LLM。你需要选择一个模型服务并获取 API Key。我强烈推荐从DeepSeek开始，原因有三：免费额度大（新用户有额度）、价格极其便宜（几乎可忽略）、对中文支持好、API 稳定。

1. 访问 DeepSeek 开放平台 。
2. 注册账号，在控制台找到“API Keys”，创建一个新的 Key。
3. 在你的项目根目录下，创建一个名为.env的文件。这是最方便的配置方式。

.env文件内容如下：

# 指定使用 deepseek 模型 AUTOWING_MODEL_PROVIDER=deepseek # 替换为你自己的 DeepSeek API Key DEEPSEEK_API_KEY=sk-your-actual-deepseek-api-key-here

注意：.env文件包含敏感信息，务必将其添加到.gitignore中，避免将 API Key 提交到代码仓库。

其他模型的配置类似，参考官方文档替换AUTOWING_MODEL_PROVIDER和对应的 Key 环境变量名即可。

3.3 编写第一个 AI 自动化测试用例

我们来写一个简单的测试：用 AI 操作浏览器打开 Bing，搜索一个关键词，并验证结果。

创建一个文件test_ai_bing.py：

import pytest from playwright.sync_api import Page from autowing.playwright.fixture import create_fixture from dotenv import load_dotenv # 加载 .env 文件中的环境变量配置 load_dotenv() @pytest.fixture def ai(page): """创建一个 ai fixture，它依赖于 playwright 的 page fixture""" ai_fixture = create_fixture() return ai_fixture(page) def test_bing_search_with_ai(page: Page, ai): """ 测试用例：使用 AI 在 Bing 进行搜索 """ # 1. 导航到 Bing 首页 page.goto("https://cn.bing.com") # 给页面一点加载时间，虽然不是必须，但更稳定 page.wait_for_timeout(2000) # 2. AI 执行操作：找到搜索框并输入关键词 # 注意：这里的描述要尽可能像人话，指出关键视觉特征 ai.ai_action('在页面中间找到一个主要的搜索输入框，输入"人工智能发展现状"，然后按回车键搜索') # 3. 等待搜索结果加载 page.wait_for_timeout(3000) # 4. AI 执行查询：获取搜索结果的标题列表 # 指令格式：`返回类型, 描述`。这里要求返回字符串列表。 result_titles = ai.ai_query('string[], 列出当前搜索结果页面中所有包含“人工智能”字样的标题文本') print(f"AI 查询到的相关标题: {result_titles}") # 验证至少有一条相关结果 assert len(result_titles) > 0, "未找到包含‘人工智能’的搜索结果" # 5. AI 执行断言：检查第一条结果是否相关 # ai_assert 会返回 True 或 False is_first_result_relevant = ai.ai_assert('检查搜索结果列表的第一条标题，是否与“人工智能”技术强相关') assert is_first_result_relevant, "第一条结果似乎不相关" # 也可以直接用 assert ai.ai_assert(...) # assert ai.ai_assert('检查搜索结果列表的第一条标题，是否与“人工智能”技术强相关')

3.4 运行测试并解读输出

在终端运行测试：

pytest test_ai_bing.py -v -s

-v显示详细信息，-s允许打印输出（如我们的print语句）。

你会看到类似如下的日志，这非常有助于理解其工作流程：

test_ai_bing.py::test_bing_search_with_ai 2025-XX-XX 10:00:30.961 | INFO | autowing.playwright.fixture:ai_action:88 - 🪽 AI Action: 在页面中间找到一个主要的搜索输入框，输入"人工智能发展现状"，然后按回车键搜索 2025-XX-XX 10:00:40.070 | INFO | autowing.playwright.fixture:ai_query:162 - 🪽 AI Query: string[], 列出当前搜索结果页面中所有包含“人工智能”字样的标题文本 2025-XX-XX 10:00:48.954 | DEBUG | autowing.playwright.fixture:ai_query:218 - 📄 Query: ['人工智能发展现状及趋势分析报告 - 知乎', '2024年人工智能行业发展现状与前景展望 - 百度文库', ...] 2025-XX-XX 10:00:48.954 | INFO | autowing.playwright.fixture:ai_assert:267 - 🪽 AI Assert: 检查搜索结果列表的第一条标题，是否与“人工智能”技术强相关 PASSED

从日志可以看出：

1. ai_action阶段，AI 理解了指令，操控鼠标/键盘完成了输入和回车。
2. ai_query阶段，AI “看到”了搜索结果页，并按要求过滤出了包含特定文字的标题，以列表形式返回。
3. ai_assert阶段，AI 对页面状态做出了一个布尔判断。

至此，你的第一个 AI 驱动的自动化测试就成功运行了！整个过程，你没有写一行定位元素的代码（如page.locator(‘#sb_form_q’)），全部通过自然语言完成。

4. 核心功能深度解析与最佳实践

掌握了基础用法后，我们来深入看看它的三个核心方法和如何写出更健壮的 AI 测试指令。

4.1 三大核心方法：action, query, assert 详解

ai_action(instruction: str)

• 用途：让 AI 执行一个操作。这是最常用的方法。
• 输入：一个描述操作步骤的自然语言字符串。
• 输出：无返回值（或返回操作结果状态）。它直接驱动浏览器/App 执行。
• 内部流程：截图 -> LLM 分析指令并生成操作序列（如：点击坐标[x,y]）-> 通过 Playwright 执行。
• 最佳实践：
  • 指令要具体、唯一：避免“点击那个按钮”，而要说“点击页面顶部导航栏右侧的、文字为‘登录’的蓝色按钮”。
  • 包含上下文：如果页面有多个相似区域，指明位置，如“在侧边栏的用户信息卡片中，找到‘编辑资料’链接并点击”。
  • 一个指令，一个动作：尽量保持指令原子化。虽然 AI 能处理多步，但拆分开更稳定，也便于调试。例如，将“登录并发布帖子”拆成“输入用户名密码点击登录”和“在发布框输入内容点击发布”两个ai_action。

ai_query(instruction: str)

• 用途：向页面提问，并获取结构化的答案。
• 输入：一个指定了返回类型和查询意图的字符串。格式至关重要：<返回类型>, <查询描述>。
• 输出：根据指定的返回类型，可能是str,list,dict,bool,int,float等。
• 示例：

  # 获取单个字符串 price = ai.ai_query(‘string, 当前商品详情页显示的价格是多少（只返回数字和单位，如”¥1999”）’) # 获取字符串列表 menu_items = ai.ai_query(‘string[], 获取主导航菜单的所有一级菜单名称’) # 获取布尔值 is_logged_in = ai.ai_query(‘bool, 当前页面右上角是否显示了用户的头像或用户名？’) # 获取字典（需要更清晰的描述） # 这个对LLM要求较高，可能不稳定 # user_info = ai.ai_query(‘dict, 获取个人资料卡片中的信息，键为：姓名，等级，积分’)

• 最佳实践：
  • 明确返回类型：在指令开头就声明，这是与 LLM 的“契约”。
  • 描述要可观测：查询的信息必须在屏幕截图中清晰可见。无法查询 DOM 属性或网络状态。

ai_assert(instruction: str)

• 用途：让 AI 对当前页面状态做一个断言判断。
• 输入：一个描述断言条件的自然语言字符串。
• 输出：布尔值True或False。通常直接用在assert语句中。
• 示例：

  # 断言页面包含某个元素 assert ai.ai_assert(‘页面中央有一个显示“支付成功”的绿色对勾图标和文字’) # 断言元素状态 assert ai.ai_assert(‘“提交订单”按钮当前处于可点击状态（不是灰色）’) # 断言文本内容 assert ai.ai_assert(‘欢迎提示语中包含当前登录的用户名“张三”’)

• 最佳实践：
  • 断言要基于视觉：和query一样，条件必须是屏幕上能看到的。
  • 用于复杂断言：对于简单的文本存在性断言page.locator(‘text=支付成功’).is_visible()，传统方式可能更直接可靠。ai_assert更适合用于复杂的、综合性的视觉判断。

4.2 编写高效 AI 指令的黄金法则

auto-wing 的效果，八成取决于你写的指令（Prompt）。以下是结合官方建议和我实战总结的法则：

法则一：扮演“瞎子摸象”的指导者假设 AI 是一个只能看到当前屏幕截图、对 HTML 和 JS 一无所知的“瞎子”。你的指令必须基于视觉特征和空间位置。

• 好：“点击那个位于页面顶部、背景是蓝色、写着‘立即注册’的按钮。”
• 差：“点击id为register-btn的按钮。” （AI 看不到id）
• 差：“等 Ajax 加载完成后点击。” （AI 不知道加载状态）

法则二：提供充足的上下文与区分度当页面有多个相似元素时，必须提供足够的上下文来区分。

• 好：“在商品列表区域（通常有多个商品卡片排列），找到第三个商品卡片，点击卡片内的‘查看详情’链接。”
• 差：“点击‘查看详情’。” （可能有多个）

法则三：指令原子化，一步一指令将复杂操作拆解为连续的、简单的ai_action调用。这提高了可读性、可维护性和稳定性。

# 推荐：原子化操作 ai.ai_action(‘在登录弹窗中，找到用户名输入框并点击’) page.keyboard.type(‘testuser’) ai.ai_action(‘找到密码输入框并点击’) page.keyboard.type(‘password123’) ai.ai_action(‘点击“登录”按钮’) # 不推荐：一个指令包含多步复杂操作（虽然可能成功，但失败时难调试） # ai.ai_action(‘在登录弹窗中输入用户名testuser和密码password123，然后点击登录按钮’)

法则四：利用ai_query进行状态判断和决策你可以用ai_query获取页面信息，来驱动后续的逻辑。

# 判断页面状态，决定下一步操作 page_state = ai.ai_query(‘string, 当前页面是登录页、主页还是错误页？’) if “登录” in page_state: ai.ai_action(‘执行登录操作，用户test，密码123’) elif “主页” in page_state: ai.ai_query(‘string, 主页欢迎语是什么？’)

4.3 集成到现有测试框架：Pytest 最佳实践

auto-wing 设计之初就考虑了与 Pytest 和 Unittest 的集成。上面的例子已经展示了 Pytest fixture 的用法。这里再分享几个进阶技巧：

1. 创建全局的、可配置的 ai fixture在conftest.py文件中定义，方便所有测试用例使用。

# conftest.py import pytest from autowing.playwright.fixture import create_fixture from dotenv import load_dotenv load_dotenv() # 确保在 fixture 创建前加载环境变量 @pytest.fixture(scope=“session”) # 作用域设为session，避免重复创建 def ai_fixture(): “”“创建 AI fixture 工厂函数”“” return create_fixture() @pytest.fixture def ai(page, ai_fixture): “”“为每个测试用例提供 ai 操作对象”“” return ai_fixture(page)

2. 结合传统定位器，发挥混合优势AI 不是万能的，传统定位器在稳定场景下更快、更精确。二者可以结合。

def test_mixed_approach(page: Page, ai): # 使用传统方式导航到稳定页面 page.goto(“https://example.com/login”) # 使用传统方式填充固定的表单字段（更可靠） page.locator(‘#username’).fill(‘standard_user’) page.locator(‘#password’).fill(‘secret_sauce’) # 使用 AI 点击登录按钮（避免因CSS类名变化而失败） ai.ai_action(‘点击那个用于提交表单的、颜色突出的按钮’) # 使用 AI 断言登录后的复杂页面状态 assert ai.ai_assert(‘页面主导航栏显示了用户菜单，并且页面主体显示了商品列表’)

3. 处理动态加载与等待AI 操作本身包含截图和推理时间，这无形中成为一种“等待”。但对于显式需要等待元素的情况，仍需结合 Playwright 的等待机制。

ai.ai_action(‘点击“加载更多”按钮’) # AI操作后，显式等待新内容出现（传统方式） page.wait_for_selector(‘.new-item’, state=‘visible’, timeout=10000) # 然后再用 AI 查询新内容 new_items = ai.ai_query(‘string[], 获取新加载出来的商品名称’)

5. 实战进阶：复杂场景应用与性能调优

掌握了基本操作，我们来看看如何应对更复杂的真实测试场景，以及如何控制成本与提升稳定性。

5.1 测试数据驱动与参数化

我们可以用 Pytest 的@pytest.mark.parametrize来实现数据驱动的 AI 测试。

import pytest search_keywords = [“Playwright”, “Selenium”, “Cypress”, “自动化测试”] @pytest.mark.parametrize(“keyword”, search_keywords) def test_ai_search_different_keywords(page: Page, ai, keyword): page.goto(“https://cn.bing.com”) # 使用 f-string 将变量注入 AI 指令 ai.ai_action(f’在搜索框输入”{keyword}”并回车’) page.wait_for_timeout(2000) # 验证结果包含关键词 titles = ai.ai_query(f‘string[], 查找包含”{keyword}”的搜索结果标题’) assert len(titles) > 0, f”搜索 ‘{keyword}’ 未返回相关结果” # 也可以让 AI 判断相关性 assert ai.ai_assert(f’搜索结果的第一页内容与”{keyword}”主题相关’), f”‘{keyword}’ 搜索结果不相关”

5.2 处理弹窗、iframe 与多标签页

弹窗处理：AI 通常能“看到”弹窗并与之交互。指令需要更精确。

# 假设点击某个按钮后出现一个模态框 ai.ai_action(‘点击“删除”按钮’) # 操作弹窗中的元素，需要指明上下文 ai.ai_action(‘在刚刚弹出的确认对话框（通常有半透明背景遮罩）上，点击红色的“确认删除”按钮’)

iframe 处理：auto-wing 的 AI 操作基于当前page或frame的上下文。如果元素在 iframe 里，需要先切换到对应的 frame。

# 传统方式切换到 iframe frame = page.frame_locator(‘iframe[name=”content”]’).content_frame # 为这个 frame 创建 AI 操作对象 (需要查看 auto-wing 是否支持 frame 对象，通常 page 是主要接口) # 一种可行思路：如果 auto-wing 的 fixture 接受 page/frame，则可以： ai_in_frame = ai_fixture(frame) ai_in_frame.ai_action(‘在框架内的表单中填写信息’) # 更通用的方式是，在切换 frame 后，对主 page 的 AI 对象进行操作，AI 会基于当前活动页面截图。

多标签页：AI 操作聚焦于当前激活的页面。切换标签页后，AI 的上下文也随之切换。

# 点击一个打开新标签页的链接 with page.context.expect_page() as new_page_info: ai.ai_action(‘点击“在新窗口打开帮助文档”的链接’) new_page = new_page_info.value new_page.wait_for_load_state() # 切换到新页面，并为其创建或使用 AI 对象 ai_new = ai_fixture(new_page) ai_new.ai_action(‘在新页面的搜索框输入问题’)

5.3 性能优化与成本控制：深入理解缓存机制

LLM API 调用是收费的（DeepSeek 等有免费额度但也有限制），且速度比本地代码慢。auto-wing 的智能缓存是解决这个问题的关键。

缓存是如何工作的？根据文档和代码分析，其缓存逻辑大致是：以“当前页面截图（或特征） + 操作指令”作为缓存的键（Key）。如果相同的页面状态和相同的指令再次出现，则直接返回缓存的结果（可能是操作序列或查询结果），而不再调用 LLM。

如何最大化利用缓存？

1. 保持指令一致性：对于相同的操作，使用完全相同的指令字符串。避免在指令中嵌入随机或变化的部分（如时间戳）。
2. 稳定页面状态：在触发缓存点之前，确保页面处于一个稳定、可重复的状态。避免在动态加载过程中进行操作。
3. 分步骤操作：原子化的指令更容易被缓存和复用。一个复杂的多步指令很难遇到完全相同的页面状态。

成本估算与监控

• 了解计费：清楚你所用模型的计费方式（如每千 tokens 的价格）。一个ai_action或ai_query的调用，可能会消耗几百到几千 tokens（包含系统提示词、截图描述、你的指令等）。
• 开始阶段：在开发调试阶段，缓存未命中率高，成本较高。建议在本地或测试环境充分调试指令。
• 稳定运行阶段：在 CI/CD 中回归测试时，由于页面稳定、指令固定，缓存命中率会很高，实际成本很低。
• 监控建议：可以在测试报告中加入简单的日志，记录每次测试运行中 LLM 的实际调用次数，以便评估成本。

5.4 稳定性提升：错误处理与重试策略

AI 并非 100% 可靠，可能会误解指令或操作失败。必须为测试用例增加鲁棒性。

1. 内置重试与超时auto-wing 本身可能包含一些重试逻辑，但我们应在测试脚本层面增加保障。

import time from tenacity import retry, stop_after_attempt, wait_fixed @retry(stop=stop_after_attempt(3), wait=wait_fixed(2)) def ai_action_with_retry(ai, instruction): “”“包装 ai_action，失败后重试”“” return ai.ai_action(instruction) def test_stable_operation(page: Page, ai): page.goto(“...“) try: ai_action_with_retry(ai, ‘点击那个有时加载慢的按钮’) except Exception as e: print(f“AI操作失败，尝试备用方案: {e}”) # 备用方案：使用传统定位器（如果已知） page.locator(‘button:has-text(“Submit”)’).click()

2. 验证操作结果不要假设 AI 操作一定成功。重要的操作后，应通过ai_query或ai_assert进行验证。

def test_payment_flow(page: Page, ai): ai.ai_action(‘点击“立即支付”按钮’) # 关键操作后，验证是否跳转到了预期页面 page.wait_for_timeout(3000) # 等待跳转或弹窗 assert ai.ai_assert(‘当前页面出现了支付成功的提示信息，或者跳转到了订单完成页’), “支付操作后未到达成功页面” # 或者结合URL验证 assert “order/success” in page.url

3. 截图与日志归档在 CI/CD 中，当 AI 测试失败时，传统的错误信息可能不够直观。务必在关键步骤和失败时截图。

def test_with_screenshot(page: Page, ai): try: ai.ai_action(‘进行一些操作’) assert ai.ai_assert(‘验证某个状态’) except AssertionError as e: # 失败时截图，文件名包含时间戳和测试名 timestamp = time.strftime(“%Y%m%d_%H%M%S”) page.screenshot(path=f”./screenshots/failure_{timestamp}.png”, full_page=True) print(f“测试失败，截图已保存。”) raise e # 重新抛出异常，让pytest捕获

6. 常见问题排查与实战心得

在实际使用 auto-wing 的过程中，你肯定会遇到各种问题。下面是我总结的一些典型问题及其解决方案，以及一些宝贵的“踩坑”经验。

6.1 问题排查速查表

6.2 实战心得与避坑指南

心得一：AI 自动化是“增强”，而非“替代”不要试图用 auto-wing 重写所有现有测试。它的最佳定位是：

• 补充复杂、易变的 UI 验证：如验证一个动态仪表盘的图表渲染是否正确。
• 快速编写原型测试：在项目早期，UI 不稳定时，用 AI 快速写出可运行的冒烟测试。
• 处理“不可测”元素：对于那些没有稳定测试属性（>