1. 项目概述当AI开始“浏览”网页最近在跟一个做自动化测试的朋友聊天他跟我大倒苦水说现在的Web应用越来越复杂前端框架三天一小变交互逻辑五花八门传统的基于DOM元素定位的自动化测试脚本维护成本高得吓人。一个按钮的class名或者># 创建项目目录并进入 mkdir webtest-agent-prototype cd webtest-agent-prototype # 创建虚拟环境推荐 python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # macOS/Linux: source venv/bin/activate # 安装核心依赖 pip install playwright openai python-dotenv # 安装Playwright所需的浏览器 playwright install chromium这里我们安装了三个核心库playwright用于控制浏览器获取页面信息执行操作。openai用于调用GPT API提供决策能力。python-dotenv用于管理API密钥等敏感信息避免硬编码在代码中。接下来在项目根目录创建一个.env文件存放你的OpenAI API密钥OPENAI_API_KEY你的实际api密钥4.2 核心模块一感知模块 - 获取页面“观察结果”我们创建一个perception.py文件其核心函数是获取当前页面的简化表示。# perception.py import asyncio from playwright.async_api import async_playwright import json async def get_page_observation(page): 获取当前页面的观察结果简化版。 返回一个包含页面URL、标题和关键元素的字典。 observation { “url”: page.url, “title”: await page.title(), “interactive_elements”: [] } # 获取所有可交互或关键的元素 # 这里是一个极其简化的示例获取所有按钮、输入框和链接 selectors [‘button’, ‘input’, ‘textarea’, ‘a[href]’] for selector in selectors: elements await page.query_selector_all(selector) for element in elements: elem_info {} # 获取元素的一些关键属性 elem_info[‘tag’] selector elem_info[‘inner_text’] (await element.inner_text()).strip()[:100] # 截断长文本 elem_info[‘placeholder’] await element.get_attribute(‘placeholder’) elem_info[‘type’] await element.get_attribute(‘type’) elem_info[‘name’] await element.get_attribute(‘name’) elem_info[‘id’] await element.get_attribute(‘id’) # 生成一个简单的、用于定位的描述符 # 在实际项目中这里需要更稳健的定位器生成逻辑 if elem_info[‘id’]: elem_info[‘locator’] f“#{elem_info[‘id’]}” elif elem_info[‘name’]: elem_info[‘locator’] f“[name‘{elem_info[‘name’]}’]” else: # 作为演示使用文本内容非常脆弱仅用于演示 if elem_info[‘inner_text’]: elem_info[‘locator’] f“text‘{elem_info[‘inner_text’]}’” else: elem_info[‘locator’] selector # 兜底 observation[‘interactive_elements’].append(elem_info) # 为了减少Token消耗我们只保留前20个元素实际应用需要更智能的过滤 observation[‘interactive_elements’] observation[‘interactive_elements’][:20] return observation if __name__ “__main__”: # 测试函数 async def test(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) page await browser.new_page() await page.goto(‘https://example.com’) obs await get_page_observation(page) print(json.dumps(obs, indent2, ensure_asciiFalse)) await browser.close() asyncio.run(test())这个感知模块非常基础它只是收集了页面上的按钮、输入框等元素及其部分属性。在真实的WebTestBench或生产系统中这里应该替换为获取可访问性树A11y TreePlaywright可以通过page.accessibility.snapshot()方法获得其信息质量要高得多。4.3 核心模块二决策模块 - 大语言模型作为“大脑”接下来创建agent_brain.py。这个模块负责接收“观察”和“任务”然后调用LLM决定下一步动作。# agent_brain.py import openai import os from dotenv import load_dotenv import json import re load_dotenv() # 加载 .env 文件中的环境变量 client openai.OpenAI(api_keyos.getenv(‘OPENAI_API_KEY’)) def decide_next_action(task_description, page_observation): 根据任务描述和页面观察决定下一个动作。 返回一个字典包含动作类型和参数。 # 构建给LLM的提示词 prompt f“”” 你是一个Web自动化助手。你的目标是完成用户给定的任务。 当前任务{task_description} 当前页面状态 - 页面URL{page_observation[‘url’]} - 页面标题{page_observation[‘title’]} - 页面上的交互元素简化列表 {json.dumps(page_observation[‘interactive_elements’], indent2, ensure_asciiFalse)} 你可以执行以下类型的操作 1. CLICK [locator] - 点击某个元素。locator是上面元素信息中的‘locator’字段。 2. TYPE [locator] [text] - 在某个输入框内输入文本。 3. NAVIGATE [url] - 导航到一个新的URL。 4. WAIT - 等待一段时间例如页面加载。 5. DONE - 任务已完成。 请根据当前页面状态和任务分析下一步最应该做什么。只输出一个操作指令格式必须严格为 ACTION: [动作类型] [参数1] [参数2...] 例如 ACTION: CLICK text‘Login’ 或 ACTION: TYPE [name‘username’] myusername 或 ACTION: DONE “”” try: response client.chat.completions.create( model“gpt-3.5-turbo”, # 或使用 gpt-4 以获得更好效果 messages[ {“role”: “system”, “content”: “你是一个严谨的Web自动化助手只输出指定的动作指令。”}, {“role”: “user”, “content”: prompt} ], temperature0.1, # 低随机性确保输出稳定 max_tokens150 ) llm_output response.choices[0].message.content.strip() print(f“LLM原始输出: {llm_output}”) # 解析LLM的输出提取动作和参数 action_match re.match(r‘ACTION:\s*(\w)(?:\s(.))?’, llm_output) if not action_match: return {“action”: “ERROR”, “params”: [“无法解析LLM输出”]} action_type action_match.group(1).upper() params_str action_match.group(2) params [] if params_str: # 简单的参数分割对于TYPE操作可能需要更精细的处理 params params_str.split(‘ ‘, 1) if action_type ‘TYPE’ else params_str.split() return {“action”: action_type, “params”: params} except Exception as e: print(f“调用LLM API时出错: {e}”) return {“action”: “ERROR”, “params”: [str(e)]} if __name__ “__main__”: # 简单测试 test_obs { “url”: “https://demo.testfire.net/login.jsp”, “title”: “Altoro Mutual”, “interactive_elements”: [ {“tag”: “input”, “name”: “uid”, “locator”: “[name‘uid’]”, “placeholder”: “Username”}, {“tag”: “input”, “name”: “passw”, “locator”: “[name‘passw’]”, “placeholder”: “Password”}, {“tag”: “button”, “inner_text”: “Login”, “locator”: “text‘Login’”} ] } task “登录到这个网站用户名是‘admin’密码是‘admin’” decision decide_next_action(task, test_obs) print(f“决策结果: {decision}”)这个决策模块的核心是构造一个清晰的提示词Prompt引导LLM根据页面元素和任务做出合理决策并以严格的格式输出动作指令。我们使用正则表达式来解析这个指令。4.4 核心模块三执行模块 - 将决策转化为浏览器操作创建executor.py它接收决策模块的指令并通过Playwright在真实浏览器中执行。# executor.py import asyncio from playwright.async_api import async_playwright class WebAgentExecutor: def __init__(self): self.playwright None self.browser None self.page None async def setup(self, headlessFalse): 初始化浏览器环境 self.playwright await async_playwright().start() self.browser await self.playwright.chromium.launch(headlessheadless) self.page await self.browser.new_page() # 设置超时和视口大小 self.page.set_default_timeout(30000) # 30秒 await self.page.set_viewport_size({“width”: 1280, “height”: 720}) async def execute_action(self, action_dict): 执行单个动作指令 action action_dict.get(‘action’) params action_dict.get(‘params’, []) if action ‘CLICK’ and params: locator params[0] print(f“执行点击: {locator}”) try: await self.page.click(locator) await self.page.wait_for_load_state(‘networkidle’) # 等待网络空闲 return True except Exception as e: print(f“点击失败 {locator}: {e}”) return False elif action ‘TYPE’ and len(params) 2: locator, text params[0], params[1] print(f“执行输入: 在 {locator} 中输入 ‘{text}’”) try: # 先点击输入框确保焦点再输入 await self.page.click(locator) await self.page.fill(locator, text) return True except Exception as e: print(f“输入失败 {locator}: {e}”) return False elif action ‘NAVIGATE’ and params: url params[0] print(f“执行导航: {url}”) try: await self.page.goto(url, wait_until‘networkidle’) return True except Exception as e: print(f“导航失败 {url}: {e}”) return False elif action ‘WAIT’: wait_time float(params[0]) if params else 2.0 print(f“等待 {wait_time} 秒”) await asyncio.sleep(wait_time) return True elif action ‘DONE’: print(“任务完成指令。”) return ‘DONE’ elif action ‘ERROR’: print(f“收到错误指令: {params}”) return False else: print(f“未知或参数不全的指令: {action_dict}”) return False async def close(self): 清理资源 if self.browser: await self.browser.close() if self.playwright: await self.playwright.stop() if __name__ “__main__”: async def test(): executor WebAgentExecutor() await executor.setup(headlessFalse) await executor.page.goto(‘https://example.com’) # 测试一个点击动作 test_action {“action”: “CLICK”, “params”: [“text‘More information...’”]} result await executor.execute_action(test_action) print(f“执行结果: {result}”) await asyncio.sleep(2) await executor.close() asyncio.run(test())执行模块是“手”和“脚”它必须足够健壮能够处理定位失败、元素未加载等异常情况。在实际项目中这里需要加入更完善的错误处理和重试逻辑。4.5 主循环将感知、决策、执行串联起来最后我们创建一个main.py作为主入口实现智能体与网页交互的主循环。# main.py import asyncio import json from perception import get_page_observation from agent_brain import decide_next_action from executor import WebAgentExecutor async def run_web_agent(task, start_url, max_steps20): 运行Web智能体的主循环。 task: 字符串描述要完成的任务。 start_url: 起始URL。 max_steps: 最大执行步骤防止无限循环。 executor WebAgentExecutor() await executor.setup(headlessFalse) # 调试时可设为False看浏览器操作 try: # 1. 导航到起始页面 print(f“开始任务: {task}”) await executor.page.goto(start_url, wait_until‘networkidle’) await asyncio.sleep(1) # 初始等待 for step in range(max_steps): print(f“\n——— 第 {step1} 步 ———”) # 2. 感知获取当前页面观察 observation await get_page_observation(executor.page) print(f“当前页面: {observation[‘title’]} ({observation[‘url’]})”) # 3. 决策LLM决定下一步动作 action_dict decide_next_action(task, observation) print(f“智能体决策: {action_dict}”) # 4. 执行在浏览器中执行动作 result await executor.execute_action(action_dict) # 5. 检查结果 if result ‘DONE’: print(“智能体认为任务已完成。”) # 这里可以添加最终状态验证逻辑 break elif not result: print(“动作执行失败任务可能无法继续。”) break elif step max_steps - 1: print(“达到最大步骤数任务未完成。”) # 执行后短暂等待让页面稳定 await asyncio.sleep(1) except Exception as e: print(f“运行过程中发生异常: {e}”) finally: await executor.close() print(“\n智能体运行结束。”) if __name__ “__main__”: # 示例任务在一个测试登录页面上登录 TASK “找到登录表单输入用户名‘admin’和密码‘admin’然后点击登录按钮。” START_URL “https://demo.testfire.net/login.jsp” # 一个公开的测试银行网站 asyncio.run(run_web_agent(TASK, START_URL, max_steps10))现在运行python main.py你会看到一个浏览器窗口打开导航到测试网站然后智能体开始尝试分析页面元素并逐步执行登录操作。虽然这个原型非常简陋但它清晰地展示了感知 - 决策 - 执行的完整闭环这正是WebTestBench所评估的智能体的核心工作流程。注意这个原型仅为教学演示存在大量简化感知层极其薄弱仅获取了少量简单元素真实环境需要A11y树。决策层提示词简单容易受到LLM幻觉影响需要更精细的提示工程和约束。执行层容错差定位器生成逻辑脆弱缺乏重试和备用定位策略。无状态验证任务是否真正成功需要定义明确的成功条件并在循环中检查。成本与性能每一步都调用LLM成本高且速度慢。实际应用需优化如缓存、批量处理决策等。5. 挑战、优化方向与行业影响构建一个真正实用、可靠的Web测试智能体远非一个原型那么简单。WebTestBench这类基准测试的出现正是为了系统地暴露和度量这些挑战。5.1 当前面临的主要挑战感知的完备性与噪声如何从复杂、动态的现代Web页面包含大量JavaScript、iframe、Shadow DOM中提取出足够完备、简洁且无噪声的语义表示A11y树并非总是完整或准确视觉信息又难以精确解析。LLM的可靠性与成本大语言模型的输出具有不确定性可能产生“幻觉”执行无效或危险操作。同时每一步都调用LLM的延迟和成本在大型测试套件中难以承受。动作的精确映射与鲁棒性如何将智能体输出的高级指令如“点击登录按钮”稳定、准确地映射到浏览器中一个具体的、可能动态变化的DOM元素这是连接“决策”与“执行”的关键桥梁也是最容易失败的地方之一。长流程任务的状态跟踪对于一个需要十几步甚至几十步的复杂业务流程如配置一个云服务器智能体如何记住自己的目标、当前进展和已执行的操作这需要引入更复杂的内存和状态管理机制。评估的全面性除了“是否成功”如何评估智能体行为的“质量”例如它的操作路径是否高效是否遵循了最佳实践如先等待元素加载再点击是否避免了不必要的操作5.2 可行的优化方向与技术演进混合感知策略结合A11y树、精简DOM、视觉特征嵌入通过小型视觉模型提取以及页面截图的部分OCR形成多模态的页面表示提高感知的鲁棒性。分层决策与技能库并非所有决策都需要动用大模型。可以建立一个“技能库”将常见的原子操作如“填写表单字段”、“点击导航栏”固化下来。LLM负责高层任务规划和异常处理常规操作由更轻量、更可靠的规则或小模型处理。这能显著降低成本和延迟。强化学习与从经验中学习让智能体在WebTestBench这样的环境中反复运行根据成功/失败反馈进行微调如通过强化学习微调一个小型策略模型使其行为越来越高效和可靠。更智能的元素定位结合多种定位策略语义、视觉、布局并设计回退机制。例如当“点击登录按钮”的指令无法通过文本匹配时可以尝试寻找页面上唯一的role”button”且name包含”登录”的元素。定义更丰富的评估维度WebTestBench的未来版本可能会引入更多指标如任务完成时间、与人类操作轨迹的相似度、对UI微小变化的容忍度等以更全面地评估智能体的能力。5.3 对自动化测试与RPA行业的潜在影响WebTestBench及其代表的Computer-Use Agents方向其影响可能远超自动化测试本身。对测试工程师角色的重塑测试工程师的工作重心将从编写和维护大量脆弱的脚本转向设计更智能、更复杂的测试任务场景训练和评估AI智能体以及分析智能体失败的根本原因这本身就是一个高级的调试过程。他们需要更深入的理解业务逻辑和AI行为。降低自动化门槛对于一些相对标准但仍有变化的流程如不同电商网站的结账可能不再需要为每个网站单独编写脚本。一个训练有素的通用智能体或许就能处理。这将使前端UI变化频繁的团队更容易维持E2E测试的覆盖。探索性测试的自动化智能体可以模拟用户进行一些探索性操作甚至主动尝试边界情况有可能发现那些基于固定脚本的测试无法覆盖的、意料之外的缺陷。向广义RPA的延伸这套“感知-决策-执行”的范式同样适用于桌面应用、移动端应用乃至整个操作系统层面的自动化。WebTestBench可以看作是这一宏大愿景在Web领域的一个先驱性试验场。未来我们或许会看到“DesktopTestBench”、“MobileTestBench”的出现。这个领域目前仍处于早期探索阶段充满了技术挑战但也蕴含着巨大的可能性。WebTestBench这样的基准测试平台就像为这个新兴领域点亮了一盏路灯让研究者、开发者和企业能够看清前进的道路衡量进步的尺度。对于每一位从事软件测试、质量保障或自动化工作的工程师来说理解并关注这一趋势或许就是在为未来几年的工作方式提前做准备。