基于AI Agent与LangChain实现自然语言测试用例自动化执行

1. 项目概述：当手工测试遇见AI智能体

作为一名在软件测试领域摸爬滚打了十多年的老兵，我经历过从纯手工“点点点”到自动化脚本，再到如今DevOps流水线中各种测试工具的洗礼。测试工程师的日常，总绕不开一个永恒的痛点：那些数量庞大、逻辑复杂、变更频繁的手工测试用例。它们像是测试资产库里的“不动产”，价值很高，但“流动性”极差——执行起来耗时费力，维护成本高昂，且严重依赖测试人员的经验和状态。最近，随着AI Agent（智能体）技术的爆火，尤其是看到各种“十大智能体排名”、“AI Agent开发框架”的讨论，一个想法在我脑子里越来越清晰：能不能让AI智能体来“读懂”并“执行”这些手工测试用例，实现真正的智能化测试执行？

这个想法并非空穴来风。我们团队维护着上千条手工测试用例，覆盖了核心业务流程、边缘场景和兼容性测试。每次回归，哪怕只执行其中一部分，也需要投入大量人力，而且难免会有疏漏或执行标准不一的问题。传统的自动化测试框架（如Selenium、Appium）虽然能解决一部分问题，但它们对测试用例有严苛的要求——需要写成结构化的脚本。而我们的手工用例，大多是自然语言描述的Word或Excel文档，比如“在登录页面，输入错误的密码，点击登录按钮，验证提示信息为‘密码错误’”。让AI来理解并执行这样的描述，听起来就像给测试工作装上了“大脑”和“双手”。

于是，我决定启动一个探索性项目：基于现有的AI Agent开发框架，构建一个能够理解自然语言手工测试用例，并驱动浏览器或应用程序进行自动化执行的智能体系统。这不仅仅是“用AI写自动化脚本”，而是让AI直接成为测试执行者，动态解析、决策并操作。接下来，我将详细拆解整个项目的设计思路、核心技术选型、实操步骤以及踩过的那些坑，希望能给同样被手工测试所困的同仁们一些切实可行的参考。

2. 核心思路与框架选型：为什么是AI Agent框架？

在决定动手之前，我花了大量时间研究市面上的技术方案。最直接的想法可能是：用大语言模型（LLM）的API，写个程序去解析测试用例，然后调用Selenium。但这很快会遇到问题：大模型输出不稳定，它告诉你“应该点击登录按钮”，但你怎么把这个指令转换成Selenium WebDriver能执行的find_element(By.ID, “loginBtn”).click()？你需要一个能持续理解上下文、进行多轮决策、并具备工具调用能力的“智能体”。

2.1 为什么传统自动化框架不够用？

传统的UI自动化框架（如Selenium、Cypress、Playwright）本质上是“脚本回放器”。它们需要精确的、预先编写好的指令序列和元素定位器。而手工测试用例是高度抽象和描述性的，存在大量模糊空间。例如，“在商品列表页找到最新上架的商品并加入购物车”。这个“找到”依赖于对页面布局的理解和实时判断，这是传统脚本难以应对的。我们需要一个能进行视觉理解、语义分析和实时规划的“智能”层，这正是AI Agent所擅长的。

2.2 AI Agent开发框架的核心价值

AI Agent开发框架（如LangChain、LlamaIndex、Dify、Coze等平台提供的智能体构建能力）提供了一套标准化的“骨架”，帮助我们快速组装一个具备以下能力的智能体：

1. 记忆与上下文管理：能够记住之前执行过的步骤、页面的状态以及测试用例的全局目标。
2. 工具调用（Tool Calling）：这是最关键的能力。智能体可以调用我们为其“装备”的工具，比如“打开浏览器”、“输入文本”、“点击元素”、“验证文本”。
3. 规划与决策：将复杂的测试用例目标拆解成一系列可执行的动作步骤。
4. 自我反思与纠错：当操作失败（如元素未找到）时，能够分析原因并尝试替代方案。

