OpenClaw+飞书：AI Agent驱动UI自动化测试实战

做UI自动化的朋友这两年应该都有同感项目跑得越多脚本库越像一坨“会动的遗产”。页面结构一改定位器全挂流程一复杂断言逻辑写到手软好不容易跑完了几十条失败还得人肉筛。我之前维护一套基于Selenium的Web自动化用例光修定位器和处理误报就占了一半时间。直到我把OpenClaw和飞书搭到一条链路上让AI去驱动UI自动化测试情况才算有了本质变化。这套方案的核心思路很简单OpenClaw作为AI Agent的执行框架负责理解任务、规划步骤、调用浏览器工具飞书作为消息入口和结果出口相当于给测试体系装了一个“遥控器”和“显示屏”。测试人员不用再打开IDE、改脚本、敲命令直接在飞书里发一句话测试就自动跑跑完把结果、日志、截图原样推回来。这篇文章我会从方案选型、环境部署、首个用例落地、结果回传、排坑实录五个部分完整展开涉及的具体配置和代码我都会给出方便你照着搭。适合正在做Web UI自动化、想引入AI Agent的测试开发、运维和独立开发者参考。1. 方案选型传统UI自动化为什么需要AI来搭把手1.1 传统UI自动化的三个死结先说痛点。UI自动化做了这么多年工具从QTP换到Selenium再换到Playwright但核心问题一直没变。第一个死结是定位器太脆弱。登录按钮之前叫btn-login前端工程重构以后改成btn-primary你所有用例集体阵亡改起来又臭又长。更麻烦的是现在的前端框架大量使用动态class和嵌套组件CSS选择器根本没法稳定命中。有些页面甚至加了随机ID每次刷新都不一样固定定位器这条路基本走死。第二个死结是断言逻辑太僵化。传统UI测试的断言无非几种等待元素出现、判断URL变化、检查某个文本是否存在。但真实业务里“登录成功”不一定等于跳转首页可能首页还在异步加载可能弹了个欢迎弹窗可能右上角用户信息延迟一秒才出来。你写早了误报写晚了超时最后只能靠一堆sleep硬扛。第三个死结也是我最受不了的——维护成本完全失控。业务流程一变脚本改动的不是一个点而是一条链。改登录、改表单、改按钮、改跳转逻辑每一处都得跟着调。时间长了脚本库就成了没人敢碰的“祖传代码”每次发版跑回归都像拆炸弹。这三个死结的根源在于传统自动化是在“用代码模拟用户操作”但页面是给人看的不是给代码看的。人能找到按钮是因为我们理解页面语义代码只能靠选择器本质上是盲人摸象。AI加入以后解决的就是“理解页面语义”这件事。1.2 OpenClaw和飞书在链路中各自扮演什么角色先说OpenClaw。它是一个开源的AI Agent编排框架核心能力是让大模型能调用外部工具。你可以把它理解成一个“中间调度层”大模型负责理解和规划OpenClaw负责把规划翻译成实际动作比如启动浏览器、点击按钮、读取文件、发HTTP请求。UI自动化测试需要的东西它基本都具备。飞书在这里的角色更偏向“入口”和“出口”。入口是指令通道测试人员不用打开任何开发工具直接在飞书群里给机器人发消息消息通过事件订阅推给OpenClaw。出口是结果通道测试跑完OpenClaw把文本报告、截图、日志通过飞书机器人推回来甚至可以把执行记录写进多维表格做数据沉淀。这两个工具配合起来的好处是测试体系从“本地封闭”变成了“团队协作”。以前跑测试只有写脚本的人知道怎么看结果现在产品、开发、测试都能在飞书群里看到完整报告。出问题直接相关人效率不是一个量级。1.3 为什么不是“脚本Jenkins”或“纯LLM”有人可能会问我现在用Jenkins定时跑脚本再加个飞书通知不也差不多吗区别很大。传统“脚本Jenkins”是定时触发不能按需临时跑AI驱动是对话触发你说跑就跑。传统脚本的每一个步骤都要写死页面一变就报废AI驱动是语义理解加动态执行即使定位器变了AI可以通过页面文本、上下文、甚至截图来重新找到目标元素。最关键的一点传统脚本只能验证“写死的预期”AI可以结合业务上下文做更灵活的断言判断。也有人问为什么不直接让ChatGPT读页面这里有个根本限制大模型本身不能操作浏览器。它只能生成文本真正点按钮、填表单、截图的动作必须有工具层去执行。OpenClaw这类Agent框架解决的就是这个“最后一公里”它把大模型的能力和浏览器操作绑定在一起形成完整的“感知-决策-执行-验证”闭环。做一个简单的对比对比项传统脚本Jenkins纯LLMOpenClaw飞书触发方式定时/手动对话生成代码飞书对话直接触发元素定位固定选择器无法操作浏览器语义理解动态定位断言能力写死预期只能给建议AI结合上下文判断结果反馈邮件/控制台无飞书图文表格维护成本高低但不可执行中低以调Prompt为主2. 环境准备先把OpenClaw和飞书两条腿接上2.1 部署OpenClaw的几种方式OpenClaw的部署方式比较灵活我试过的有三种。第一种是Docker部署适合不想污染本地环境的人。官方仓库通常提供docker-compose.yml把配置改好以后一条命令启动。好处是OpenClaw全家桶都在容器里升级和卸载都干净。缺点是对网络环境有一定要求拉镜像偶尔会卡住多试几次就行。第二种是本地一键脚本部署适合在服务器上快速安装。官方提供的安装脚本会自动检测系统依赖把Node/Python运行时和环境变量一并配好。这种方式在Ubuntu和Debian上实测比较稳基本上几分钟就能起来。第三种是源码运行适合要二次开发的人。先把仓库clone下来安装依赖然后手动配置环境变量。优点是你能改底层的工具调用逻辑缺点是升级麻烦每次拉代码可能冲突。如果你只是做测试不推荐直接从源码跑。无论哪种方式装完之后第一步都是检查核心服务是否正常。浏览器控制端通常叫control ui会监听一个本地端口如果这个服务没起来Agent就无法操作浏览器。这个问题后面我会在排坑章节专门讲。2.2 在飞书开放平台创建自建应用飞书侧的准备步骤比较固定按着走就行。打开飞书开放平台进入开发者后台创建一个企业自建应用。填名字和图标然后进入应用配置页。这里有几个关键的配置项第一添加“机器人”能力。应用默认是空的需要在“添加应用能力”里找到机器人开启后应用才能在群聊里收发消息。第二获取App ID和App Secret。这两个凭证在“凭证与基础信息”页面后续OpenClaw接入飞书渠道时要用相当于飞书发给这个应用的身份证。第三配置事件订阅。UI自动化测试的核心场景是“有人在群里发指令”所以必须订阅接收消息事件事件名为“im.message.receive_v1”。订阅地址填OpenClaw暴露出来的回调URL通常是在OpenClaw配置里指定的一个webhook路径。这里要注意飞书要求回调地址必须是公网可达的HTTPS地址如果你部署在本地需要借助公网转发能力把本地端口映射出去。第四开通权限。机器人要能读消息、发消息、上传图片这些分别对应不同的API权限在“权限管理”里逐个开通然后发布应用版本。这里容易踩坑只改权限不发版是不生效的必须走一遍“创建版本-发布”流程版本审核通过后重新授权才真正生效。2.3 把飞书接入OpenClawOpenClaw的配置一般是一个JSON或YAML文件里面按channels划分不同渠道飞书是其中一个channel。我用的配置大致长这样{ channels: { feishu: { app_id: cli_xxxxxxxx, app_secret: xxxxxxxxxxxxxxxx, encrypt_key: , verification_token: , event_endpoint: /webhook/feishu } } }这里的app_id和app_secret就是刚才在飞书后台拿到的。event_endpoint是OpenClaw监听的本地路径配合你部署时配置的公网地址拼成飞书事件订阅的完整回调URL。配置好以后重启OpenClaw然后在飞书里给机器人发一条“你好”如果OpenClaw日志里出现收到消息的提示就说明通道打通了。这一步是整个方案的地基后面所有自动化测试的指令都是走这条消息通道进来的。2.4 让OpenClaw获得操作浏览器的能力OpenClaw本身不是一个浏览器自动化工具它要通过MCP协议接入浏览器操作能力。目前主流的选择是Playwright的MCP服务它把打开页面、点击、输入、截图、提取元素等操作封装成标准接口大模型通过工具调用就能控制真实浏览器。在OpenClaw的配置里加一个MCP Server{ mcp_servers: { playwright: { command: npx, args: [playwright/mcplatest] } } }加了以后重启服务OpenClaw会自动发现这些工具并暴露给大模型。你可以先在控制端手动测试一下让AI打开一个网页截图如果这一步能成功说明工具链路是通的。这里提醒一点如果你跑在服务器上没有真实显示器Playwright要用headless模式运行不要显示浏览器窗口这需要在MCP Server的启动参数里加上headless相关配置。否则服务会一直报“连接超时”排查起来很头疼。3. 首个AI驱动用例让AI自己找到登录按钮3.1 场景定义登录页回归测试配置都通了接下来跑第一个真正的用例。我选的场景是很多团队都有的Web后台登录页输入用户名密码点击登录验证是否进入系统首页。传统玩法这一步要写Selenium脚本、找定位器、写断言、跑报告。在OpenClaw飞书这套方案里测试人员的操作变成了在飞书群里发一条消息告诉机器人“执行登录页回归测试”附上测试账号和密码然后就等结果。听起来简单但AI到底是怎么完成这个任务的值得拆开看。它不是靠预设脚本而是靠大模型的规划和推理能力一步一步执行浏览器工具并在执行过程中实时观察页面状态。这背后其实是一次“任务规划-工具调用-结果验证”的完整Agent循环。3.2 用自然语言描述用例而不是写死定位器传统脚本和AI Agent在用例表达上有一个显著差异。传统脚本写的是“让浏览器做什么”比如driver.find_element(By.ID, username).send_keys(u001) driver.find_element(By.CSS_SELECTOR, .login-btn).click()这种实现依赖页面结构一旦前端改了class或者ID用例就废了。AI Agent的写法则更接近自然语言比如在OpenClaw的任务配置里这样定义场景登录页回归测试 步骤 1. 打开测试环境登录页 2. 输入用户名和密码 3. 点击登录 4. 验证是否成功进入首页 成功标准页面出现用户昵称或跳转到首页OpenClaw里的Agent拿到这个描述后会动态决定每一步怎么执行。它打开页面后先截图观察页面结构通过按钮上的文字“登录”去定位而不是依赖CSS选择器。这就是AI驱动测试最核心的差异它理解页面内容而不是匹配页面代码。3.3 落地实现的关键配置让OpenClaw能处理这类任务需要在配置里注册一个自定义Skill或者在任务描述中把Prompt写清楚。我常用的做法是在OpenClaw里配置一个“UI测试执行器”的Prompt模板你是一名资深UI自动化测试工程师。 请使用浏览器工具完成以下测试任务。 操作约束 1. 打开页面后先截图观察页面结构再执行操作。 2. 定位元素优先使用可见文本不要在识别不到时猜测固定ID。 3. 每次操作后都必须截图确认结果。 4. 如果页面出现错误提示不要继续执行记录错误并终止。 5. 最终输出一个JSON格式的测试报告包含用例名称、执行步骤、截图路径、通过与否。这样配置的好处是AI的行为是受约束的不会乱点。实际跑测试时我给机器人发一条指令OpenClaw把这条指令和Prompt模板一起交给大模型大模型生成执行计划然后逐步调用Playwright工具完成操作。3.4 用飞书多维表格管理测试用例和结果用例多了以后不可能每次都靠聊天指令传参这时候飞书多维表格就派上用场了。我把所有UI测试用例都维护在一张多维表格里字段包括用例ID、用例名称、测试数据、预期结果、最近执行状态、失败原因。OpenClaw通过飞书开放API读取多维表格的记录拿到用例列表后按需执行。比如我发指令说“跑今天变更涉及的所有用例”OpenClaw先从多维表格查出状态为“待回归”的用例逐个执行最后把执行结果写回表格。这样测试数据和测试逻辑分离产品和测试都能维护用例不再依赖脚本代码。多维表格还有一个好处是天然支持视图和筛选。我可以建一个“失败用例”视图OpenClaw跑完以后自动把失败记录追加到月末总结里老板问起来直接甩链接比翻日志强多了。4. 实操记录从飞书发指令到收到测试报告4.1 完整流程时间线一套完整的执行链路从发指令到收报告过程大致如下第一步测试人员在飞书群里输入“/uitest login_page 用户名u001 密码123456”。这里的斜杠命令不是飞书原生的而是OpenClaw在收到消息后做的语义解析。你甚至不用斜杠直接发“跑一下登录页的回归用u001这个账号”也能触发大模型能理解口语化指令。第二步飞书把这条消息通过事件订阅推送到OpenClaw。OpenClaw判断这是一条测试执行请求进入Agent工作流。第三步Agent读取任务配置明确当前场景是“登录页回归测试”。如果配置了多维表格它会同时拉取相关测试数据。第四步Agent调用Playwright工具启动浏览器进入被测环境按顺序执行截图、定位元素、输入、点击等操作。第五步页面跳转后Agent再次截图分析页面文本和状态判断是否达到预期结果。第六步Agent汇总执行日志、截图和结论调用飞书API发送图文消息到群里。如果配置了多维表格还会同步更新用例状态。整条链路从发消息到收到报告快的时候不到一分钟。比本地跑完脚本再手动截图、整理邮件快了一个数量级。4.2 关键节点上的AI决策细节很多朋友好奇AI在执行过程中到底是怎么“思考”的。我记录过一次实际运行的细节非常有参考价值。AI打开登录页后第一件事不是急着输账号而是先对整个页面截图。这一步很多人会忽略但它极其关键LLM本身不直接“看”页面源码它需要通过截图或可访问性树来感知页面内容。截完图后AI在内部生成了一段描述类似“页面左上角有logo中部是用户名输入框下方是密码输入框底部蓝色按钮显示‘登 录’”。接下来填数据。AI先定位用户名输入框通过placeholder文本“请输入手机号/邮箱”判断这是用户名框填入u001。密码框同理但有个细节——AI知道密码框的type属性是password所以截图里会显示为圆点它不会误判为空。这里用了“感知推理”的双重校验。点登录之后页面卡了两秒才跳转。传统脚本这时候大概率因为等待时间不够而误报但AI的做法是先等待再截图发现页面URL变成/home并且右上角出现了“欢迎你u001”才判定通过。如果页面上弹出“账号或密码错误”AI会把这段文本原样写进报告并且标记为失败而不是简单看URL。这个案例说明AI驱动测试的断言不再是“等一个布尔值”而是“综合页面文本、结构、状态做业务层面的判断”。这才是它比传统脚本值钱的地方。4.3 报告回传图片、日志和表格测试跑完结果怎么回到飞书这里需要调用飞书开放API。我先上传截图拿到image_key再发消息时附上。下面是一个简化版的上传和发送示例import requests APP_ID cli_xxxxxxxx APP_SECRET xxxxxxxxxxxx def get_tenant_token(): url https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal resp requests.post(url, json{app_id: APP_ID, app_secret: APP_SECRET}) return resp.json()[tenant_access_token] def upload_image(token, path): url https://open.feishu.cn/open-apis/im/v1/images with open(path, rb) as f: resp requests.post( url, headers{Authorization: fBearer {token}}, data{image_type: message}, files{image: (path, f, image/png)}, ) return resp.json()[data][image_key] def send_msg(token, chat_id, text, image_keyNone): url https://open.feishu.cn/open-apis/im/v1/messages?receive_id_typechat_id msg_type image if image_key else text content {image_key: image_key} if image_key else {text: text} resp requests.post( url, headers{Authorization: fBearer {token}}, json{receive_id: chat_id, msg_type: msg_type, content: content}, ) return resp.json()这段逻辑放到OpenClaw的执行后处理里就能实现“测试结束自动发报告”。我习惯在报告里附上三样东西失败截图、执行摘要、失败原因。执行摘要用一句话描述比如“登录页回归测试执行完成通过2/3失败1条失败原因是验证码输入超时”。这样群里的人一眼就能看到关键信息不需要打开Excel。如果团队有数据沉淀的需求还可以把执行记录追加到多维表格里保留每天每次执行的历史。时间长了就能看出哪些用例最不稳定哪些页面改动最频繁反向指导开发和测试策略。5. 排坑实录OpenClaw飞书落地中的常见问题5.1 先给你一张速查表真正落地的时候问题比想象的多。我把自己踩过的坑和群里朋友反馈过的问题整理成一个表格按优先级排序现象可能原因处理方法OpenClaw控制端打不开control ui服务未启动查看服务日志确认端口是否被占用重启服务发送消息后Agent无响应飞书事件订阅没回调成功检查回调URL是否公网可达查看OpenClaw渠道日志Agent报“unknown model”模型配置的ID不对检查模型名称是否在当前模型服务商可用列表中飞书报错误代码2700002事件订阅的签名或token校验失败核对encrypt_key和verification_token配置AI找不到页面上的输入框页面使用了iframe或shadow DOM让AI先切换到对应frame或配置为展开shadow DOM浏览器自动化一直超时headless模式未开启或MCP服务未启动给Playwright MCP加headless参数确认npx进程存活飞书群里收不到消息机器人权限未开通或版本未发布确认权限已开重新发布应用版本并授权这些坑里最隐蔽的是“权限已开但不生效”。飞书开放平台的权限改动必须重新发布版本而且老版本要下线新版本要全体成员重新授权。如果你改了权限后发现机器人还是不能发消息先去检查应用是不是还停在旧版本。5.2 提升AI执行稳定性的几个实操技巧AI执行UI操作偶尔会“犯迷糊”但大部分问题可以通过工程手段规避。第一拆解步骤一次让AI只做一件事。不要让它一口气“打开页面并完成登录并检查优惠券弹窗”步骤越长越容易中途出错。每个步骤结束加上“截图确认”的约束相当于给AI加了一道检查点。第二给AI限制操作边界。Prompt里明确写“如果页面出现错误提示停止执行并记录”这能避免AI在异常页面上反复操作把简单问题放大成连锁故障。第三设置超时和重试。AI可能因为页面加载慢导致定位不到元素一次失败不代表用例失败。我通常在完成一个步骤后留出8-10秒的缓冲时间如果第一次点击没生效AI会截图重新判断再点一次。这比传统脚本的“等待5秒后断言”智能得多。第四把验证逻辑单独拆出来。有时候输入和点击都成功了但页面跳转慢AI可能误判为失败。我现在的做法是比较关键的断言步骤单独给一段Prompt“请等待页面加载完成再检查是否出现以下标识”然后列出3个备选的验证点。让AI有多个判断依据不要孤注一掷。5.3 团队落地的节奏建议我不建议一上来就把所有用例都迁到AI驱动上。最稳妥的路径是先挑一个核心场景登录、注册、搜索这类跑通全链路让团队看到效果再逐步扩大范围。我个人的经验是第一批迁移两个场景就够了。一个是登录页因为它足够典型覆盖了输入、点击、跳转、断言这些核心操作另一个是主流程里的搜索加列表页因为它涉及异步加载和动态内容判定能验证AI在处理复杂页面的能力。这两个场景跑顺以后就可以考虑把OpenClaw接入CI/CD流水线在发版前自动触发回归。飞书群里发一条指令或者由流水线自动发起测试跑完直接在群里广播结果。到这一步整个测试体系就已经从“脚本维护”切换到“场景维护”了。需要注意的是AI驱动测试依然需要人工抽查尤其是失败用例要定期复盘看是页面问题、数据问题还是AI判断失误这样才能持续调优Prompt和流程。最后再分享一个实践中的小技巧把常用的测试指令固化成语义模板比如“跑一下{模块名}的回归用{账号}”。这样团队成员即使完全不懂AI和代码也能在飞书里发起测试。比如“跑一下支付流程的回归用test_02账号”。这类指令进入OpenClaw后大模型会自动匹配到对应的测试场景后端再按既定步骤执行。这样团队里每一个人都能顺畅使用这套系统而不再只是测试开发专属的工具。这是我从“AI自动跑用例”走向“团队能自助跑用例”的关键一步。