你有没有算过自己一天里有多少时间花在写 Selenium 脚本上我算过——定位元素、试等待时间、跑一遍报错、再改……一个中等复杂度的自动化脚本从零到能稳定跑大半天就没了。后来我换了个思路让 AI 先写我只管提需求和验收结果一个脚本从半天压缩到十几分钟有些简单的甚至一杯水没喝完就能跑。这篇实战教程就是记录我怎么用 AI 在 1 分钟里生成 Selenium 自动化脚本以及那些 AI 生成脚本后不能直接跑、需要人工兜底的坑。不管你是刚接触自动化测试还是已经写了几年脚本想提效这套方法都能直接上手。我见过不少测试同学看到 AI 写代码的第一反应是AI 写的能信吗或者说这玩意儿是不是要把我们饭碗端了。我的答案是都不对。AI 写 Selenium 脚本这件事本质是把可复用的模式化代码交给大模型把人从重复劳动里解放出来去思考真正需要业务判断的测试场景。下面我把完整流程拆开讲。1. 为什么我最后决定让 AI 来写 Selenium 脚本1.1 手工写脚本的真实困境时间都花在了猜上先说一个很现实的场景。上周我要给一个后台管理系统写回归脚本需求本身不复杂登录、进列表页、按条件筛选、点开一条详情、把关键字段带回来。听起来 30 分钟能搞定吧结果我花了整整一个下午。原因就三个字定位器。页面是前端框架动态渲染的class 名称一会儿带随机后缀一会儿整个结构嵌套五层。我在 DevTools 里翻来翻去看试了 XPath、CSS Selector好不容易定位到点击后页面又弹了个 toast把下面的按钮挡住了。于是再调等待、再加滚动。等到脚本真正跑通晚饭时间都过了。这不是个例。测试群里每天都有同事在问这个元素为什么定位不到“加了 sleep 还是偶发失败”。说白了手工写 Selenium 脚本的大部分时间消耗在元素定位、等待策略、浏览器兼容这些模式化问题上而不是测试逻辑本身。1.2 Selenium 脚本为什么正好是 AI 的舒适区后来我开始尝试让大模型写代码一开始写的是算法题、爬虫脚本质量参差不齐。直到某天我突发奇想把一个 Selenium 需求丢给它结果让我吃了一惊生成的代码结构完整等待条件、异常处理、退出逻辑全都齐了几乎可以直接跑。事后我琢磨了一下Selenium 脚本是天然的 AI 友好场景。第一它是高度模式化的打开浏览器、定位元素、执行操作、等待结果、断言翻来覆去就那么几套 API第二互联网上有海量的真实示例和 Stack Overflow 问答AI 在训练阶段见得太多了第三业务逻辑和代码骨架可以完全解耦——我只需要把登录、点这个按钮、断言出现那行字讲清楚AI 就能把它翻译成标准 Selenium 代码。换句话说AI 不擅长的是模糊的创意性任务但把明确需求翻译成标准代码这种事它比大多数人类都快。1.3 它的价值不是替代你而是把工作重心挪到需求我现在的状态是自己是测试负责人也是团队里写脚本最多的那个人。用 AI 之后我的角色从写代码的人变成了提需求的人和验收代码的人。这个转变很重要。以前同事提需求我要先把需求翻译成技术实现再写代码去匹配网站结构现在我可以把需求直接丢给 AI它产出初稿我根据自己的业务理解去修改和验证。同样的时间我覆盖的测试场景至少翻了一倍。尤其是在版本迭代快、页面频繁改动的项目里以前最怕改一个小按钮就牵连一堆脚本现在改起来快多了把新页面的 HTML 片段贴给 AI让它更新定位器几分钟就完事。所以这套玩法适合谁正在学自动化测试的人可以通过 AI 生成的代码看到标准写法已经在写脚本但觉得维护成本高的人可以让 AI 帮你从 CRUD 中解放出来测试负责人想提效也可以把提示词模板沉淀成团队资产。下面具体讲怎么落地。2. 动手前的准备工具选型与提示词设计2.1 模型怎么选别纠结先用熟一个我试过 ChatGPT、Claude也用过国产的通义千问和 Kimi结论是写 Selenium 这种模式化代码主流大模型之间差距没有想象中那么大。真正影响产出质量的是你给它的上下文和约束条件。如果你问我具体选哪个我的建议是手边哪个用着顺手就用哪个。我自己的习惯是日常快速生成用 ChatGPT复杂一点的逻辑让 Claude 补一版两者互相验证。有人可能觉得还要搭插件、接 API 很麻烦其实完全不需要。一个网页版对话窗口加上一个能跑 Python 的本地环境就够了。当然有一点要注意AI 的训练数据有滞后性Selenium 4.x 的新特性它偶尔会记混。碰到不确定的 API让它给出版本说明或者直接看官方文档别盲信。2.2 环境三件套Python、Selenium、浏览器驱动在让 AI 写脚本之前先把本地环境跑通。三样东西必备Python 3.8 以上装好 pipSelenium 库命令很简单pip install selenium浏览器驱动这里有个省心方案Selenium 4.6 以上版本自带 Selenium Manager会自动帮你下载和匹配 ChromeDriver基本不用手动管版本我以前最怕的就是驱动版本不匹配报错提示ChromeDriver only supports Chrome version xxx每次都懵。现在新版本自动管理驱动这个坑少多了。如果团队统一用的是 Chrome我会建议本地和 CI 环境尽量保持浏览器版本一致避免脚本在这边跑得好好的到 CI 上就挂。2.3 提示词模板四要素缺一不可很多人让 AI 写脚本就扔一句话帮我写个登录脚本。然后 AI 生成一个通用登录跟你项目完全不搭。这真不怪 AI是你没给它足够的决策信息。我试过几十种写法之后总结出一套稳定好用的提示词结构四要素角色设定告诉它你是资深测试开发工程师输出专业级代码业务需求目标是哪个 URL要做什么操作预期结果是什么技术约束用显式等待不要用 sleep定位优先用稳定的属性加异常处理和注释附加信息账号密码、关键按钮的文字、页面特殊结构我现在的常用模板长这样你是一名资深测试开发工程师请用 Python Selenium 编写自动化测试脚本实现以下需求 1. 打开 URLhttps://www.saucedemo.com/ 2. 输入用户名 standard_user密码 secret_sauce 3. 点击登录按钮 4. 断言登录后页面标题显示 Products 要求 - 使用 WebDriverWait 显式等待不要使用硬编码 sleep - 元素定位优先使用稳定的 ID 或 CSS 选择器 - 添加必要的注释和异常处理 - 输出完整可直接运行的代码包含浏览器退出逻辑你看把约束写在里面AI 生成出来的代码质量立刻提升一个档次。尤其是显式等待和不要用 sleep这两条直接决定脚本跑起来稳不稳。如果你还没有自己的模板先把我这个改吧改吧用起来后面再根据自己的项目沉淀。3. 实战练习从登录到数据提取的完整脚本生成3.1 第一步让 AI 生成登录脚本拿上面的提示词举例AI 给我的第一版代码大概长这样from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC driver webdriver.Chrome() try: driver.get(https://www.saucedemo.com/) wait WebDriverWait(driver, 10) wait.until(EC.presence_of_element_located((By.ID, user-name))).send_keys(standard_user) driver.find_element(By.ID, password).send_keys(secret_sauce) driver.find_element(By.ID, login-button).click() wait.until(EC.visibility_of_element_located((By.CLASS_NAME, title))) assert driver.find_element(By.CLASS_NAME, title).text Products print(登录成功页面标题验证通过) finally: driver.quit()这段代码在 saucedemo.com 这个公开练习站上是可以直接跑通的。注意几个细节等待条件用的是presence_of_element_located输入框用 ID 定位按钮用 ID 定位断言页面标题。这里没有一行 sleep全靠显式等待撑住节奏稳定性比我手写时代强不少。3.2 第二步追加需求生成数据提取和滚动翻页逻辑第一步只是热身实战中更常见的是登录之后我还要干活。这时候不需要重新让 AI 写一整套而是直接追问让它基于现有代码继续扩展。我继续输入在上面的脚本基础上增加登录后提取商品列表中前 5 个商品的名称并控制页面向下滚动 500 像素模拟用户加载更多内容。 AI 给出的增量代码items driver.find_elements(By.CLASS_NAME, inventory_item) for i, item in enumerate(items[:5], 1): name item.find_element(By.CLASS_NAME, inventory_item_name).text print(f{i}. {name}) driver.execute_script(window.scrollBy(0, 500))看到没滚动直接用execute_script调用 JavaScript比盲目按 End 键或者反复滑动滚轮稳定得多。如果网站上真的有下一页按钮我会继续追问把这段逻辑封装成循环点击下一页直到按钮不可用为止。 AI 给出的骨架通常是while True: # 提取当前页数据 # 判断下一页按钮是否可点击 next_btn driver.find_element(By.CSS_SELECTOR, button.next-page) if not next_btn.is_enabled(): break next_btn.click() wait.until(EC.staleness_of(previous_item_list))这个骨架的思路是对的但实际落地要注意判断下一页到底有没有不能只看按钮是否 disabled有些网站是把按钮藏起来了或者直接移除。所以我会把具体网站的 HTML 片段给 AI让它根据实际情况写判断条件。这一步非常关键很多人就是栽在想当然的下一页上。3.3 为什么1 分钟是可能的把需求拆小块对话式推进说回标题里1 分钟这件事。严格讲从打开对话框到脚本全部跑通1 分钟不太现实除非脚本简单到只有一个登录。我说的一分钟指的是 AI 生成一份可用初稿通常只要 10 到 30 秒加上你复制粘贴和运行验证一个简单脚本确实能在 1 分钟内出初稿。想要做到这一点核心心法就是别把复杂需求一次性全丢给 AI而是拆成小块像聊天一样逐步推进。先让它生成登录骨架确认没问题再让它加数据提取再加翻页逻辑再加断言和报告。每一轮它只需要改一小块出错的概率大大降低你验证的速度也快。这比一上来丢给 AI 一个帮我写一套完整的电商自动化框架要靠谱得多——后者光上下文就够它蒙圈了。在我实际项目中一个包含登录、筛选、数据提取、翻页的脚本从第一次提问到可以在 staging 环境跑起来通常控制在 15 到 20 分钟。对比以前半天起步说效率翻倍已经算保守了。4. AI 生成的脚本不是拿来就能跑复盘我踩过的坑4.1 坑一AI 爱用老旧的定位写法第一次用 AI 生成脚本我兴冲冲地复制进编辑器结果一运行一堆红色报错。仔细一看代码里全是这种driver.find_element_by_xpath(//*[iduser-name])这在 Selenium 4.x 里已经被废弃了新版本要求统一用By指定定位方式driver.find_element(By.XPATH, //*[iduser-name])原因是 AI 的训练数据里混了一些旧教程它并不知道你本地的 Selenium 版本具体是第几代。解决办法很简单在提示词里加一条使用 Selenium 4 语法所有定位都用 By.XXX 方式基本就能避开。也可以跑一次报错后把错误信息贴回给 AI它自己会改过来。4.2 坑二等待全用 sleep脚本慢还容易抽风如果提示词里不限制等待方式AI 大概率给你生成一堆time.sleep(2)。脚本倒是能跑问题有两个一是慢5 个页面切下来光等待就 20 秒二是不稳网络稍微卡一下2 秒不够用元素没加载出来点击就报错网络好时2 秒又纯属浪费。这种脚本我是绝对不敢拿去做回归的。修复办法就是所有元素操作前都用显式等待# 不推荐无脑等固定时间 time.sleep(5) driver.find_element(By.CSS_SELECTOR, button.continue).click() # 推荐等元素处于可点击状态再操作 wait.until(EC.element_to_be_clickable((By.CSS_SELECTOR, button.continue))).click()这个坑我踩过不下三次所以现在提示词模板里固定写死不要使用硬编码 sleep。4.3 坑三XPath 写死页面一改就崩AI 特别喜欢生成一些看似精准、实则脆弱的绝对路径比如driver.find_element(By.XPATH, /html/body/div[1]/div/div[2]/form/div[1]/input)这种路径在你本地运行的那一刻可能是对的但前端稍微改个节点顺序或者加一层 shell脚本立刻当场死亡。更靠谱的定位方式是优先使用 ID、name、稳定的 class或者通过可见文本定位driver.find_element(By.XPATH, //button[contains(text(),立即登录)])我在让 AI 写脚本时会明确补一句定位元素时优先使用 ID 和稳定的 CSS 类名禁止使用从 html/body 开始的绝对 XPath。生成出来的代码耐用程度会高很多。4.4 坑四浏览器驱动版本不匹配的无效劳动有一阵子我的脚本在本地跑得好好的一放到 CI 上就报错报错信息长这样This version of ChromeDriver only supports Chrome version 114。我一查CI 镜像里的 Chrome 已经升到 116而 chromedriver 还是旧的。以前我都是手动下载对应版本后来发现完全没必要。Selenium 4.6 以上的 Selenium Manager 会自动处理驱动和浏览器版本的匹配只要你用的是新版 selenium并且环境能联网基本不用操心。AI 生成的代码默认是webdriver.Chrome()这个写法在本地通常没问题如果你用的是 Firefox 或者 Edge记得在提示词里说明它会改用对应驱动。AI 默认的浏览器偏好是 Chrome这点容易让团队里用 Edge 的同学踩坑。4.5 调试闭环把报错信息原样扔回给 AI我见过很多人拿到 AI 生成的代码跑挂了就自己撸起袖子一行行调试那跟 AI 出现之前有什么区别呢我的习惯是先把报错信息完整复制下来原封不动贴给 AI让它解释原因并给出修复版。举个实际例子。有一次脚本运行到一半报ElementClickInterceptedException: element click interceptedAI 秒回这个元素被另一个元素挡住了多半是有弹窗或者加载遮罩建议先关闭弹窗或等待遮罩消失然后给了对应代码。我自己去排查的话至少要打开 DevTools 确认定位器和层级关系十分钟起步。把报错丢给 AI它基于大量经验库能快速定位同类问题虽然偶尔也会给错方案但至少能帮你缩小范围。有效的调试闭环是跑脚本 → 贴报错 → 让 AI 修 → 再跑循环几轮脚本就稳定了。这个过程里你自己对业务的理解才是判断 AI 改得对不对的锚点。4.6 要主动避开的坑验证码和滑块不是 AI 该碰的还有一类需求AI 能写但我建议你别让它写——自动绕过验证码、自动破滑块。这类脚本在法律和平台规则上都有风险而且技术实现非常依赖具体网站的防护策略今天写完明天就失效。我的做法是明确告诉 AI我不需要自动处理验证码脚本跑到验证码处暂停由人工介入。这样既合规又不会被 AI 带偏到危险的实现上。记住AI 是工具工具的使用边界在自己手里。5. 让效率翻倍的第二阶段把 AI 用成测试搭档5.1 用 AI 维护老脚本页面改版时它比你先看到问题自动化测试最烦的是维护成本。新版本一上线原本定位得好好的按钮换了文案class 名也变了脚本报错一大片。以前这种时候我要逐个元素改现在直接把报错的元素和新的 HTML 片段贴给 AI它很快就给出新的定位器。这里有个小技巧贴 HTML 前先删掉动态生成的属性比如一次性 token、随机 ID否则会让 AI 以为这些动态属性是稳定特征生成出来的定位器照样脆弱。我会保留固定的 class、data-test 属性、可见文本等关键信息让 AI 基于这些来写。实测下来页面改版后的脚本恢复速度比以前快了 5 倍不止。5.2 用 AI 生成测试数据和断言逻辑别浪费它的大局观除了写 Selenium 操作本身AI 还能帮我把测试脚本的周边补全。我经常让它生成符合规则的随机测试数据比如手机号、邮箱、地址只要明确格式要求它生成的假数据比手工造的快很多而且不会重复。断言逻辑也一样我告诉它这个页面的订单金额应该等于商品总价减去优惠券再加快递费它能直接给出精确到小数位的断言表达式。最让我觉得它像搭档的是它能把整个测试脚本组织成 Page Object 模式。以前我写 Page Object 总觉得麻烦能省则省现在让 AI 生成一版代码结构清晰每个页面一个类定位器集中管理后边谁接手这个脚本都不至于骂人。比如它生成的LoginPage是这样的class LoginPage: def __init__(self, driver): self.driver driver self.wait WebDriverWait(driver, 10) def login(self, username, password): self.wait.until(EC.presence_of_element_located((By.ID, user-name))).send_keys(username) self.driver.find_element(By.ID, password).send_keys(password) self.driver.find_element(By.ID, login-button).click() return InventoryPage(self.driver)你看登录成功后直接返回下一个页面对象链路清晰复用性也好。AI 对设计模式的理解用在 Selenium 脚本上绰绰有余。5.3 AI Agent 与多 AI 协作我最近在尝试的新玩法最近不少同事开始折腾 AI Agent让一个智能体自动完成读需求 → 写代码 → 跑用例 → 读报错 → 修代码的闭环。我也试过效果比我手动对话更激进你只需要给出需求和验收标准Agent 自己会去读项目文件、改代码、跑测试然后把结果汇报给你。有点像一个自动写脚本的小实习生但方向对不对还是需要你把控。我还有一个习惯性玩法让一个模型生成完脚本换另一个模型做 Code Review。ChatGPT 生成Claude 来审查审查意见往往能发现一些我在代码里忽略的边界情况——比如某个元素在列表为空时根本不存在或者等待条件选得不够严格。多模型交叉验证这个方法比单模型一条路走到黑靠谱很多。唯一的代价是你要多复制粘贴几轮但比起脚本上线后半夜报警这点成本完全可以接受。5.4 边界在哪里AI 不懂你的业务流程断言还得自己拍板我必须泼一盆冷水AI 再怎么强它不知道你们公司的业务规则。比如登录失败时我们要求页面必须展示账号或密码错误这个文案且 3 秒内出现AI 只会按常识生成一个通用断言它不会知道你什么时候该断言、断言的精度要到什么程度。这些业务细节只能由熟悉系统的人给出。我的实践经验是让 AI 处理代码结构、元素定位、异常处理这些工程问题但测试用例的设计、业务断言的判定、优先级的排列这些业务问题一定要自己把关。如果你完全不理解脚本里的每一行在做什么那 AI 一旦生成错误逻辑你根本没有能力发现它。这也是为什么我一直强调用 AI 提效的前提是你本身得具备读代码、查报错、理解测试逻辑的基本功。6. 写在最后我的实际体会与建议用 AI 写 Selenium 脚本这件事真正改变我的不是写代码这个动作而是工作流程我更像一个测试场景的设计师AI 是我的实现执行者。它负责把明确的指令翻译成可靠的自动化代码我负责判断这些代码是不是真的覆盖了核心业务逻辑。二者结合效率才会真的翻倍。给准备上手的你三条建议。第一从最小的脚本开始试水别一上来就让它生成整套框架先让它帮你写一个登录跑通了再让它扩展翻页和数据提取一步一步建立信任。第二把好用的提示词沉淀成团队模板一个人试出来的经验全团队都能直接受益。第三永远保持对代码的掌控力AI 生成的代码你要能看懂、能改、能解释这意味着它是个好工具而不是黑盒保险箱。最后分享一个小技巧把常用的提示词片段存在一个笔记里比如显式等待模板Page Object 生成模板报错修复模板遇到项目直接复制替换关键信息。我靠这个方法从打开对话框到脚本初稿出来经常真的能在一分钟内完成——别人还在翻 DevTools 的时候你已经在跑验证了。试试看你会发现回不去的。