先交代背景我干了八年测试开发其中五年都在跟 Selenium 打交道。这五年里我见过团队的人为了一个动态 id 死磕一整天见过凌晨两点还在群里问为什么昨天能跑的用例今天全红了也见过项目上线前把整个自动化套件临时砍掉一半因为实在修不过来。所以当 AI 这波浪潮砸过来的时候我最关心的就一件事Selenium 那些让人头秃的破事AI 到底能不能真的解决而不是又来一个花架子工具。今天这篇不聊虚的就把我最近总结出来的一套 AI Selenium 落地玩法摊开讲怎么把原本 3 天的回归测试工作量压缩到 15 分钟思路、选型、代码、踩坑全给你捋一遍。先说结论Selenium 本身没有做错什么折磨我们的从来不是工具而是“写脚本的人要去替浏览器思考”这件事占了太多时间。AI 的价值恰恰在于把你从那些机械、重复、需要反复试错的泥潭里捞出来。我这里说的 AI不是哪个公司的什么黑魔法就是现在大家都在用的多模态大模型加上代码生成能力配合一套合理的自动化测试框架让机器替你去生成定位策略、维护用例、分析失败原因。方向对了效率提升十倍真不是夸张。这篇文章适合谁看如果你正在用 Selenium 写 Web 自动化天天被元素定位、等待、维护困扰如果你是测试组长想给团队引入 AI 辅助测试但不知道从哪儿下手又或者你只是好奇 AI Agent 在测试领域到底能干什么那这篇内容基本就是给你准备的。全程没有晦涩的理论堆砌只有我实测过的方案和改过的代码按着做能直接落地。1. 先复盘Selenium 到底在哪些地方让人想摔键盘1.1 折磨点一元素定位像开盲盒Selenium 最基础的操作就是找元素但找元素这件事在真实项目里有多恶心只有真正经历过的人才知道。早期的项目还好id 规规矩矩name 也起得明明白白。现在的 Web 项目基本被前端框架统治了React、Vue 一上动态 id 满地跑比如input_8x2ak3这种带随机数的你这边刚写死那边一刷新就变了测试直接崩。更烦的是各种弹窗、iframe、shadow DOM 叠加在一起你明明在页面上肉眼看到了那个按钮Selenium 就是定位不到那种感觉就像你伸手去按电梯按钮手指直接穿过去了。我统计过自己团队的情况一个中型 Web 项目的自动化套件大概 600 条用例每周因为定位符失效而失败的用例平均有 40 到 60 条。每一条都要人去打开页面、翻代码、重新定位、改脚本、回归验证一条平均花 20 分钟到半小时。光这一项一周就烧掉整整两天的工时。这是 Selenium 折磨人的第一个大头不是脚本写不出来是脚本活不过两周。1.2 折磨点二等待策略成了团队玄学新手写 Selenium 最爱干的事就是time.sleep(5)无脑睡 5 秒。结果就是快的时候其实 2 秒就加载完了白等 3 秒慢的时候 5 秒还不够页面还在转圈脚本就傻乎乎地去找元素然后报错。有人改用隐式等待implicitly_wait(10)看起来聪明一点但隐式等待对元素存在性判断是通用的一旦遇到动态加载、异步请求的场景依然是杯水车薪。真正正确的做法是用显式等待配合WebDriverWait加各种expected_conditions但显式等待写多了之后每一个元素都要琢磨该等什么条件该设多少超时时间代码量直接翻倍。更诡异的是环境和环境之间的差异。测试环境明明点一下 2 秒就出结果CI 机器上跑偏偏要 6 秒。你在本地怎么调都通过上了 CI 就蹦出一排超时。这种问题没有银弹只能靠经验去指定策略。而 AI 最强的地方恰恰是它见过海量的项目代码你把它之前成功的等待策略喂给它它能给你生成一套比人写的还要稳健的等待逻辑。1.3 折磨点三用例维护的成本比开发还高测试圈有句话叫“自动化测试的维护成本高到让团队怀疑人生”一点都不夸张。一个典型的业务系统前端三天一小改、五天一大改。今天把登录按钮的 class 改了明天把下单流程的步骤从三步改成四步后天把某个文本框的动态 id 又换了。每一次改动自动化测试脚本都要跟着动。传统做法是测试人员打开 IDE搜索所有引用这个元素的代码一个一个去改定位表达式改完跑一遍看还有没有其他地方报错。这种机械、重复、毫无创造性的工作恰恰是 AI 最擅长处理的。我实测过把一个失败报告丢给大模型让它分析失败原因并给出新定位符准确率能做到七八成。剩下的两三成人工确认一下就好。这比从零去排查快得多我后面第 3 章会写具体的操作流程。1.4 折磨点四断言、数据和报告全是隐形成本大家一说 Selenium 只想到元素操作其实断言、测试数据和结果报告也是耗时大户。断言写得太粗页面上明显的错误提示都抓不到写得太细页面加载慢一点就误报。测试数据更是个坑注册过的用户名不能再用、订单状态必须符合前置要求每次跑用例之前都要串来串去地准备。最后的数据报告如果公司没搭现成的测试平台你还得手动把失败截图、日志、接口信息整理成表格发给开发。这一整套东西靠人肉去做3 天其实是非常保守的估算。真正复杂点的项目一个完整的冒烟加回归周期你有 5 天都不够用。那 AI 进来之后到底是怎么把这些环节逐一消化的这个放到第 2 章详细说。2. AI 辅助测试的核心思路与方案选型2.1 别指望 AI 替代 Selenium要让它替代你的重复劳动先说一个很多人容易搞错的方向。网上有不少人在讨论“AI 会不会取代 Selenium”“AI 来了还要不要学自动化测试”这都是把关系搞错了。Selenium 是一个真实可控的浏览器自动化协议和工具库它负责的是“执行”。AI 是什么AI 是“思考”。你让 AI 直接去操作浏览器现在的技术确实可以做到市面上也有 Agent 产品能看图点按钮但成本高、稳定性差、企业内网环境还不好部署。与其这样不如让 AI 去生成 Selenium 代码、诊断失败原因、维护用例逻辑再让 Selenium 去稳定执行。一个管脑力一个管体力各干各擅长的。这个思路的好处是你现有的测试框架、CI 流程、测试平台全部不用推翻AI 只是在脚本生成和维护环节插了一脚。改造风险极小团队接受度也高。我见过有人一上来就买一堆重平台最后发现 Selenium 脚本根本没法直接兼容结果推几个月推不下去纯属自己给自己挖坑。2.2 三种最实用的 AI 介入姿势我实测下来现阶段真正能落地并且出效果的基本是下面三种方式。第一种是 AI 写脚本。你描述业务操作流程比如“进入首页点击登录输入用户名密码点击提交断言跳转到个人中心”大模型直接给你生成完整的 Selenium 代码包括 import、等待、异常处理。这适合前期从 0 到 1 搭建自动化套件的时候效率堪比直接复印代码。第二种是 AI 辅助元素定位。把页面的 HTML 片段或者截图丢给多模态大模型让它帮你分析用哪些定位策略最稳。比如面对一个动态 idAI 会建议你用相对定位、XPath 轴定位或者 CSS 属性匹配。这招在处理动态元素时特别好使比我之前教的那些经验还要快。第三种是失败诊断与自动修复。用例跑挂了把报错信息、截图、录制到的页面状态丢给 AI让它判断是产品真的出 bug 了还是定位符失效了如果是后者直接给出替代方案。这个是我最常用的后面会特意展开写。2.3 工具选型我用的这套组合价格便宜还能落地现在市面上的 AI 工具眼花缭乱我用下来最顺手的组合是下面这套成本可控效果稳定适合绝大多数测试团队复刻。多模态大模型这一块日常用 GPT-4o、Claude 都行国内的话也可以用主流的大模型 API重点是要能识别截图和 HTML 文本。代码生成插件方面如果你还在 IDE 里写脚本GitHub Copilot 或者同类 AI 编程助手可以装上补全速度比人敲键盘快太多了。真正重头的其实是流程编排我建议大家先用现成的 AI Agent 工具来实验。你给它一个任务描述让它自己规划步骤、调用工具、产出结果。比如你告诉它“帮我看看这套测试为什么失败并修复它”它自己就会去提取日志、对比页面、生成新定位符。这里不硬性指定品牌只要是能调用浏览器工具或代码执行工具的都行。等流程跑通了再考虑用代码把 Agent 固化到自己的框架里。小团队的轻量做法是直接用 Python 调大模型 API把提示词封装成函数在自动化框架里留一个“AI 修复助手”的入口成本可能就一杯奶茶钱跑一个月。对你没看错按量计费下用不了多少钱。2.4 整体流程设计从 3 天到 15 分钟是怎么拆解的我把自己用下来的一套流程画在脑子里给你们描述一下你们感受下这个节奏。原来的 3 天工作量大概是这样的花半天梳理测试范围一天写脚本和调试定位符半天准备测试数据和断言逻辑最后一天跑用例、修问题、发报告。每一步都是人在动手AI 一点没参与三天时间就这么没了。现在的流程变成了第一步你花一个小时把核心业务路径用自然语言写清楚第二步AI 在几分钟之内给你生成初步脚本你跑一遍看个大概第三步针对跑不通的地方截图喂给 AI它直接给你修复方案第四步让 AI 补全边界条件的测试数据和断言第五步正式跑回归全程盯着日志有失败就让 AI 先诊断一轮你再确认。整个过程下来前期投入可能还是需要一个小时但后续每天的回归真的只需要 15 分钟左右。说白了AI 没有把测试工作完全清零它做的是把那些占大头的、可重复的、靠经验试错的 3 天压缩成一个小时的初始化加每天 15 分钟的机器辅助维护。3. 实操演示一个登录到下单的回归用例AI 怎么帮我跑完全程3.1 场景定义从一个常见的 B 端订单系统说起为了让你们有一个具体的感知我就拿一个极其典型的内网订单管理系统来做演示。这套系统的前端是 Vue后端是 Java登录页长这样一个用户名输入框、一个密码输入框、一个登录按钮、偶尔会弹一个验证码弹窗。登录成功之后进到首页左侧菜单有个“订单管理”点进去之后可以查询订单列表点某一条订单能看到详情从详情页可以点击“审核通过”。就这一段流程传统做法从初始化脚本到跑通3 天还真的不夸张。为什么Vue 项目的 Button 经常没有固定的 id有时候是根据权限动态渲染的审核按钮在某种角色下还不显示。正常你写着写着就发现坑一个接一个。现在看我怎么用 AI 快速搞定它。3.2 第一步让 AI 看懂被测系统的页面结构这是整个流程里最容易被忽略但最关键的一步。很多人上来就甩给 AI 一句“帮我写个自动化脚本”AI 给出来的代码能不能跑完全靠运气因为模型根本不知道你的页面长什么样。正确姿势是把页面的骨架信息喂给它。操作很简单用浏览器打开目标页面按 F12把关键区域的 HTML 复制出来扔给大模型。如果担心数据敏感可以脱敏之后再扔但关键属性最好留着。如果是 Vue 项目我一般还会把渲染后的 DOM 拷一份因为源码里的模板跟实际 DOM 不一定完全一致。喂完之后让 AI 先输出一个“页面元素地图”就是它理解的输入框、按钮、下拉菜单都长什么样用什么定位策略最合适。这一步相当于给 AI 建立了对被测系统的认知后面生成的代码才不会瞎猜。提示这里我强烈建议用支持截图的模型。截图加 HTML 一起给AI 对页面布局的理解会准很多。比如截图能看到按钮在表单右下角AI 就会倾向于用相对位置来辅助定位比只凭 HTML 猜空间关系要稳。3.3 第二步让 AI 按 PageObject 模式生成框架代码页面结构搞清楚了第二步就是生成框架代码。我一般让 AI 直接生成完整的 PageObject 模式代码这样后续维护和扩展都比平铺直叙的脚本好得多。所谓的 PageObject说白了就是把一个页面封装成一个类页面上所有的元素定位和操作都写在类里测试用例只负责组织业务步骤。这样做的好处是页面改版的时候只需要改一个类而不是满世界找用例去改。提示词我是这么给的我现在要为一个订单管理系统写 Selenium 自动化脚本框架基于 pytest。 请帮我创建一个 BasePage 类包含 1. 统一的显式等待封装默认超时 10 秒支持重试。 2. 点击、输入、获取文本的通用方法每一步都自动记录日志。 3. 失败时自动截图保存到 reports 目录。 再创建一个 LoginPage 类继承 BasePage包含 1. 用户名输入框可以使用 placeholder 属性定位。 2. 密码输入框使用 typepassword 定位。 3. 登录按钮优先使用 button 的文本内容定位。 4. 登录成功后的跳转判断。 页面 HTML 如下脱敏 [粘贴 HTML]大模型会给出一整套代码包括 BasePage、LoginPage、测试用例文件。这个准确率比我预期的要高基本不用怎么改就能跑。核心就是你把 HTML 给它了它不是凭空瞎写而是基于真实的页面结构去组织定位符所以命中率很高。3.4 第三步动态元素的定位策略AI 给的方案比人还细这个环节我必须重点说说因为动态元素就是 Selenium 测试最大的敌人。以我那个订单管理页为例“审核通过”这两个按钮是后端根据用户权限渲染出来的登录账号不同按钮的 class 可能就不同有时候按钮 id 还带时间戳。传统做法下测试人员要去跟开发确认哪些属性是稳定的或者自己写一段很长的 XPath 碰运气。现在我把其中一个按钮的 HTML 丢给 AI让它找出所有稳定特征并给推荐定位符。AI 的做法通常很聪明它会优先看># 先按>我是一个 Selenium 测试用例执行失败。 用例目标点击订单的“审核通过”按钮。 失败现象元素无法定位超时 10 秒。 定位符原文//button[contains(class, btn-primary) and contains(data-action, audit)] 当前页面 HTML 关键片段 [贴上失败时的页面 HTML] 请分析 1. 失败的原因是什么 2. 产品是否真的出 bug 了 3. 如果是定位符问题请给出新的定位符并解释为什么新的定位符更稳定。 4. 如果产品真的出 bug 了请用一句话总结现象方便我提 bug 单。这一套跑起来之后我基本只需要每天早上花 15 分钟看一遍 AI 的修复建议批准或者微调剩下的就交给它。原来靠人工一条条排查的日子彻底结束了。4. 常见问题与排查技巧实录4.1 AI 生成的代码跑不起来多半是环境问题而不是 AI 不对用 AI 写 Selenium 脚本时最容易碰到的坑不是 AI 代码写得烂而是本地环境和 AI 预设的环境不一致。最典型的是 ChromeDriver 版本和 Chrome 浏览器版本对不上代码本身没毛病一跑就给你报个 session not created 的错。AI 写代码的时候默认你用的是最新稳定版浏览器但公司内网的机器很多是锁版本的说不定 Chrome 还停留在两年前的版本。所以我在框架里加了一个自动检测逻辑启动时先读取浏览器版本再自动匹配对应的 driver不匹配就直接报清晰的中文提示而不是甩一堆难懂的英文堆栈。另外一个环境坑是执行路径。AI 生成的代码里有不少相对路径比如./reports、../driver/chromedriver在本地 IDE 里跑没问题一上 CI 就全部失效。这是因为 CI 的工作目录跟本地不一样。我后来统一改成Path(__file__).resolve().parent来拼接绝对路径一套代码到处跑。4.2 滑块和图形验证码到底该不该用 Selenium 去破解顺带提一个出现频率极高的问题就是滑块验证码和图形拼图验证码。很多人一上来就想让 AI 帮自己写一套算法去绕过它什么计算缺口距离、模拟人工拖拽轨迹。我劝大家别在这个方向上花太多时间。从合规和成本角度来说验证码本身就是网站的一道安全防线绕过验证码的自动化不仅仅技术难度高还涉及平台规则和道德风险。你在自己公司的测试环境这么干开发同事可能还要找你聊天你拿别人的网站练手那问题更大。我的建议是走正规路子测试环境让开发配合加一个万能验证码或者关闭验证码开关再就是在 staging 环境做好白名单实在不行可以让 AI 辅助做验证码图案自动标注但最终点击和拖拽还是要配合图像识别服务。这里重点提醒一下别因为 AI 现在能通过“看图说话”帮你分析缺口位置就上头去搞绕过验证码的事有些红线尽量不碰。4.3 文件下载怎么知道真的下完再执行下一步下载文件是 Web 自动化里非常掉头发的场景。点击下载按钮之后Selenium 本身不会等你文件真正落盘你要是立刻去查文件是否存在大概率扑空。而且现在很多下载是大文件网速一慢等多久完全不可预期。AI 给过我一个非常妙的方案我后来一直在用先设置浏览器的下载路径到指定目录点击下载之后用轮询查目录里文件数量变化和文件大小是否稳定。如果文件大小在连续 5 秒内不再变化就认为下载完成。代码写出来大概是这样的import time from pathlib import Path def wait_for_download(download_dir, timeout30): download_path Path(download_dir) end_time time.time() timeout last_size -1 stable_count 0 while time.time() end_time: files list(download_path.glob(*)) if not files: time.sleep(1) continue current_size sum(f.stat().st_size for f in files if f.is_file()) if current_size last_size and current_size 0: stable_count 1 if stable_count 5: return [f for f in files if f.is_file()] else: stable_count 0 last_size current_size time.sleep(1) raise TimeoutError(下载超时)这套方案配合 AI 生成的截图确认逻辑下载场景基本可以做到无人值守。以前最怕的点现在反而是最省心的环节。4.4 网站识别出我是 Selenium怎么办有些网站的反爬能力很强你一启动 Selenium 就检测到navigator.webdriver属性为 true然后给你弹个验证页或者干脆不加载。以前大家会去改启动参数比如加--disable-blink-featuresAutomationControlled或者用 undetected-chromedriver 一类的库。我的看法是这个技术可以了解但同样要分清使用场景。在公司内部系统测试根本不存在这个问题如果是爬虫或不合规采集这里面的边界问题我不想碰。所以在这件事上我的建议异常简单确保你在合规的测试环境里跑自己的自动化用例不要拿 Selenium 去对抗陌生的线上服务。反检测方案本身会随着浏览器的更新不断失效维护成本非常高而且容易带来法律风险。从工程角度把核心精力放在测试覆盖和脚本稳定性上远比研究怎么“隐藏自己”有价值得多。4.5 AI 幻觉怎么破必须让人在环上兜底任何用过 AI 的人都知道幻觉这回事。在测试领域幻觉最可怕的表现是AI 很笃定地告诉你“这个元素定位符没问题你试试看”但你一试还是挂。或者更隐蔽它给出的断言逻辑看着合理实际却漏掉了关键业务规则。我的经验是两条线并行。第一重要脚本必须经过人工 reviewAI 可以出初稿但最终能不能上线跑人说了算。第二AI 的建议要跟自动化测试的执行结果形成闭环。它说“换个定位符就好”那你就真的跑一遍这个用例通过了才采纳而不是直接信它。慢慢地经过验证的 AI 建议会沉淀成一个可信的“修复缓存”后续类似的失败可以快速命中。我在框架里专门做了一个机制把每次 AI 修复的结果都记录下来包括当时的页面 HTML、模型建议、最终是否修复成功。跑一段时间之后这个数据库本身就是团队的宝贵资产新同事接手测试项目不用再到处问“这个元素以前怎么定位的”翻记录就行。4.6 小团队落地 AI 测试的几条实在建议如果你现在是想把小团队的测试体系接上 AI我建议别一下子就搞很重的基础设施。你先拿一个最头疼的模块做试点比如登录和订单查询用现有的 Selenium 框架往里接大模型 API把提示词调通把修复助手做出来让团队看到真实效果。一旦跑通了再把整套流程固化成文档纳入日常迭代。这个过程中有几个坑你要提前做好心理准备提示词不是一次性写好的要反复调大模型对 HTML 的上下文长度有限制页面太大就只截取关键片段公司网络如果访问外网 API 受限就部署内部的大模型服务或者用开源模型本地跑效果稍差但胜在安全可控。我真心建议大家不要迷信某一个 AI 工具是万能的工具始终是工具真正能带来长期价值的是你把它嵌入到测试工作流里的方式。AI 帮你写一千个脚本不如你自己搭好一个能让 AI 持续发挥作用的框架。最后再说一点这套 AI 加 Selenium 的组合我已经跑了快半年最大的变化不是测得更快而是我终于把那个天天守着页面看测试日志的自己拽了出来。以前最怕周一因为积压了一堆周末失败的用例等着修现在周一早上花一刻钟让 AI 先跑一遍诊断大部分问题它已经帮我筛好分类好了我只需要做判断题而不是填空题。如果你正被 Selenium 折磨你不用立刻全盘拥抱 AI可以先拿一个最烦的登录用例试一晚上让 AI 帮你生成脚本、帮你修一次定位符感受一下那种“原来这活真的可以不靠加班”的爽感。技术演进从来不是让你一夜之间丢掉旧工具而是让你用新工具把旧工具的最后一滴价值榨干。希望你也能早点睡个好觉。
先交代背景我干了八年测试开发其中五年都在跟 Selenium 打交道。这五年里我见过团队的人为了一个动态 id 死磕一整天见过凌晨两点还在群里问为什么昨天能跑的用例今天全红了也见过项目上线前把整个自动化套件临时砍掉一半因为实在修不过来。所以当 AI 这波浪潮砸过来的时候我最关心的就一件事Selenium 那些让人头秃的破事AI 到底能不能真的解决而不是又来一个花架子工具。今天这篇不聊虚的就把我最近总结出来的一套 AI Selenium 落地玩法摊开讲怎么把原本 3 天的回归测试工作量压缩到 15 分钟思路、选型、代码、踩坑全给你捋一遍。先说结论Selenium 本身没有做错什么折磨我们的从来不是工具而是“写脚本的人要去替浏览器思考”这件事占了太多时间。AI 的价值恰恰在于把你从那些机械、重复、需要反复试错的泥潭里捞出来。我这里说的 AI不是哪个公司的什么黑魔法就是现在大家都在用的多模态大模型加上代码生成能力配合一套合理的自动化测试框架让机器替你去生成定位策略、维护用例、分析失败原因。方向对了效率提升十倍真不是夸张。这篇文章适合谁看如果你正在用 Selenium 写 Web 自动化天天被元素定位、等待、维护困扰如果你是测试组长想给团队引入 AI 辅助测试但不知道从哪儿下手又或者你只是好奇 AI Agent 在测试领域到底能干什么那这篇内容基本就是给你准备的。全程没有晦涩的理论堆砌只有我实测过的方案和改过的代码按着做能直接落地。1. 先复盘Selenium 到底在哪些地方让人想摔键盘1.1 折磨点一元素定位像开盲盒Selenium 最基础的操作就是找元素但找元素这件事在真实项目里有多恶心只有真正经历过的人才知道。早期的项目还好id 规规矩矩name 也起得明明白白。现在的 Web 项目基本被前端框架统治了React、Vue 一上动态 id 满地跑比如input_8x2ak3这种带随机数的你这边刚写死那边一刷新就变了测试直接崩。更烦的是各种弹窗、iframe、shadow DOM 叠加在一起你明明在页面上肉眼看到了那个按钮Selenium 就是定位不到那种感觉就像你伸手去按电梯按钮手指直接穿过去了。我统计过自己团队的情况一个中型 Web 项目的自动化套件大概 600 条用例每周因为定位符失效而失败的用例平均有 40 到 60 条。每一条都要人去打开页面、翻代码、重新定位、改脚本、回归验证一条平均花 20 分钟到半小时。光这一项一周就烧掉整整两天的工时。这是 Selenium 折磨人的第一个大头不是脚本写不出来是脚本活不过两周。1.2 折磨点二等待策略成了团队玄学新手写 Selenium 最爱干的事就是time.sleep(5)无脑睡 5 秒。结果就是快的时候其实 2 秒就加载完了白等 3 秒慢的时候 5 秒还不够页面还在转圈脚本就傻乎乎地去找元素然后报错。有人改用隐式等待implicitly_wait(10)看起来聪明一点但隐式等待对元素存在性判断是通用的一旦遇到动态加载、异步请求的场景依然是杯水车薪。真正正确的做法是用显式等待配合WebDriverWait加各种expected_conditions但显式等待写多了之后每一个元素都要琢磨该等什么条件该设多少超时时间代码量直接翻倍。更诡异的是环境和环境之间的差异。测试环境明明点一下 2 秒就出结果CI 机器上跑偏偏要 6 秒。你在本地怎么调都通过上了 CI 就蹦出一排超时。这种问题没有银弹只能靠经验去指定策略。而 AI 最强的地方恰恰是它见过海量的项目代码你把它之前成功的等待策略喂给它它能给你生成一套比人写的还要稳健的等待逻辑。1.3 折磨点三用例维护的成本比开发还高测试圈有句话叫“自动化测试的维护成本高到让团队怀疑人生”一点都不夸张。一个典型的业务系统前端三天一小改、五天一大改。今天把登录按钮的 class 改了明天把下单流程的步骤从三步改成四步后天把某个文本框的动态 id 又换了。每一次改动自动化测试脚本都要跟着动。传统做法是测试人员打开 IDE搜索所有引用这个元素的代码一个一个去改定位表达式改完跑一遍看还有没有其他地方报错。这种机械、重复、毫无创造性的工作恰恰是 AI 最擅长处理的。我实测过把一个失败报告丢给大模型让它分析失败原因并给出新定位符准确率能做到七八成。剩下的两三成人工确认一下就好。这比从零去排查快得多我后面第 3 章会写具体的操作流程。1.4 折磨点四断言、数据和报告全是隐形成本大家一说 Selenium 只想到元素操作其实断言、测试数据和结果报告也是耗时大户。断言写得太粗页面上明显的错误提示都抓不到写得太细页面加载慢一点就误报。测试数据更是个坑注册过的用户名不能再用、订单状态必须符合前置要求每次跑用例之前都要串来串去地准备。最后的数据报告如果公司没搭现成的测试平台你还得手动把失败截图、日志、接口信息整理成表格发给开发。这一整套东西靠人肉去做3 天其实是非常保守的估算。真正复杂点的项目一个完整的冒烟加回归周期你有 5 天都不够用。那 AI 进来之后到底是怎么把这些环节逐一消化的这个放到第 2 章详细说。2. AI 辅助测试的核心思路与方案选型2.1 别指望 AI 替代 Selenium要让它替代你的重复劳动先说一个很多人容易搞错的方向。网上有不少人在讨论“AI 会不会取代 Selenium”“AI 来了还要不要学自动化测试”这都是把关系搞错了。Selenium 是一个真实可控的浏览器自动化协议和工具库它负责的是“执行”。AI 是什么AI 是“思考”。你让 AI 直接去操作浏览器现在的技术确实可以做到市面上也有 Agent 产品能看图点按钮但成本高、稳定性差、企业内网环境还不好部署。与其这样不如让 AI 去生成 Selenium 代码、诊断失败原因、维护用例逻辑再让 Selenium 去稳定执行。一个管脑力一个管体力各干各擅长的。这个思路的好处是你现有的测试框架、CI 流程、测试平台全部不用推翻AI 只是在脚本生成和维护环节插了一脚。改造风险极小团队接受度也高。我见过有人一上来就买一堆重平台最后发现 Selenium 脚本根本没法直接兼容结果推几个月推不下去纯属自己给自己挖坑。2.2 三种最实用的 AI 介入姿势我实测下来现阶段真正能落地并且出效果的基本是下面三种方式。第一种是 AI 写脚本。你描述业务操作流程比如“进入首页点击登录输入用户名密码点击提交断言跳转到个人中心”大模型直接给你生成完整的 Selenium 代码包括 import、等待、异常处理。这适合前期从 0 到 1 搭建自动化套件的时候效率堪比直接复印代码。第二种是 AI 辅助元素定位。把页面的 HTML 片段或者截图丢给多模态大模型让它帮你分析用哪些定位策略最稳。比如面对一个动态 idAI 会建议你用相对定位、XPath 轴定位或者 CSS 属性匹配。这招在处理动态元素时特别好使比我之前教的那些经验还要快。第三种是失败诊断与自动修复。用例跑挂了把报错信息、截图、录制到的页面状态丢给 AI让它判断是产品真的出 bug 了还是定位符失效了如果是后者直接给出替代方案。这个是我最常用的后面会特意展开写。2.3 工具选型我用的这套组合价格便宜还能落地现在市面上的 AI 工具眼花缭乱我用下来最顺手的组合是下面这套成本可控效果稳定适合绝大多数测试团队复刻。多模态大模型这一块日常用 GPT-4o、Claude 都行国内的话也可以用主流的大模型 API重点是要能识别截图和 HTML 文本。代码生成插件方面如果你还在 IDE 里写脚本GitHub Copilot 或者同类 AI 编程助手可以装上补全速度比人敲键盘快太多了。真正重头的其实是流程编排我建议大家先用现成的 AI Agent 工具来实验。你给它一个任务描述让它自己规划步骤、调用工具、产出结果。比如你告诉它“帮我看看这套测试为什么失败并修复它”它自己就会去提取日志、对比页面、生成新定位符。这里不硬性指定品牌只要是能调用浏览器工具或代码执行工具的都行。等流程跑通了再考虑用代码把 Agent 固化到自己的框架里。小团队的轻量做法是直接用 Python 调大模型 API把提示词封装成函数在自动化框架里留一个“AI 修复助手”的入口成本可能就一杯奶茶钱跑一个月。对你没看错按量计费下用不了多少钱。2.4 整体流程设计从 3 天到 15 分钟是怎么拆解的我把自己用下来的一套流程画在脑子里给你们描述一下你们感受下这个节奏。原来的 3 天工作量大概是这样的花半天梳理测试范围一天写脚本和调试定位符半天准备测试数据和断言逻辑最后一天跑用例、修问题、发报告。每一步都是人在动手AI 一点没参与三天时间就这么没了。现在的流程变成了第一步你花一个小时把核心业务路径用自然语言写清楚第二步AI 在几分钟之内给你生成初步脚本你跑一遍看个大概第三步针对跑不通的地方截图喂给 AI它直接给你修复方案第四步让 AI 补全边界条件的测试数据和断言第五步正式跑回归全程盯着日志有失败就让 AI 先诊断一轮你再确认。整个过程下来前期投入可能还是需要一个小时但后续每天的回归真的只需要 15 分钟左右。说白了AI 没有把测试工作完全清零它做的是把那些占大头的、可重复的、靠经验试错的 3 天压缩成一个小时的初始化加每天 15 分钟的机器辅助维护。3. 实操演示一个登录到下单的回归用例AI 怎么帮我跑完全程3.1 场景定义从一个常见的 B 端订单系统说起为了让你们有一个具体的感知我就拿一个极其典型的内网订单管理系统来做演示。这套系统的前端是 Vue后端是 Java登录页长这样一个用户名输入框、一个密码输入框、一个登录按钮、偶尔会弹一个验证码弹窗。登录成功之后进到首页左侧菜单有个“订单管理”点进去之后可以查询订单列表点某一条订单能看到详情从详情页可以点击“审核通过”。就这一段流程传统做法从初始化脚本到跑通3 天还真的不夸张。为什么Vue 项目的 Button 经常没有固定的 id有时候是根据权限动态渲染的审核按钮在某种角色下还不显示。正常你写着写着就发现坑一个接一个。现在看我怎么用 AI 快速搞定它。3.2 第一步让 AI 看懂被测系统的页面结构这是整个流程里最容易被忽略但最关键的一步。很多人上来就甩给 AI 一句“帮我写个自动化脚本”AI 给出来的代码能不能跑完全靠运气因为模型根本不知道你的页面长什么样。正确姿势是把页面的骨架信息喂给它。操作很简单用浏览器打开目标页面按 F12把关键区域的 HTML 复制出来扔给大模型。如果担心数据敏感可以脱敏之后再扔但关键属性最好留着。如果是 Vue 项目我一般还会把渲染后的 DOM 拷一份因为源码里的模板跟实际 DOM 不一定完全一致。喂完之后让 AI 先输出一个“页面元素地图”就是它理解的输入框、按钮、下拉菜单都长什么样用什么定位策略最合适。这一步相当于给 AI 建立了对被测系统的认知后面生成的代码才不会瞎猜。提示这里我强烈建议用支持截图的模型。截图加 HTML 一起给AI 对页面布局的理解会准很多。比如截图能看到按钮在表单右下角AI 就会倾向于用相对位置来辅助定位比只凭 HTML 猜空间关系要稳。3.3 第二步让 AI 按 PageObject 模式生成框架代码页面结构搞清楚了第二步就是生成框架代码。我一般让 AI 直接生成完整的 PageObject 模式代码这样后续维护和扩展都比平铺直叙的脚本好得多。所谓的 PageObject说白了就是把一个页面封装成一个类页面上所有的元素定位和操作都写在类里测试用例只负责组织业务步骤。这样做的好处是页面改版的时候只需要改一个类而不是满世界找用例去改。提示词我是这么给的我现在要为一个订单管理系统写 Selenium 自动化脚本框架基于 pytest。 请帮我创建一个 BasePage 类包含 1. 统一的显式等待封装默认超时 10 秒支持重试。 2. 点击、输入、获取文本的通用方法每一步都自动记录日志。 3. 失败时自动截图保存到 reports 目录。 再创建一个 LoginPage 类继承 BasePage包含 1. 用户名输入框可以使用 placeholder 属性定位。 2. 密码输入框使用 typepassword 定位。 3. 登录按钮优先使用 button 的文本内容定位。 4. 登录成功后的跳转判断。 页面 HTML 如下脱敏 [粘贴 HTML]大模型会给出一整套代码包括 BasePage、LoginPage、测试用例文件。这个准确率比我预期的要高基本不用怎么改就能跑。核心就是你把 HTML 给它了它不是凭空瞎写而是基于真实的页面结构去组织定位符所以命中率很高。3.4 第三步动态元素的定位策略AI 给的方案比人还细这个环节我必须重点说说因为动态元素就是 Selenium 测试最大的敌人。以我那个订单管理页为例“审核通过”这两个按钮是后端根据用户权限渲染出来的登录账号不同按钮的 class 可能就不同有时候按钮 id 还带时间戳。传统做法下测试人员要去跟开发确认哪些属性是稳定的或者自己写一段很长的 XPath 碰运气。现在我把其中一个按钮的 HTML 丢给 AI让它找出所有稳定特征并给推荐定位符。AI 的做法通常很聪明它会优先看># 先按>我是一个 Selenium 测试用例执行失败。 用例目标点击订单的“审核通过”按钮。 失败现象元素无法定位超时 10 秒。 定位符原文//button[contains(class, btn-primary) and contains(data-action, audit)] 当前页面 HTML 关键片段 [贴上失败时的页面 HTML] 请分析 1. 失败的原因是什么 2. 产品是否真的出 bug 了 3. 如果是定位符问题请给出新的定位符并解释为什么新的定位符更稳定。 4. 如果产品真的出 bug 了请用一句话总结现象方便我提 bug 单。这一套跑起来之后我基本只需要每天早上花 15 分钟看一遍 AI 的修复建议批准或者微调剩下的就交给它。原来靠人工一条条排查的日子彻底结束了。4. 常见问题与排查技巧实录4.1 AI 生成的代码跑不起来多半是环境问题而不是 AI 不对用 AI 写 Selenium 脚本时最容易碰到的坑不是 AI 代码写得烂而是本地环境和 AI 预设的环境不一致。最典型的是 ChromeDriver 版本和 Chrome 浏览器版本对不上代码本身没毛病一跑就给你报个 session not created 的错。AI 写代码的时候默认你用的是最新稳定版浏览器但公司内网的机器很多是锁版本的说不定 Chrome 还停留在两年前的版本。所以我在框架里加了一个自动检测逻辑启动时先读取浏览器版本再自动匹配对应的 driver不匹配就直接报清晰的中文提示而不是甩一堆难懂的英文堆栈。另外一个环境坑是执行路径。AI 生成的代码里有不少相对路径比如./reports、../driver/chromedriver在本地 IDE 里跑没问题一上 CI 就全部失效。这是因为 CI 的工作目录跟本地不一样。我后来统一改成Path(__file__).resolve().parent来拼接绝对路径一套代码到处跑。4.2 滑块和图形验证码到底该不该用 Selenium 去破解顺带提一个出现频率极高的问题就是滑块验证码和图形拼图验证码。很多人一上来就想让 AI 帮自己写一套算法去绕过它什么计算缺口距离、模拟人工拖拽轨迹。我劝大家别在这个方向上花太多时间。从合规和成本角度来说验证码本身就是网站的一道安全防线绕过验证码的自动化不仅仅技术难度高还涉及平台规则和道德风险。你在自己公司的测试环境这么干开发同事可能还要找你聊天你拿别人的网站练手那问题更大。我的建议是走正规路子测试环境让开发配合加一个万能验证码或者关闭验证码开关再就是在 staging 环境做好白名单实在不行可以让 AI 辅助做验证码图案自动标注但最终点击和拖拽还是要配合图像识别服务。这里重点提醒一下别因为 AI 现在能通过“看图说话”帮你分析缺口位置就上头去搞绕过验证码的事有些红线尽量不碰。4.3 文件下载怎么知道真的下完再执行下一步下载文件是 Web 自动化里非常掉头发的场景。点击下载按钮之后Selenium 本身不会等你文件真正落盘你要是立刻去查文件是否存在大概率扑空。而且现在很多下载是大文件网速一慢等多久完全不可预期。AI 给过我一个非常妙的方案我后来一直在用先设置浏览器的下载路径到指定目录点击下载之后用轮询查目录里文件数量变化和文件大小是否稳定。如果文件大小在连续 5 秒内不再变化就认为下载完成。代码写出来大概是这样的import time from pathlib import Path def wait_for_download(download_dir, timeout30): download_path Path(download_dir) end_time time.time() timeout last_size -1 stable_count 0 while time.time() end_time: files list(download_path.glob(*)) if not files: time.sleep(1) continue current_size sum(f.stat().st_size for f in files if f.is_file()) if current_size last_size and current_size 0: stable_count 1 if stable_count 5: return [f for f in files if f.is_file()] else: stable_count 0 last_size current_size time.sleep(1) raise TimeoutError(下载超时)这套方案配合 AI 生成的截图确认逻辑下载场景基本可以做到无人值守。以前最怕的点现在反而是最省心的环节。4.4 网站识别出我是 Selenium怎么办有些网站的反爬能力很强你一启动 Selenium 就检测到navigator.webdriver属性为 true然后给你弹个验证页或者干脆不加载。以前大家会去改启动参数比如加--disable-blink-featuresAutomationControlled或者用 undetected-chromedriver 一类的库。我的看法是这个技术可以了解但同样要分清使用场景。在公司内部系统测试根本不存在这个问题如果是爬虫或不合规采集这里面的边界问题我不想碰。所以在这件事上我的建议异常简单确保你在合规的测试环境里跑自己的自动化用例不要拿 Selenium 去对抗陌生的线上服务。反检测方案本身会随着浏览器的更新不断失效维护成本非常高而且容易带来法律风险。从工程角度把核心精力放在测试覆盖和脚本稳定性上远比研究怎么“隐藏自己”有价值得多。4.5 AI 幻觉怎么破必须让人在环上兜底任何用过 AI 的人都知道幻觉这回事。在测试领域幻觉最可怕的表现是AI 很笃定地告诉你“这个元素定位符没问题你试试看”但你一试还是挂。或者更隐蔽它给出的断言逻辑看着合理实际却漏掉了关键业务规则。我的经验是两条线并行。第一重要脚本必须经过人工 reviewAI 可以出初稿但最终能不能上线跑人说了算。第二AI 的建议要跟自动化测试的执行结果形成闭环。它说“换个定位符就好”那你就真的跑一遍这个用例通过了才采纳而不是直接信它。慢慢地经过验证的 AI 建议会沉淀成一个可信的“修复缓存”后续类似的失败可以快速命中。我在框架里专门做了一个机制把每次 AI 修复的结果都记录下来包括当时的页面 HTML、模型建议、最终是否修复成功。跑一段时间之后这个数据库本身就是团队的宝贵资产新同事接手测试项目不用再到处问“这个元素以前怎么定位的”翻记录就行。4.6 小团队落地 AI 测试的几条实在建议如果你现在是想把小团队的测试体系接上 AI我建议别一下子就搞很重的基础设施。你先拿一个最头疼的模块做试点比如登录和订单查询用现有的 Selenium 框架往里接大模型 API把提示词调通把修复助手做出来让团队看到真实效果。一旦跑通了再把整套流程固化成文档纳入日常迭代。这个过程中有几个坑你要提前做好心理准备提示词不是一次性写好的要反复调大模型对 HTML 的上下文长度有限制页面太大就只截取关键片段公司网络如果访问外网 API 受限就部署内部的大模型服务或者用开源模型本地跑效果稍差但胜在安全可控。我真心建议大家不要迷信某一个 AI 工具是万能的工具始终是工具真正能带来长期价值的是你把它嵌入到测试工作流里的方式。AI 帮你写一千个脚本不如你自己搭好一个能让 AI 持续发挥作用的框架。最后再说一点这套 AI 加 Selenium 的组合我已经跑了快半年最大的变化不是测得更快而是我终于把那个天天守着页面看测试日志的自己拽了出来。以前最怕周一因为积压了一堆周末失败的用例等着修现在周一早上花一刻钟让 AI 先跑一遍诊断大部分问题它已经帮我筛好分类好了我只需要做判断题而不是填空题。如果你正被 Selenium 折磨你不用立刻全盘拥抱 AI可以先拿一个最烦的登录用例试一晚上让 AI 帮你生成脚本、帮你修一次定位符感受一下那种“原来这活真的可以不靠加班”的爽感。技术演进从来不是让你一夜之间丢掉旧工具而是让你用新工具把旧工具的最后一滴价值榨干。希望你也能早点睡个好觉。