我的选型思路是：不重复造轮子，基于成熟框架进行领域适配。经过对比，我选择了LangChain作为核心Agent框架，并结合Playwright作为浏览器自动化工具。理由如下：

• LangChain：生态成熟，社区活跃，对工具调用、记忆管理和与多种大模型集成的支持非常好。它的“ReAct”（推理+行动）范式非常适合测试执行这种需要多步决策的场景。
• Playwright：相比Selenium，Playwright的API更现代，自动等待机制更健壮，对现代Web应用（单页应用）支持更好，且自带强大的元素定位和录制功能，能为AI提供更丰富的页面上下文信息。
• 大模型选择：考虑到成本、响应速度和API稳定性，我选择了OpenAI的GPT-4 Turbo作为核心的“大脑”。它在理解复杂指令和进行步骤拆解方面表现非常出色。对于内部或对成本敏感的场景，也可以考虑使用开源的Llama 3 70B或DeepSeek等模型通过Ollama本地部署。

注意：框架选型没有绝对的对错，关键看团队技术栈和需求。如果你团队更熟悉Python，LangChain是首选；如果追求低代码快速搭建，Dify、Coze这类平台也能通过工作流的方式组装智能体，但它们对深度定制和集成到现有CI/CD流程的支持可能不如代码级框架灵活。

3. 系统架构设计与核心组件拆解

整个系统的设计目标是：输入一段自然语言描述的手工测试用例，输出测试执行结果（成功/失败）及详细的执行日志。为了实现这个目标，我设计了如下分层架构：

3.1 架构总览

整个系统可以划分为四个核心层：

1. 用例理解与规划层：由大模型驱动的AI Agent核心。负责解析自然语言用例，生成初始执行计划。
2. 工具执行层：封装了一系列可被AI Agent调用的原子操作工具，如浏览器控制、元素操作、断言验证等。
3. 上下文感知层：实时获取并处理应用程序的当前状态（如页面URL、DOM结构、可视元素文本），将其转化为AI能理解的上下文信息。
4. 控制与协调层：协调整个执行流程，处理异常，管理执行状态，并生成最终报告。

[自然语言测试用例] | v [AI Agent (LLM + 规划器)] <---> [记忆存储器] | (调用工具) v [工具集(Toolkit)] | (驱动) v [浏览器(Playwright)] ---> [被测应用] | v [结果与日志收集] ---> [测试报告]

3.2 核心组件详解

3.2.1 AI Agent与规划器（Planner）

这是系统的大脑。我使用LangChain的AgentExecutor和create_react_agent来构建智能体。但关键的改进在于自定义规划器（Planner）。单纯的ReAct Agent在面对长流程测试时，容易迷失或做出不合理规划。因此，我设计了一个两阶段规划策略：

• 第一阶段：高层任务分解。让大模型先将整个测试用例分解为几个关键阶段。例如，对于“用户登录后搜索商品并下单”这个用例，分解为：1. 用户登录，2. 搜索目标商品，3. 进入商品详情页并加入购物车，4. 完成结算流程。
• 第二阶段：单步动作生成。在执行每个阶段时，Agent再根据当前页面上下文，规划出具体的下一个动作（如click(‘登录按钮’),type(‘搜索框’， ‘手机’)）。

这样做的优点是避免了Agent一开始就陷入细节，提高了规划的成功率和执行效率。规划器的提示词（Prompt）需要精心设计，明确告诉模型它的角色（一个QA测试工程师）、可用的工具以及输出的格式要求。

3.2.2 工具集（Toolkit）的设计

工具是AI Agent的“手和脚”。我基于Playwright封装了以下核心工具函数，并通过LangChain的@tool装饰器暴露给Agent：

