做UI自动化这些年我最大的体会是真正让项目推进不下去的往往不是不会写脚本而是不会设计用例。很多人原生Selenium玩得挺溜定位元素一套一套的结果用例跑两周就崩——要么前端改版全盘失效要么用例之间互相干扰要么本地能过一到CI就挂。后来我把整个流程从需求拆解、用例设计、数据规划到落地执行全部切到SeleniumBase重做稳定性和可维护性才真正立起来。这篇就把这套从需求到自动化的完整流程整理出来同时把SeleniumBase里那些能让你少写一半代码的细节讲透。不管你是刚接触UI自动化的新人还是被现有脚本维护折磨得想重构的老手这套思路都值得参考。1. 为什么是SeleniumBase先把框架选型想明白1.1 它和原生Selenium的差别在哪里见过太多人还在用原生Selenium写很原始的代码先实例化WebDriver再写显式等待工具类封装元素查找方法自己处理截图和报告最后维护一整套和业务无关的底层框架。这套东西不是不能跑但维护成本全部压在自己团队身上。SeleniumBase解决的核心问题是把那些所有UI项目都会遇到的脏活累活全部内置掉让你把精力留在业务用例上。我挑几个最典型的差异说。首先是等待机制。原生Selenium里最常见的报错就是元素找不到、元素不可点击你得自己写WebDriverWait。SeleniumBase所有内置动作方法——click、type、assert_element这些——默认都会自动等待元素出现且可交互不需要你手动加等待。这个改动直接消掉了脚本里一半以上的稳定性问题。其次是API设计。原生Selenium的click只能点击“能点”的元素遇到被遮挡、不可见的按钮就要自己处理。SeleniumBase提供了js_click、slow_click这类带实际场景的变体还支持通过文本定位元素比如self.click(button:contains(登 录))这种在极端DOM结构下特别好用。再一个是自带的一整套工程能力。SeleniumBase内置了pytest插件、可视化报告、失败截图、录屏、命令行参数、并发执行策略连无头模式都直接整合好。我早期用原生Selenium搭一套报告系统前后写了小两周在SeleniumBase里就是一条命令的事。提示SeleniumBase不是替代Selenium而是基于Selenium的上层框架。你可以理解成原生Selenium是“手动挡工具”SeleniumBase是“自动挡工具”该有的能力都有但操作路径被大幅简化了。1.2 哪些项目适合用它哪些不适合我也得泼点冷水。SeleniumBase不是万能药选型前先对照你的项目现状。适合的场景传统Web系统、后台管理系统这类DOM结构相对稳定页面流程清晰的项目。团队希望快速搭建UI自动化体系但又不想花大量时间自研框架的场景。需要跑回归、支持数据驱动、需要出报告给管理层看的交付型项目。页面交互不算太复杂以表单填写、按钮点击、列表校验为主的业务。不太适合的场景纯API测试为主的项目没必要引一套UI框架进去重。页面有大量Canvas、WebGL绘制的场景SeleniumBase帮不了你该用图像识别还是得用。完全动态、无固定DOM结构的页面比如大量Shadow DOM嵌套、自定义渲染引擎虽然SeleniumBase对Shadow DOM有支持但代价依旧不小。另外如果你的项目还没想清楚自动化要和业务怎么结合先别急着上框架。工具只是放大你的设计能力不会替你思考用例结构。2. 从需求到用例先别急着写脚本2.1 需求拆解把一句话变成一张可追查的清单很多自动化项目的死亡原因不是技术而是需求理解不到位。产品经理给你一句“登录功能要测”你直接开始写脚本十有八九会漏掉边界场景。我习惯的做法是先把需求拆成功能点清单。以登录模块为例一句话需求至少可以拆出这些维度正常登录流程正确账号、正确密码能进入主页。必填项校验用户名为空、密码为空时的提示。格式校验用户名格式、密码长度限制。账号密码错误不同错误组合的提示与行为。异常状态账号被锁定、账号被禁用、密码过期未改。安全与体验记住密码、验证码刷新、登录失败重试限制。跳转逻辑登录成功后默认落到哪个页面。拆完清单再去看现有系统的实际行为逐条核对哪些是真实存在的入口哪些是隐藏规则。这个核对动作特别重要因为有些校验在前端做、有些在后端做前端能触发的前提条件不一样。我遇到过很多次用例设计得很美结果跑到第三步就没法继续因为前置状态根本构造不出来。拆完清单之后把每个功能点对应到具体的页面元素和交互路径。比如“用户名为空”就对应着用户名输入框不填写、直接点击登录按钮、校验提示文案出现在某个位置。这一步做完你才有底气说用例是可落地的。2.2 用例颗粒度一个用例不要干三件事新手最喜欢犯的错是把一个用例写得又臭又长从注册登录开始一路点到下单支付最后还要校验订单状态。看着像是“端到端覆盖”实际上只要中间任何一步失败整个用例就无法定位问题出在哪排查成本极高。我定的原则是一个用例只验证一个核心行为。登录成功是一个用例用户名必填校验是一个用例密码错误提示是一个用例。业务链路长的时候用前置条件跳过去而不是把所有步骤硬揉进同一个用例里。假设你要测“已登录用户加购下单”前置条件就直接通过接口或数据库准备一份已登录状态而不是每次从登录页一步一步点进去。这样用例之间的耦合度大幅降低单个用例的可读性和可维护性都上来了。等用例规模上来之后你还会发现用例颗粒度小并发执行和失败重跑的代价都非常低。注意小颗粒度的前提是你有可用的前置条件构造手段比如测试账号体系、数据准备接口、数据库直插。如果没有优先补齐这块基建再去优化用例结构会顺畅很多。2.3 元素定位策略稳定比优雅更重要元素定位是UI自动化的地基。这地方不稳上面全白搭。我在做元素定位时优先级排序是这样的有语义化的id、name属性优先用这种定位和页面结构调整的耦合度最小。没有稳定属性时用CSS选择器定位到结构化特征比如表单区域内的某个输入框。实在没有特征再用XPath但只用来表达层级或文本关系不要写那种一改前端就碎的绝对路径。另外要有意识地避开“表达页面状态”的元素。比如按钮的文案是“确认提交”这种文本随时可能改成“提交订单”。用文本定位一时很爽但属于把风险藏起来的写法。SeleniumBase里还提供了一种很有用的组合写法把属性和文本一起用self.click(button:contains(提 交)) self.assert_text(提交成功, .toast-message)这种标签:contains(文本)的选择器在遇到页面文案频繁调整时也好维护只要把主语换成数据属性或稳定的class读起来还特别像自然语言。定位策略定下来以后最好整理成元素库文档。哪些元素用id、哪些用CSS、哪些有特殊说明统一记录。项目里多人协作的时候没有这份文档就会出现同一个人对不同模块的定位风格完全不一致的情况到时候改版维护会特别痛。3. 实操一个登录模块从零跑通全流程3.1 环境准备与目录规划先花一分钟把环境搞定。SeleniumBase推荐用Python 3.8以上版本直接pip安装pip install seleniumbase装完之后seleniumbase这个命令会出现它会帮你去下载对应浏览器驱动。第一次执行用例时会自动下载匹配的驱动版本不用像原生Selenium那样手动配环境变量。如果你在CI环境跑无头模式一条命令带上--headless参数就行。然后是目录规划。我习惯把测试文件统一放在tests/目录下按模块拆文件project/ ├── tests/ │ ├── test_login.py │ ├── test_cart.py │ └── test_order.py ├── reports/ └── run_tests.sh这一步看似简单但决定了项目后续扩展的顺畅度。建议从一开始就按业务模块分文件别把几百条用例堆在一个文件里。3.2 第一个脚本把登录流程跑起来我用一个模拟项目X的登录模块来演示完整流程。假设登录页结构是用户名输入框#username密码输入框#password登录按钮button[typesubmit]登录成功后的欢迎语.user-welcome错误提示框.message-box第一个正常登录的用例from seleniumbase import BaseCase class LoginTests(BaseCase): def test_login_success(self): # 打开登录页 self.open(https://demo.example.com/login) # 输入账号密码 self.type(#username, tester001) self.type(#password, Passw0rd!) # 点击登录 self.click(button[typesubmit]) # 断言登录成功 self.assert_element(.user-welcome) self.assert_text(欢迎回来, .user-welcome)跑一下pytest tests/test_login.py -v如果是第一次运行SeleniumBase会自动下载驱动并进行浏览器初始化全程不需要手动操作。用例跑完你会在终端看到每个步骤的输出日志失败时还会自动截图放到./latest_logs/目录。这段代码看起来简洁但背后SeleniumBase做了不少事type会先自动清空输入框再输入click会等待元素可见且可交互assert_element会轮询直到元素出现或超时。你省掉的那些显式等待代码都是框架在替你完成。3.3 用例设计与数据驱动改造正常登录只是起点。现在把第2节里拆出来的需求点逐个落地最常用的方式是数据驱动。SeleniumBase基于pytest天然支持parametrize。我把登录相关场景整理成一张数据表场景用户名密码预期行为正常登录tester001Passw0rd!登录成功进入主页用户名为空(空)Passw0rd!提示“用户名不能为空”密码为空tester001(空)提示“密码不能为空”密码错误tester001wrongpass提示“用户名或密码错误”账号锁定locked_userPassw0rd!提示“账号已锁定请联系管理员”对应代码import pytest from seleniumbase import BaseCase class LoginDataDriven(BaseCase): pytest.mark.parametrize(username,password,expected, [ (tester001, Passw0rd!, 欢迎回来), (, Passw0rd!, 用户名不能为空), (tester001, , 密码不能为空), (tester001, wrongpass, 用户名或密码错误), (locked_user, Passw0rd!, 账号已锁定请联系管理员), ]) def test_login_scenarios(self, username, password, expected): self.open(https://demo.example.com/login) if username: self.type(#username, username) if password: self.type(#password, password) self.click(button[typesubmit]) self.assert_text(expected, .message-box)这样单个文件就把一类场景全部覆盖了。参数表本身可以进一步外置成JSON或YAML项目规模上来以后用例数据会统一维护。注意里面有个小细节空值场景下如果直接type一个空字符串也可以但为了保持真实交互我对username和password做了条件判断空值就完全不去触碰输入框。虽然结果基本一样但更贴近用户真实行为减少因为触发方式差异带来的不稳定。3.4 断言与报告让结果可读可追踪断言设计是UI自动化里最容易糊弄、也最影响质量的一环。很多人只断言“元素存在”就完事也就是assert_element用一下页面随便有个匹配元素就算过。这样会产生大量假阳性——脚本绿着但你根本不知道页面是否真的正确。我自己的断言设计分了两个层级流程态断言判断当前页面是否流转到了预期位置。比如登录成功后是否存在.user-welcome区域。数据态断言判断页面上的具体内容是否符合预期。比如欢迎语是不是“欢迎回来”订单金额是不是“99.00”列表里有没有包含目标商品名。只有流程态断言是远远不够的。拿一道生活里的类比网购签收时快递员把箱子放下你就算收到了但验货还要打开看里面东西对不对。UI测试同理流程到了不等于数据对了。SeleniumBase里断言API非常丰富常用的有self.assert_element(selector) # 元素存在且可见 self.assert_text(text, selector) # 元素文本包含指定内容 self.assert_exact_text(text, selector) # 元素文本与指定内容完全一致 self.assert_attribute(selector, attr, value) # 元素属性值 self.assert_element_count(selector, n) # 匹配元素数量执行完整个测试集之后生成报告的命令也很简单pytest tests/test_login.py --htmlreport.html --self-contained-html搭配SeleniumBase自带的报告功能失败用例会自动包含截图、页面源码和浏览器控制台日志。这些信息在你排查问题时会省下大量时间尤其当你面对的是“测试凌晨挂了早上来修”这种场景。4. 执行阶段的坑与排查实录4.1 time.sleep为什么是毒药几乎每个从原生Selenium转过来的人都踩过这个坑元素加载不够快于是直接在代码里加time.sleep(3)。这段代码在本地可能没问题但换台配置差点的机器、或者页面数据量变大之后性能一波动用例就挂。SeleniumBase之所以稳核心在于它的事件等待机制。click、type这类动作会先等元素“存在且可见且可交互”等到之后才操作。你能做的不是加睡眠而是把等待策略用好。SeleniumBase直接支持显式等待self.wait_for_element(#dynamic-content, timeout15) self.wait_for_text(加载完成, .status-text, timeout15)我通常会在页面有明显异步加载的场景里用wait_for_text去等一段代表加载结束的业务文案。等的是“业务状态”而不是“时间长度”这是最本质的区别。注意不是所有场景都完全不能等待比如上传文件后预览渲染这种不在DOM状态里体现的场景偶尔需要固定等待。但这类等待要写注释说明原因别让人以为是在盲等。4.2 元素定位失败的几种典型场景UI自动化跑久了定位失败基本逃不开下面几种Stale元素引用。页面发起了局部刷新之前拿到的元素对象已经失效再去点击就报StaleElementReferenceException。多数情况下SeleniumBase内部会帮你自动重试但如果你在代码里先用self.find_element取出元素再经过一段业务逻辑后去操作就可能踩到。我的习惯是避免把元素对象缓存住每次操作直接用选择器让框架自己重新查找。元素被遮挡。按钮明明找得到但click报不可交互。常见原因是页面有浮层、遮罩或者弹窗把按钮盖住了。先用浏览器开发者工具看一下元素上的覆盖节点再决定是用js_click绕过遮挡还是先关掉弹窗再操作。别一遇到就无脑上JS点击掩盖了真实交互路径里的问题。有多个匹配元素。选择器写得太宽比如div.button匹配了一排按钮。SeleniumBase里click会默认点击第一个匹配到的元素但可能不是你要的那个。这时候把选择器收窄加上父级特征或用包含文本定位。4.3 用例串扰与数据污染UI自动化项目跑一段时间后最常见的神秘故障是“单独跑全过整套跑随机挂”。这种问题九成是用例之间共享了状态。典型的串扰场景用户A在用例1里创建了一条数据用例2跑的时候带着同一条历史数据继续操作结果断言数据数量不符合预期。再比如用例1把某个全局状态改了用例2没等恢复直接跑页面显示就不对了。我的解法是三个方向同时做每个用例独立准备自己的数据尽量别依赖上一个用例留下的现场。需要特定账号状态的用例优先通过接口或数据库直接构造前置数据而不是靠UI一步步点过去。用例执行顺序上不要让业务流有先后依赖需要链路验证就拆成独立用例各自构造前置条件。数据层面还要注意账号污染的问题。测试账号用久了历史数据越积越多一些对数据敏感的操作就会忽好忽坏。定期清理测试数据或者用随机账号是很多项目容易忽略但非常必要的维护动作。4.4 CI环境下保持稳定的关键配置在本地跑得好好的上了CI时不时就挂这是很多团队的常态。CI环境的机器配置、网络、屏幕分辨率都会影响到UI自动化。SeleniumBase在CI这块做了不少适配我实际用下来有几个关键点无头模式。CI里没有显示设备务必用--headless参数。SeleniumBase的无头模式对主流浏览器支持很成熟。固定浏览器分辨率。页面响应式布局很容易因为浏览器尺寸不同导致元素位置变化进而点击失败。我在CI里一般把窗口固定在1920x1080避免这类波动。预留超时余量。CI机器负载高页面加载慢是常态。关键步骤的显式等待超时我会比本地多给5到10秒而不是每个操作都加时间只针对异步加载瓶颈处增加。pytest tests/ -v --headless --browserchrome --window-size1920,1080 -n4-n4可以并行跑用例执行效率会明显提升。不过并发数不是越大越好受接口压力、数据库连接数、页面资源加载的影响需要实测调整。我一般从2开始试逐步往上加找到当前环境下的稳定阈值。5. 从长远维护的角度看用例设计5.1 用例改名与变更是常态设计好是为了改起来不痛很多自动化项目死在“改版”这个坎上。前端一改所有用例跟着碎团队改不过来就渐渐放弃跑了。这个问题的根源往往不是自动化这层的问题而是用例本身没有和业务场景做好映射。页面元素会变、交互方式会变但业务行为相对稳定。“登录”“加购”“下单”这些动作不会因为前端重写而消失。所以我做用例设计时优先去想“这个用例在验证什么业务规则”而不是“这个用例操作什么页面元素”。这样前端改版时你更新的是元素的定位信息而不需要重写整个用例逻辑。如果项目里有简单的页面对象层把元素定位独立封装用例本体只描述业务步骤维护成本会大幅下降。SeleniumBase本身不强制页面对象模式但你可以轻松地通过继承或工具类的方式实现这一层抽象这几乎是我在超过200条用例规模的项目里必须做的事。5.2 用例评审自动化用例和手工用例一样需要被人看我见过太多自动化用例代码写得只有自己能看懂。变量命名随意、注释缺失、断言逻辑完全看不出在测什么业务。这种代码两三个月后连作者自己都未必能快速改得动。比较务实的做法是把用例评审纳入日常流程。每轮新写或改动用例的时候以评审的方式过一遍重点看三点——是否覆盖了改动的业务点、是否有不必要的耦合、断言是否和需求一致。这个动作不复杂但能有效防止用例库走向腐烂。另外用例里尽量用中文注释写明业务意图尤其是那些看起来“不太常规”的写法。比如某个元素因为历史原因要特殊处理注释里一句话解释清楚别人就不需要去考古了。提示写自动化用例有一个很朴素的标准——如果你在半年后接手这段代码能不能在十分钟内看懂它在测什么、怎么改才不会破坏原有意图。按这个标准来写维护成本就不会失控。我个人实际做项目时还有一个习惯每个迭代结束后翻一遍失败用例记录看看哪些用例反复失败、哪些用例长期不跑。反复失败的用例说明设计或者环境依赖有问题长期不跑说明它已经失去价值。定期清理和优化用例比一味新增用例要重要得多。自动化测试的核心不是用例数量而是这套用例能不能持续稳定地帮你发现回归问题这个标准从第一天建框架到最后一天维护从来没有变过。 
长河君 · 2026/10/18 15:48:46 · 阅读 1.2k SeleniumBase实践：从需求拆解到稳定UI自动化用例设计
做UI自动化这些年我最大的体会是真正让项目推进不下去的往往不是不会写脚本而是不会设计用例。很多人原生Selenium玩得挺溜定位元素一套一套的结果用例跑两周就崩——要么前端改版全盘失效要么用例之间互相干扰要么本地能过一到CI就挂。后来我把整个流程从需求拆解、用例设计、数据规划到落地执行全部切到SeleniumBase重做稳定性和可维护性才真正立起来。这篇就把这套从需求到自动化的完整流程整理出来同时把SeleniumBase里那些能让你少写一半代码的细节讲透。不管你是刚接触UI自动化的新人还是被现有脚本维护折磨得想重构的老手这套思路都值得参考。1. 为什么是SeleniumBase先把框架选型想明白1.1 它和原生Selenium的差别在哪里见过太多人还在用原生Selenium写很原始的代码先实例化WebDriver再写显式等待工具类封装元素查找方法自己处理截图和报告最后维护一整套和业务无关的底层框架。这套东西不是不能跑但维护成本全部压在自己团队身上。SeleniumBase解决的核心问题是把那些所有UI项目都会遇到的脏活累活全部内置掉让你把精力留在业务用例上。我挑几个最典型的差异说。首先是等待机制。原生Selenium里最常见的报错就是元素找不到、元素不可点击你得自己写WebDriverWait。SeleniumBase所有内置动作方法——click、type、assert_element这些——默认都会自动等待元素出现且可交互不需要你手动加等待。这个改动直接消掉了脚本里一半以上的稳定性问题。其次是API设计。原生Selenium的click只能点击“能点”的元素遇到被遮挡、不可见的按钮就要自己处理。SeleniumBase提供了js_click、slow_click这类带实际场景的变体还支持通过文本定位元素比如self.click(button:contains(登 录))这种在极端DOM结构下特别好用。再一个是自带的一整套工程能力。SeleniumBase内置了pytest插件、可视化报告、失败截图、录屏、命令行参数、并发执行策略连无头模式都直接整合好。我早期用原生Selenium搭一套报告系统前后写了小两周在SeleniumBase里就是一条命令的事。提示SeleniumBase不是替代Selenium而是基于Selenium的上层框架。你可以理解成原生Selenium是“手动挡工具”SeleniumBase是“自动挡工具”该有的能力都有但操作路径被大幅简化了。1.2 哪些项目适合用它哪些不适合我也得泼点冷水。SeleniumBase不是万能药选型前先对照你的项目现状。适合的场景传统Web系统、后台管理系统这类DOM结构相对稳定页面流程清晰的项目。团队希望快速搭建UI自动化体系但又不想花大量时间自研框架的场景。需要跑回归、支持数据驱动、需要出报告给管理层看的交付型项目。页面交互不算太复杂以表单填写、按钮点击、列表校验为主的业务。不太适合的场景纯API测试为主的项目没必要引一套UI框架进去重。页面有大量Canvas、WebGL绘制的场景SeleniumBase帮不了你该用图像识别还是得用。完全动态、无固定DOM结构的页面比如大量Shadow DOM嵌套、自定义渲染引擎虽然SeleniumBase对Shadow DOM有支持但代价依旧不小。另外如果你的项目还没想清楚自动化要和业务怎么结合先别急着上框架。工具只是放大你的设计能力不会替你思考用例结构。2. 从需求到用例先别急着写脚本2.1 需求拆解把一句话变成一张可追查的清单很多自动化项目的死亡原因不是技术而是需求理解不到位。产品经理给你一句“登录功能要测”你直接开始写脚本十有八九会漏掉边界场景。我习惯的做法是先把需求拆成功能点清单。以登录模块为例一句话需求至少可以拆出这些维度正常登录流程正确账号、正确密码能进入主页。必填项校验用户名为空、密码为空时的提示。格式校验用户名格式、密码长度限制。账号密码错误不同错误组合的提示与行为。异常状态账号被锁定、账号被禁用、密码过期未改。安全与体验记住密码、验证码刷新、登录失败重试限制。跳转逻辑登录成功后默认落到哪个页面。拆完清单再去看现有系统的实际行为逐条核对哪些是真实存在的入口哪些是隐藏规则。这个核对动作特别重要因为有些校验在前端做、有些在后端做前端能触发的前提条件不一样。我遇到过很多次用例设计得很美结果跑到第三步就没法继续因为前置状态根本构造不出来。拆完清单之后把每个功能点对应到具体的页面元素和交互路径。比如“用户名为空”就对应着用户名输入框不填写、直接点击登录按钮、校验提示文案出现在某个位置。这一步做完你才有底气说用例是可落地的。2.2 用例颗粒度一个用例不要干三件事新手最喜欢犯的错是把一个用例写得又臭又长从注册登录开始一路点到下单支付最后还要校验订单状态。看着像是“端到端覆盖”实际上只要中间任何一步失败整个用例就无法定位问题出在哪排查成本极高。我定的原则是一个用例只验证一个核心行为。登录成功是一个用例用户名必填校验是一个用例密码错误提示是一个用例。业务链路长的时候用前置条件跳过去而不是把所有步骤硬揉进同一个用例里。假设你要测“已登录用户加购下单”前置条件就直接通过接口或数据库准备一份已登录状态而不是每次从登录页一步一步点进去。这样用例之间的耦合度大幅降低单个用例的可读性和可维护性都上来了。等用例规模上来之后你还会发现用例颗粒度小并发执行和失败重跑的代价都非常低。注意小颗粒度的前提是你有可用的前置条件构造手段比如测试账号体系、数据准备接口、数据库直插。如果没有优先补齐这块基建再去优化用例结构会顺畅很多。2.3 元素定位策略稳定比优雅更重要元素定位是UI自动化的地基。这地方不稳上面全白搭。我在做元素定位时优先级排序是这样的有语义化的id、name属性优先用这种定位和页面结构调整的耦合度最小。没有稳定属性时用CSS选择器定位到结构化特征比如表单区域内的某个输入框。实在没有特征再用XPath但只用来表达层级或文本关系不要写那种一改前端就碎的绝对路径。另外要有意识地避开“表达页面状态”的元素。比如按钮的文案是“确认提交”这种文本随时可能改成“提交订单”。用文本定位一时很爽但属于把风险藏起来的写法。SeleniumBase里还提供了一种很有用的组合写法把属性和文本一起用self.click(button:contains(提 交)) self.assert_text(提交成功, .toast-message)这种标签:contains(文本)的选择器在遇到页面文案频繁调整时也好维护只要把主语换成数据属性或稳定的class读起来还特别像自然语言。定位策略定下来以后最好整理成元素库文档。哪些元素用id、哪些用CSS、哪些有特殊说明统一记录。项目里多人协作的时候没有这份文档就会出现同一个人对不同模块的定位风格完全不一致的情况到时候改版维护会特别痛。3. 实操一个登录模块从零跑通全流程3.1 环境准备与目录规划先花一分钟把环境搞定。SeleniumBase推荐用Python 3.8以上版本直接pip安装pip install seleniumbase装完之后seleniumbase这个命令会出现它会帮你去下载对应浏览器驱动。第一次执行用例时会自动下载匹配的驱动版本不用像原生Selenium那样手动配环境变量。如果你在CI环境跑无头模式一条命令带上--headless参数就行。然后是目录规划。我习惯把测试文件统一放在tests/目录下按模块拆文件project/ ├── tests/ │ ├── test_login.py │ ├── test_cart.py │ └── test_order.py ├── reports/ └── run_tests.sh这一步看似简单但决定了项目后续扩展的顺畅度。建议从一开始就按业务模块分文件别把几百条用例堆在一个文件里。3.2 第一个脚本把登录流程跑起来我用一个模拟项目X的登录模块来演示完整流程。假设登录页结构是用户名输入框#username密码输入框#password登录按钮button[typesubmit]登录成功后的欢迎语.user-welcome错误提示框.message-box第一个正常登录的用例from seleniumbase import BaseCase class LoginTests(BaseCase): def test_login_success(self): # 打开登录页 self.open(https://demo.example.com/login) # 输入账号密码 self.type(#username, tester001) self.type(#password, Passw0rd!) # 点击登录 self.click(button[typesubmit]) # 断言登录成功 self.assert_element(.user-welcome) self.assert_text(欢迎回来, .user-welcome)跑一下pytest tests/test_login.py -v如果是第一次运行SeleniumBase会自动下载驱动并进行浏览器初始化全程不需要手动操作。用例跑完你会在终端看到每个步骤的输出日志失败时还会自动截图放到./latest_logs/目录。这段代码看起来简洁但背后SeleniumBase做了不少事type会先自动清空输入框再输入click会等待元素可见且可交互assert_element会轮询直到元素出现或超时。你省掉的那些显式等待代码都是框架在替你完成。3.3 用例设计与数据驱动改造正常登录只是起点。现在把第2节里拆出来的需求点逐个落地最常用的方式是数据驱动。SeleniumBase基于pytest天然支持parametrize。我把登录相关场景整理成一张数据表场景用户名密码预期行为正常登录tester001Passw0rd!登录成功进入主页用户名为空(空)Passw0rd!提示“用户名不能为空”密码为空tester001(空)提示“密码不能为空”密码错误tester001wrongpass提示“用户名或密码错误”账号锁定locked_userPassw0rd!提示“账号已锁定请联系管理员”对应代码import pytest from seleniumbase import BaseCase class LoginDataDriven(BaseCase): pytest.mark.parametrize(username,password,expected, [ (tester001, Passw0rd!, 欢迎回来), (, Passw0rd!, 用户名不能为空), (tester001, , 密码不能为空), (tester001, wrongpass, 用户名或密码错误), (locked_user, Passw0rd!, 账号已锁定请联系管理员), ]) def test_login_scenarios(self, username, password, expected): self.open(https://demo.example.com/login) if username: self.type(#username, username) if password: self.type(#password, password) self.click(button[typesubmit]) self.assert_text(expected, .message-box)这样单个文件就把一类场景全部覆盖了。参数表本身可以进一步外置成JSON或YAML项目规模上来以后用例数据会统一维护。注意里面有个小细节空值场景下如果直接type一个空字符串也可以但为了保持真实交互我对username和password做了条件判断空值就完全不去触碰输入框。虽然结果基本一样但更贴近用户真实行为减少因为触发方式差异带来的不稳定。3.4 断言与报告让结果可读可追踪断言设计是UI自动化里最容易糊弄、也最影响质量的一环。很多人只断言“元素存在”就完事也就是assert_element用一下页面随便有个匹配元素就算过。这样会产生大量假阳性——脚本绿着但你根本不知道页面是否真的正确。我自己的断言设计分了两个层级流程态断言判断当前页面是否流转到了预期位置。比如登录成功后是否存在.user-welcome区域。数据态断言判断页面上的具体内容是否符合预期。比如欢迎语是不是“欢迎回来”订单金额是不是“99.00”列表里有没有包含目标商品名。只有流程态断言是远远不够的。拿一道生活里的类比网购签收时快递员把箱子放下你就算收到了但验货还要打开看里面东西对不对。UI测试同理流程到了不等于数据对了。SeleniumBase里断言API非常丰富常用的有self.assert_element(selector) # 元素存在且可见 self.assert_text(text, selector) # 元素文本包含指定内容 self.assert_exact_text(text, selector) # 元素文本与指定内容完全一致 self.assert_attribute(selector, attr, value) # 元素属性值 self.assert_element_count(selector, n) # 匹配元素数量执行完整个测试集之后生成报告的命令也很简单pytest tests/test_login.py --htmlreport.html --self-contained-html搭配SeleniumBase自带的报告功能失败用例会自动包含截图、页面源码和浏览器控制台日志。这些信息在你排查问题时会省下大量时间尤其当你面对的是“测试凌晨挂了早上来修”这种场景。4. 执行阶段的坑与排查实录4.1 time.sleep为什么是毒药几乎每个从原生Selenium转过来的人都踩过这个坑元素加载不够快于是直接在代码里加time.sleep(3)。这段代码在本地可能没问题但换台配置差点的机器、或者页面数据量变大之后性能一波动用例就挂。SeleniumBase之所以稳核心在于它的事件等待机制。click、type这类动作会先等元素“存在且可见且可交互”等到之后才操作。你能做的不是加睡眠而是把等待策略用好。SeleniumBase直接支持显式等待self.wait_for_element(#dynamic-content, timeout15) self.wait_for_text(加载完成, .status-text, timeout15)我通常会在页面有明显异步加载的场景里用wait_for_text去等一段代表加载结束的业务文案。等的是“业务状态”而不是“时间长度”这是最本质的区别。注意不是所有场景都完全不能等待比如上传文件后预览渲染这种不在DOM状态里体现的场景偶尔需要固定等待。但这类等待要写注释说明原因别让人以为是在盲等。4.2 元素定位失败的几种典型场景UI自动化跑久了定位失败基本逃不开下面几种Stale元素引用。页面发起了局部刷新之前拿到的元素对象已经失效再去点击就报StaleElementReferenceException。多数情况下SeleniumBase内部会帮你自动重试但如果你在代码里先用self.find_element取出元素再经过一段业务逻辑后去操作就可能踩到。我的习惯是避免把元素对象缓存住每次操作直接用选择器让框架自己重新查找。元素被遮挡。按钮明明找得到但click报不可交互。常见原因是页面有浮层、遮罩或者弹窗把按钮盖住了。先用浏览器开发者工具看一下元素上的覆盖节点再决定是用js_click绕过遮挡还是先关掉弹窗再操作。别一遇到就无脑上JS点击掩盖了真实交互路径里的问题。有多个匹配元素。选择器写得太宽比如div.button匹配了一排按钮。SeleniumBase里click会默认点击第一个匹配到的元素但可能不是你要的那个。这时候把选择器收窄加上父级特征或用包含文本定位。4.3 用例串扰与数据污染UI自动化项目跑一段时间后最常见的神秘故障是“单独跑全过整套跑随机挂”。这种问题九成是用例之间共享了状态。典型的串扰场景用户A在用例1里创建了一条数据用例2跑的时候带着同一条历史数据继续操作结果断言数据数量不符合预期。再比如用例1把某个全局状态改了用例2没等恢复直接跑页面显示就不对了。我的解法是三个方向同时做每个用例独立准备自己的数据尽量别依赖上一个用例留下的现场。需要特定账号状态的用例优先通过接口或数据库直接构造前置数据而不是靠UI一步步点过去。用例执行顺序上不要让业务流有先后依赖需要链路验证就拆成独立用例各自构造前置条件。数据层面还要注意账号污染的问题。测试账号用久了历史数据越积越多一些对数据敏感的操作就会忽好忽坏。定期清理测试数据或者用随机账号是很多项目容易忽略但非常必要的维护动作。4.4 CI环境下保持稳定的关键配置在本地跑得好好的上了CI时不时就挂这是很多团队的常态。CI环境的机器配置、网络、屏幕分辨率都会影响到UI自动化。SeleniumBase在CI这块做了不少适配我实际用下来有几个关键点无头模式。CI里没有显示设备务必用--headless参数。SeleniumBase的无头模式对主流浏览器支持很成熟。固定浏览器分辨率。页面响应式布局很容易因为浏览器尺寸不同导致元素位置变化进而点击失败。我在CI里一般把窗口固定在1920x1080避免这类波动。预留超时余量。CI机器负载高页面加载慢是常态。关键步骤的显式等待超时我会比本地多给5到10秒而不是每个操作都加时间只针对异步加载瓶颈处增加。pytest tests/ -v --headless --browserchrome --window-size1920,1080 -n4-n4可以并行跑用例执行效率会明显提升。不过并发数不是越大越好受接口压力、数据库连接数、页面资源加载的影响需要实测调整。我一般从2开始试逐步往上加找到当前环境下的稳定阈值。5. 从长远维护的角度看用例设计5.1 用例改名与变更是常态设计好是为了改起来不痛很多自动化项目死在“改版”这个坎上。前端一改所有用例跟着碎团队改不过来就渐渐放弃跑了。这个问题的根源往往不是自动化这层的问题而是用例本身没有和业务场景做好映射。页面元素会变、交互方式会变但业务行为相对稳定。“登录”“加购”“下单”这些动作不会因为前端重写而消失。所以我做用例设计时优先去想“这个用例在验证什么业务规则”而不是“这个用例操作什么页面元素”。这样前端改版时你更新的是元素的定位信息而不需要重写整个用例逻辑。如果项目里有简单的页面对象层把元素定位独立封装用例本体只描述业务步骤维护成本会大幅下降。SeleniumBase本身不强制页面对象模式但你可以轻松地通过继承或工具类的方式实现这一层抽象这几乎是我在超过200条用例规模的项目里必须做的事。5.2 用例评审自动化用例和手工用例一样需要被人看我见过太多自动化用例代码写得只有自己能看懂。变量命名随意、注释缺失、断言逻辑完全看不出在测什么业务。这种代码两三个月后连作者自己都未必能快速改得动。比较务实的做法是把用例评审纳入日常流程。每轮新写或改动用例的时候以评审的方式过一遍重点看三点——是否覆盖了改动的业务点、是否有不必要的耦合、断言是否和需求一致。这个动作不复杂但能有效防止用例库走向腐烂。另外用例里尽量用中文注释写明业务意图尤其是那些看起来“不太常规”的写法。比如某个元素因为历史原因要特殊处理注释里一句话解释清楚别人就不需要去考古了。提示写自动化用例有一个很朴素的标准——如果你在半年后接手这段代码能不能在十分钟内看懂它在测什么、怎么改才不会破坏原有意图。按这个标准来写维护成本就不会失控。我个人实际做项目时还有一个习惯每个迭代结束后翻一遍失败用例记录看看哪些用例反复失败、哪些用例长期不跑。反复失败的用例说明设计或者环境依赖有问题长期不跑说明它已经失去价值。定期清理和优化用例比一味新增用例要重要得多。自动化测试的核心不是用例数量而是这套用例能不能持续稳定地帮你发现回归问题这个标准从第一天建框架到最后一天维护从来没有变过。