上周有个同事在群里吐槽说一个登录加搜索的 Selenium 自动化脚本写了一下午定位元素、调等待、处理弹窗一整套下来头晕眼花。我回了一句这种活我现在五分钟搞定其中 AI 生成脚本只用一分钟剩下四分钟在验证它写得对不对。这不是凡尔赛用 AI 写 Selenium 自动化脚本这件事已经是我日常测试工作里的常规操作了。这篇文章不聊虚的直接把“怎么让 AI 帮你写出能跑的 Selenium 脚本”这条路走一遍。适合谁正在做自动化测试但脚本写得慢的测试工程师想用 AI 提效但不知道从哪下手的开发以及刚接触 Selenium 的初学者。你会看到完整的 Prompt 写法、AI 生成的脚本长什么样、怎么让它按你的要求改以及几个我在实际跑脚本时踩过的坑。看完你也能做到一分钟拿初稿半小时内落地。1. 为什么我现在习惯让 AI 写 Selenium 脚本而不是自己敲1.1 从手写脚本到 AI 辅助到底省了什么先说个扎心事实Selenium 脚本本身不难难的是那些“意料之外”的事。元素定位偶尔抽风、页面加载快慢不一、弹窗时机飘忽甚至有时候环境变了脚本就黄。早期我手写脚本大部分时间不是在写业务逻辑而是在跟这些问题搏斗。一个简单的场景打开页面、输入用户名密码、点击登录、断言进入首页看起来十分钟能写完但真跑一遍各种报错改来改去一上午就没了。AI 介入之后这个过程的效率曲线变化很明显。它最擅长的事情就是把“别人写过的套路”组合起来。Selenium 作为全世界用得最多的 Web 自动化工具面试题、博客、开源项目里积累了海量代码片段大模型看得够多只要你用自然语言描述清楚场景它生成的代码在“能跑”这个层面通常没什么问题。你要做的就是给它一个清晰的需求然后把精力留在审核和调优上。这中间的思维转换很关键以前是“我该怎么写这段代码”现在是“我该怎么把需求说清楚”。需求描述越精准脚本越接近可用状态。一句话概括就是AI 帮你把“从零到一”的枯躁工作做完了你专注“从一到十”的打磨。1.2 环境准备装好这几样就能开工在动手让 AI 写脚本之前先把本地环境弄利索。别小看这一步很多人卡在“AI 生成的脚本跑不起来”其实是因为环境少装了东西。我的建议清单如下Python 3.8 以上版本装好之后命令行输入python --version能正常输出版本号。Selenium 库安装命令是pip install selenium。pytest后面用 fixture 管理浏览器生命周期安装命令pip install pytest。webdriver-manager这个强烈推荐它能自动下载和匹配浏览器驱动不用你手动折腾 ChromeDriver 版本pip install webdriver-manager即可。一个可用的 Chrome 浏览器以及一个能联网的对话大模型工具具体用哪家无所谓市面上主流的大模型都能胜任关键是你的提问方式。这套环境基本是标配装完之后你可以先手动跑一个最简单脚本确认浏览器能正常启动并访问页面再开始用 AI 生成脚本。如果连“打开浏览器”都做不到后边写什么都是白搭。实测下来webdriver-manager 是最省心的选择以前手动配 ChromeDriver 的时候浏览器一升级脚本就挂现在这个坑基本不存在了。2. 写 Prompt 的核心套路角色、场景、约束三层定死让 AI 一次生成可用脚本2.1 第一层角色与任务别让 AI 猜你的意图很多人让 AI 写代码上来就是一句“帮我写一个登录脚本”结果 AI 给出一份看着像回事、实际跟你的业务场景完全不搭的代码。原因很简单你没说清楚你是谁、要干嘛、在什么条件下干活。AI 不是读心术它只会按字面意思去组合最常见的方案。我习惯用三段式来给 AI 布置任务。第一段是角色设定先告诉它“你是一名精通 Selenium 和 pytest 的测试开发工程师”。角色定下来它输出代码的口吻和用到的库就自然对齐了。第二段是任务描述必须具体到今天要测哪个网站、什么流程、断言什么结果。第三段是格式要求告诉它用什么语言、什么框架、代码要完整可直接运行。给个直观对比。“帮我在网站上测试登录功能”这种描述AI 大概率给你一个打开 Google 或者随便一个示例站的脚本没法直接用在你的项目上。而“请用 Python Selenium 测试这个网址的登录流程输入指定账号密码验证登录后是否跳转到商品列表页”这种描述AI 就能精确命中你的目标。任务描述里把 URL、账号密码、预期结果给全AI 不需要猜输出就靠谱得多。2.2 第二层业务场景与验收标准告诉 AI 什么算“成功”任务描述里最容易被忽略、也最关键的是验收标准。你要明确告诉 AI“怎么才算测试通过”。比如登录场景你可以写登录后等待商品列表加载完成断言页面上的商品卡片数量大于等于 1如果数量为 0 则说明登录失败或页面异常。这个验收标准看起来简单但它直接决定了 AI 在断言部分怎么写。没有验收标准的时候AI 会自由发挥。有一次我让它测一个搜索功能它给出来的断言居然是“页面标题包含搜索关键词”而实际上业务侧的验收点是“搜索结果列表里有商品”这俩根本不是一回事。加了验收标准之后它就会老老实实去定位搜索结果容器并数数量。说白了验收标准就是业务规则你得自己把关这是 AI 替代不了的部分。另外推荐在描述里带上“日志输出”和“断言信息要清晰”。比如“每个关键步骤打印日志”以及“断言失败的时候要能一眼看出是哪个环节出问题”。这样生成的脚本跑起来控制台输出的信息是可读的出了问题不会让你对着一个光秃秃的报错干瞪眼。2.3 第三层技术约束与交付格式锁定输出质量最后一层是技术约束。这是把“能跑的脚本”变成“好维护的脚本”的关键。我会明确告诉 AI使用WebDriverWait和expected_conditions做显式等待禁用time.sleep这种写死休眠的方式使用 pytest 的 fixture 管理浏览器启动和退出元素定位优先考虑id、name等相对稳定的属性避免使用大段绝对 XPath。为什么反复强调不要time.sleep因为它看起来简单但实际是脚本不稳定的头号来源。写死 3 秒页面快了浪费 3 秒页面慢了还是 3 秒结果元素没出来照样报错。显式等待是让脚本轮询元素状态元素一出现就继续既稳定又高效。AI 通常默认会给出time.sleep版本因为这是训练数据里最常见写法所以你得把这条约束写在前面。交付格式也要说清楚比如“输出完整的可以直接运行的 Python 代码包含全部 import”这句话很关键。有些 AI 为了节省字数会在代码里写“# 省略导入”或“# 此处省略浏览器初始化”你拿着半截代码去跑跑不起来还得自己补。所以务必让它输出可直接执行的完整代码。3. 1分钟实战AI 生成登录商品校验脚本的完整过程3.1 完整 Prompt 与 AI 初版脚本下面我拿一个公开测试站点saucedemo做实操演示这个站是专门给自动化测试练手的登录账号和商品列表都很稳定适合当例子。我的完整 Prompt 长这样你是一名精通 Selenium 和 pytest 的测试开发工程师。 请用 Python Selenium 为以下场景编写一份完整的自动化测试脚本 目标网站https://www.saucedemo.com/ 测试步骤 1. 打开登录页等待页面加载完成 2. 输入用户名 standard_user密码 secret_sauce 3. 点击登录按钮 4. 等待商品列表加载完成 5. 断言页面上的商品卡片数量大于等于 1 技术要求 - 使用 WebDriverWait 显式等待不要用 time.sleep - 使用 pytest fixture 管理浏览器启动与退出 - 每个关键步骤输出日志 - 使用 webdriver-manager 自动管理浏览器驱动 - 输出完整可运行的 Python 代码包含全部 import这段 Prompt 给出去AI 生成脚本的速度大概就是几十秒。它生成的第一版通常类似下面这样注意看它已经在遵守“不用 time.sleep”的约束了import logging import pytest from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.common.by import By from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.support.ui import WebDriverWait from webdriver_manager.chrome import ChromeDriverManager logging.basicConfig(levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s) pytest.fixture def driver(): driver webdriver.Chrome(serviceService(ChromeDriverManager().install())) driver.implicitly_wait(5) yield driver driver.quit() def test_login_and_view_products(driver): driver.get(https://www.saucedemo.com/) logging.info(打开登录页) WebDriverWait(driver, 10).until( EC.visibility_of_element_located((By.ID, login-button)) ) driver.find_element(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() logging.info(点击登录按钮) WebDriverWait(driver, 10).until( EC.presence_of_element_located((By.CLASS_NAME, inventory_item)) ) items driver.find_elements(By.CLASS_NAME, inventory_item) assert len(items) 1, f商品列表为空实际商品数量为 {len(items)} logging.info(登录成功发现 %s 个商品, len(items))这段代码已经具备可运行性。角色设定让 AI 写出了 pytest fixture技术约束让它没有用时间休眠验收标准让它正确使用了商品卡片数量作为断言条件。一分钟生成初稿这个目标如实达成。3.2 让 AI 按指定要求优化脚本初版脚本能跑但还达不到“可以直接投进项目里”的标准。我一般会再让 AI 做两轮强化。第一轮是增强健壮性比如给登录后的跳转加一个显式等待而不是依赖商品列表出现才确认登录成功。第二轮是增强可读性比如把元素定位统一用常量抽出来方便维护。这时候 Prompt 可以追加为请继续优化这份脚本 1. 把用户名、密码、关键页面元素的定位符提取为模块级常量 2. 增加失败截图功能断言失败时自动截图保存到本地 3. 使用 pytest 的 pytest.mark.parametrize 参数化登录账号至少包含一个正常账号和一个错误账号的用例 4. 保持原有技术约束不变这样一轮操作下来AI 输出的脚本架构就清晰多了。常量提取让后续改选择器不用钻进函数里翻参数化让一个用例覆盖多条数据截图功能让 CI 上跑挂了你还能看到现场。这些能力你要求它做它都会做但你不要求它默认不写。我通常不会让 AI 一次性把所有增强都做完而是分轮进行。为什么因为一轮 Prompt 塞太多需求AI 容易顾此失彼可能改了这个忘了那个。分轮调整每一轮只做一件事输出质量稳定得多。而且这种改法也更接近真实工作流先要一个能跑的骨架再逐步加固成能上线的东西。3.3 本地运行与结果验收脚本拿到手下一步就是放进本地跑。新建一个文件夹把代码保存为test_demo.py在命令行进入该文件夹执行pytest test_demo.py -v。如果一切顺利你会看到测试通过控制台输出含“登录成功发现 xx 个商品”的日志。这个-v参数建议养成习惯它能让你看到每条用例的执行状态失败时也方便定位具体是哪个用例挂了。运行这一步经常暴露一些小问题。最常见的是浏览器驱动没匹配上这时候 webdriver-manager 会自动帮你处理所以环境准备那步很重要。其次是首次运行需要下载驱动可能多等几十秒别误以为是卡住了。最后如果网站响应特别慢WebDriverWait的超时时间 10 秒不够用那就改成 20 秒这是很正常的调参过程。CI 环境里跑这套脚本也是同理用同样命令执行即可。如果希望输出更漂亮的报告可以追加 pytest 的 html 插件pip install pytest-html执行时加个--htmlreport.html参数就能生成网页版测试报告。具体怎么接我会自己在项目里根据自己的 CI 平台慢慢调这里就不展开说了。4. AI 生成脚本跑不起来的常见问题与排查技巧4.1 最让人头疼的四类运行报错先说一个事实AI 生成的脚本大概率能跑但不代表第一次一定能跑通。我统计了自己用 AI 写脚本的报错分布最常撞上的就四类。第一类是NoSuchElementException元素找不到。原因一般是页面结构跟你描述的不一致或者 AI 使用了默认的 class 名去定位而实际页面上那个 class 有多个元素。解决办法很简单把报错那一行的定位方式改成更稳妥的方案。让 AI 帮你重写定位器时你可以直接把报错信息和页面相关 HTML 片段贴给它让它基于真实页面结构重新生成定位方式。第二类是TimeoutException等待超时。通常不是 AI 的问题是页面加载确实慢把超时时间从 10 秒调到 20 秒就解决了。还有一种情况是你让 AI 等待的元素与页面实际渲染时机不一致比如等待一个只有在滚动后才会加载的列表而你没告诉 AI 需要先滚动这时候补个滚动操作就行。第三类是ElementClickInterceptedException元素被遮挡。页面顶部可能有个浮层或者公告栏盖住了你要点的按钮。我处理这种问题一般让 AI 用 JavaScript 直接点击也就是driver.execute_script(arguments[0].click();, element)绕过遮挡直接触发。不过这只是权宜之计长期来看还得弄清楚遮挡源。第四类是StaleElementReferenceException页面刷新后旧元素引用失效。场景是你定位了一个元素操作完页面局部刷新了你再回来操作这个元素时就报了错。解决办法是在刷新后重新定位元素。这类问题最容易出现在多页面的场景里AI 生成的代码不太会主动处理你得自己在代码里安排重新查找元素的逻辑或者让 AI 把关于这个元素的两次操作合并到一个流程里减少跨刷新操作的距离。4.2 一页纸速查表AI 脚本报错对照处理报错信息常见原因处理办法NoSuchElementException定位器不准确或页面未加载把真实 HTML 片段给 AI让它重写定位方式TimeoutException显式等待超时加大超时时间或检查等待的元素是否在预期时机出现ElementClickInterceptedException元素被浮层遮挡用 JS 点击绕过或关闭遮挡层后再操作StaleElementReferenceException页面刷新导致旧引用失效刷新后重新定位元素再操作WebDriverException驱动版本不匹配使用 webdriver-manager 自动匹配驱动AttributeError: WebDriver object has no attribute find_element_by_id旧 API 被移除让 AI 改用 find_element(By.ID, xxx) 的新写法这张表是我从实际运行 AI 脚本的报错里整理出来的。前四个占了我遇到的 80% 以上后两个属于环境或版本问题。遇到报错千万别急着百度复制粘贴先读一下报错信息里提到的定位器和元素状态大多数时候问题没那么玄学。4.3 让 AI 最终脚本更稳的三个小技巧技巧一把页面元素和业务逻辑分离。让 AI 把页面元素定位、业务步骤、断言分开组织后续维护只改定位器就行业务逻辑和断言不会跟着乱。这个要求写在 Prompt 里它就会照做。技巧二让 AI 生成“可配置”的脚本。测试环境、用户名密码这类变量不要写死在代码里让 AI 把它们抽出来定义在文件开头或者配置文件里。这样一套脚本可以在多个环境之间切换不用每换一个环境就改一段代码。技巧三建立自己的 Prompt 模板库。我在实际使用中发现不同人写 Selenium 的风格差异很大但 AI 每次都从零写风格就变来变去。我自己会把常用的 Prompt 模板保存下来比如登录测试模板、搜索测试模板、购物车流程测试模板每次只替换网址和账号密码。模板沉淀下来之后一分钟出初稿是稳定可复现的而不是偶尔灵光一现。我实际操作中还有个习惯脚本跑通之后一定会把 AI 生成的代码从头读一遍。不是不信任 AI而是测试脚本最终要对业务负责每一条断言是不是真正的业务规则、每一条等待是不是会拖慢执行、每一个定位器是不是稳定这些都得人肉把关。AI 负责把路修好方向盘始终在我手里。这套流程跑了几个月最大的感受是脚本产出速度上来了但最值钱的不是省下的时间而是我终于有精力去思考测试策略本身了。