1. navigate_to(url: str): 导航到指定URL。
2. click(description: str): 根据描述点击元素。描述可以是文本内容（如“登录按钮”）、CSS选择器或XPath。内部实现会尝试多种定位策略。
3. type_text(description: str, text: str): 在描述的元素中输入文本。
4. get_page_text(): 获取当前页面的主要文本内容，作为上下文提供给Agent。
5. extract_element_info(description: str): 获取特定元素的详细信息（如标签、属性、位置），用于辅助定位。
6. assert_text_present(text: str): 断言页面上存在某段文本。
7. take_screenshot(): 对当前页面截图，用于失败分析和报告。

工具设计的核心挑战在于元素定位。手工用例中的描述（如“点击提交按钮”）是模糊的。我的策略是“描述优先，选择器兜底”：

• 首先，工具函数会尝试通过page.get_by_text()或page.get_by_role()等Playwright的语义化定位器来查找元素。
• 如果失败，则利用大模型，将当前页面DOM摘要和元素描述结合起来，让模型推荐一个更精确的CSS选择器或XPath，然后进行重试。
• 在工具函数内部加入重试和等待逻辑，以应对页面加载或元素渲染延迟。

3.2.3 上下文构建与记忆管理

AI Agent需要知道“我在哪”、“我做了什么”。上下文信息主要包括：

• 页面文本摘要：通过get_page_text()获取，但全量DOM文本可能太长。我实现了一个摘要函数，使用轻量级NLP方法（如提取标题、按钮文本、输入框标签等关键信息）生成页面概要。
• 执行历史：LangChain的ConversationBufferMemory可以存储Agent与用户的对话历史（在这里是动作序列和结果）。我将其扩展为存储完整的测试步骤日志。
• 自定义状态：维护一个全局字典，记录当前登录用户、购物车商品数等业务状态，这些信息可以作为后续步骤的判断依据。

4. 实操搭建：从零构建你的测试AI智能体

理论讲完，我们来点实际的。下面是我搭建核心系统的关键步骤和代码片段。假设你已经有一个Python环境（3.8+），并安装了基本依赖。

4.1 环境准备与依赖安装

首先，创建项目并安装核心库：

# 创建项目目录 mkdir ai-test-agent && cd ai-test-agent python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate # 安装核心依赖 pip install langchain langchain-openai playwright # LangChain核心、OpenAI集成、浏览器自动化 pip install python-dotenv # 用于管理环境变量（如API Key） pip install pydantic # 数据验证 # 安装Playwright浏览器 playwright install chromium

4.2 构建核心工具类

我们首先封装一个基于Playwright的浏览器操作类，这是所有工具的基础。

# browser_controller.py import asyncio from playwright.async_api import async_playwright, Page from typing import Optional class BrowserController: def __init__(self): self.playwright = None self.browser = None self.page: Optional[Page] = None self.context = None async def start(self, headless: bool = False): """启动浏览器实例""" self.playwright = await async_playwright().start() self.browser = await self.playwright.chromium.launch(headless=headless) self.context = await self.browser.new_context(viewport={'width': 1920, 'height': 1080}) self.page = await self.context.new_page() print("浏览器启动成功") async def navigate(self, url: str): """导航到指定URL""" if not self.page: raise RuntimeError("浏览器未启动") await self.page.goto(url) # 等待页面基本加载完成 await self.page.wait_for_load_state("networkidle") print(f"已导航至: {url}") async def get_page_text_summary(self) -> str: """获取页面关键文本摘要（简化版）""" if not self.page: return "" # 获取所有可见文本 all_text = await self.page.evaluate("""() => { const elements = document.querySelectorAll('body *:not(script):not(style)'); let texts = []; elements.forEach(el => { if (el.offsetWidth > 0 && el.offsetHeight > 0) { const text = el.innerText?.trim(); if (text && text.length > 1) { texts.push(text); } } }); return Array.from(new Set(texts)).join(' | '); }""") # 简单截断，防止上下文过长 return all_text[:2000] if len(all_text) > 2000 else all_text async def close(self): """关闭浏览器""" if self.browser: await self.browser.close() if self.playwright: await self.playwright.stop() print("浏览器已关闭") # 注意：为了与LangChain的同步接口兼容，实际使用时可能需要同步包装或使用LangChain的异步支持。

4.3 实现LangChain工具

接下来，我们将浏览器操作封装成LangChain能识别的工具。这里以click和assert_text_present为例。

# test_agent_tools.py import os from langchain.tools import tool from langchain_core.messages import HumanMessage from browser_controller import BrowserController from typing import Type from pydantic import BaseModel, Field import asyncio # 声明一个全局的浏览器控制器实例（生产环境建议用更好的方式管理） _browser_controller = BrowserController() # 定义工具的输入Schema，这能帮助大模型更好地理解如何调用工具 class ClickInput(BaseModel): element_description: str = Field(description="对要点击的元素的描述，如‘登录按钮’、‘提交表单’") class AssertTextInput(BaseModel): expected_text: str = Field(description="期望在页面上出现的文本内容") @tool(args_schema=ClickInput) def click_tool(element_description: str) -> str: """ 根据描述点击页面上的一个元素。 描述可以是按钮文本、链接文字或其他可识别特征。 """ # 由于Playwright是异步的，我们需要在同步工具函数中运行异步代码 async def _async_click(): page = _browser_controller.page if not page: return "错误：页面未就绪" # 策略1：优先使用Playwright的文本定位器 try: await page.get_by_text(element_description, exact=False).first.click(timeout=5000) return f"成功点击描述为‘{element_description}’的元素" except Exception as e1: print(f"文本定位失败: {e1}") # 策略2：尝试通过角色定位（如button） try: await page.get_by_role("button", name=element_description).click(timeout=5000) return f"成功通过角色点击‘{element_description}’" except Exception as e2: # 策略3：获取页面上下文，让模型辅助定位（简化示例） page_text = await _browser_controller.get_page_text_summary() # 这里可以调用一个LLM来根据描述和页面文本生成选择器，为简化，直接返回失败 return f"无法根据描述‘{element_description}’找到可点击元素。当前页面关键词：{page_text[:500]}..." loop = asyncio.get_event_loop() return loop.run_until_complete(_async_click()) @tool(args_schema=AssertTextInput) def assert_text_present_tool(expected_text: str) -> str: """验证指定的文本是否出现在当前页面上。""" async def _async_assert(): page_text = await _browser_controller.get_page_text_summary() if expected_text in page_text: return f"验证成功：页面上存在文本‘{expected_text}’" else: return f"验证失败：未在页面上找到文本‘{expected_text}’。当前页面内容摘要：{page_text[:1000]}" loop = asyncio.get_event_loop() return loop.run_until_complete(_async_assert()) # 同样地，可以封装 navigate_to, type_text 等工具

4.4 组装AI Agent并定义执行流程

现在，我们将工具、模型和记忆组装起来，创建智能体。

# test_agent_executor.py import os from langchain import hub from langchain.agents import create_react_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain.memory import ConversationBufferMemory from test_agent_tools import click_tool, assert_text_present_tool # 导入所有工具 from browser_controller import BrowserController import asyncio from dotenv import load_dotenv load_dotenv() # 加载环境变量，OPENAI_API_KEY应放在.env文件中 class TestCaseAIAgent: def __init__(self): # 1. 初始化大模型 self.llm = ChatOpenAI( model="gpt-4-turbo-preview", temperature=0.1, # 低温度，保证输出稳定 api_key=os.getenv("OPENAI_API_KEY") ) # 2. 准备工具列表 self.tools = [click_tool, assert_text_present_tool] # 添加所有定义好的工具 # 3. 从LangChain Hub拉取一个优化的ReAct提示词，也可以自定义 self.prompt = hub.pull("hwchase17/react-chat") # 修改提示词，明确测试工程师的角色和任务 self.prompt.messages[0].prompt.template = """你是一个专业的QA测试工程师，负责执行手工测试用例。你的任务是根据给定的测试用例步骤，操作浏览器来完成测试。 你可以使用以下工具： {tools} 请严格按照测试用例的描述来执行操作。在行动前，先思考当前页面状态和下一步最适合的操作。 如果你认为测试步骤已经完成或遇到无法解决的问题，请用中文回复“测试执行结束”或说明原因。 之前的对话历史： {chat_history} 测试用例：{input} 开始执行： {agent_scratchpad}""" # 4. 创建记忆，保存对话历史（即执行步骤） self.memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True) # 5. 创建智能体 self.agent = create_react_agent(llm=self.llm, tools=self.tools, prompt=self.prompt) # 6. 创建执行器 self.agent_executor = AgentExecutor( agent=self.agent, tools=self.tools, memory=self.memory, verbose=True, # 打印详细执行过程，便于调试 handle_parsing_errors=True, # 处理解析错误 max_iterations=15 # 防止无限循环 ) # 7. 浏览器控制器 self.browser = BrowserController() async def execute_test_case(self, test_case_description: str, start_url: str = None): """执行一个测试用例""" print(f"\n=== 开始执行测试用例 ===") print(f"用例描述: {test_case_description}") # 启动浏览器并导航到起始页 await self.browser.start(headless=False) # 调试时设为False，看浏览器操作 if start_url: await self.browser.navigate(start_url) try: # 将测试用例描述和初始页面信息作为输入 initial_context = f"测试用例：{test_case_description}" if start_url: initial_context += f"\n起始页面：{start_url}。请从当前页面开始执行。" # 执行Agent result = await self.agent_executor.ainvoke({"input": initial_context}) print(f"\n=== 执行结果 ===") print(result["output"]) except Exception as e: print(f"执行过程中发生错误: {e}") finally: # 执行完毕，可以关闭浏览器或保持打开用于检查 # await self.browser.close() print("执行流程结束。") # 主程序 async def main(): agent_system = TestCaseAIAgent() # 示例测试用例 test_case = """ 1. 在登录页面，输入用户名‘testuser’。 2. 输入错误密码‘wrongpass’。 3. 点击登录按钮。 4. 验证页面是否出现‘密码错误’的提示信息。 """ start_url = "https://example.com/login" # 替换为你的测试登录页地址 await agent_system.execute_test_case(test_case, start_url) if __name__ == "__main__": asyncio.run(main())

5. 核心挑战与优化策略实录

在实际搭建和运行过程中，我遇到了不少预料之中和预料之外的挑战。下面分享几个最典型的“坑”以及我的解决方案。

5.1 挑战一：元素定位的模糊性与鲁棒性

问题：手工用例描述“点击登录按钮”，但页面上可能有多个按钮包含“登录”文本，或者元素是图标按钮没有文本。Agent调用click_tool(“登录按钮”)后，工具函数可能点击了错误的元素或直接失败。

解决方案：我采用了“多策略融合定位”和“上下文增强定位”。

1. 多策略融合：在click_tool内部，按优先级尝试：
   • page.get_by_role(“button”, name=“登录”)(ARIA角色)
   • page.get_by_text(“登录”)(模糊文本匹配)
   • page.locator(“button:has-text(‘登录’)”)(CSS + 文本)
   • 利用Playwright的locator(“input[type=‘submit’]”)等基于属性的定位。
2. 上下文增强：当基础定位失败时，工具函数会调用一个“元素定位辅助模型”（一个轻量级的LLM调用，例如GPT-3.5-turbo），将当前页面DOM摘要和元素描述发送给它，请求它返回一个更精确的CSS选择器或XPath。这显著提高了复杂场景下的定位成功率。
3. 视觉辅助（进阶）：对于纯图标或难以用代码描述的元素，可以集成视觉AI模型（如基于SIFT的特征匹配或轻量级CNN），通过截图对比来定位元素。但这会大幅增加系统复杂度，目前我仅在实验阶段尝试。

5.2 挑战二：测试步骤的规划与逻辑判断

问题：测试用例中常包含条件判断，例如“如果库存大于0，则显示‘立即购买’按钮，否则显示‘到货通知’”。单纯的顺序动作规划无法处理这种逻辑。

解决方案：增强Agent的规划能力和工具集。

1. 引入“观察”工具：增加一个observe_page_state(question: str)工具。Agent可以主动提问，例如“当前商品库存数量是多少？”或“‘立即购买’按钮是否可见？”。该工具会从页面中提取相关信息（通过DOM解析或OCR识别数字）并返回给Agent，供其决策。
2. 分阶段规划与检查点：在高层任务分解后，在每个阶段结束时，强制Agent调用一个checkpoint(阶段目标)工具。该工具会验证阶段目标是否达成（例如，“是否成功跳转到商品详情页？”），如果未达成，则触发重试或异常处理流程。
3. 使用支持复杂规划的高级框架：探索使用更高级的Agent框架，如LangChain的Plan-and-Execute模式，或者微软的AutoGen，它们对多智能体协作和复杂规划有更好的支持。

5.3 挑战三：执行效率与稳定性

问题：每一步操作都依赖大模型的推理和网络调用，导致执行速度慢，且API调用有成本和稳定性风险。

优化策略：

1. 缓存与记忆复用：对于重复的测试步骤（如登录），将成功的动作序列（工具调用链）缓存下来。下次遇到类似场景，可以直接复用缓存的“操作剧本”，无需重新规划。
2. 本地轻量级模型：对于元素定位辅助、页面状态判断等对推理能力要求不高的任务，使用本地部署的小模型（如经过微调的BERT分类模型）或规则引擎，减少对昂贵大模型的依赖。
3. 超时与重试机制：在每个工具调用外层包裹健壮的重试和超时逻辑。对于网络波动或页面加载慢导致的失败，自动重试数次。
4. 异步并行执行：对于独立的测试用例集，可以启动多个浏览器实例，由多个Agent并行执行，充分利用资源。

6. 效果评估与未来展望

经过一段时间的开发和调优，这个原型系统已经能够处理我们约30%的冒烟测试级别的手工用例，成功率（完全自动执行通过）在85%左右。对于剩下的用例，失败原因主要在于：1) 页面元素过于动态或复杂；2) 用例描述存在严重歧义；3) 涉及非UI操作（如文件上传、短信验证码）。

带来的价值是显而易见的：

• 释放人力：将测试工程师从重复、枯燥的手工执行中解放出来，更专注于测试设计、探索性测试和复杂场景挖掘。
• 提升覆盖率与一致性：AI可以不知疲倦地执行用例，确保每次回归的步骤完全一致，避免了人为疏忽。
• 加速反馈：可以集成到CI/CD流水线中，在代码提交后自动触发核心场景的验证。

当然，这远非终点。我认为这个方向还有巨大的演进空间：

1. 从“执行者”到“设计者”：未来的测试AI智能体，或许不仅能执行用例，还能基于需求文档或用户故事，自动生成测试用例和场景，实现测试左移。
2. 多模态能力融合：结合视觉（CV）和语音（ASR/TTS）模型，使其能处理图像验证码、语音提示等更真实的交互场景。
3. 自愈与自适应：当应用UI发生变更时，智能体能够通过对比历史截图和DOM结构，自动学习新的元素定位方式，更新“操作剧本”，实现一定程度的自我维护。

这个项目让我深刻体会到，AI Agent不是要取代测试工程师，而是成为一个强大的“数字同事”。它处理确定性的、重复的劳作，而人类则专注于创造性的、战略性的、需要深度判断的工作。构建这样一个系统的过程，本身也是对测试理论和自动化框架的重新思考。如果你也对此感兴趣，不妨从一个小而具体的测试场景开始尝试，比如“登录功能的异常流测试”，一步步搭建你的第一个测试AI智能体。