用Pytest重构Selenium自动化测试：从样板代码到高效工程-北京尧图网络

让Selenium自动化测试变简单的Pytest实践做过UI自动化的人都体会过那种痛苦明明只是要写一个测试用例结果driver初始化、等待元素、异常截图加上浏览器版本适配光这些样板代码加起来就有几十行。更难受的是用例越来越多一个浏览器会话挫得不行重启又费时。我最初写Selenium脚本用的是unittest后来换成pytest整个工程的可维护性可以说直接上升了一个台阶。这篇文章专门聊聊怎么用pytest这套体系来梳理、简化、重构你的Selenium测试让它从“堆代码”变成真正可以长期维护的工程。如果你是刚接触自动化测试的初级同学或者是被大量重复代码缠住的测试开发甚至是准备给团队搭建一套统一测试框架的负责人都可以从这篇文章里拿走对应的方案和避坑细节。我会从选型逻辑、fixture设计思路、具体落地方案到常见的坑全部讲清楚。1. 为什么是pytest而不是unittest很多同学上手Selenium的时候会先接触到unittest因为大部分教程都是这么写的。但一旦用例数量超过几十个你就会发现unittest的封装风格非常笨重必须继承TestCase类、只能通过类的继承来共享setup/teardown、断言方式单一、参数化支持很弱。我遇到过最大的痛点是当登录流程需要用在十几个测试模块里每个模块都要单独实现一个setUp方法很正常代码冗余非常严重。pytest在这几个方面有本质差异天然的函数式风格测试用例就是普通函数不强制继承任何基类写起来很轻。fixture机制依赖注入的方式替代了setUp和tearDown可以精确到用例级、模块级、会话级可以多次嵌套和组合。断言简单直接直接使用Python的assert语句也能配合pytest.raises处理异常断言不用记一堆assertEqual、assertTrue。插件生态完善报告、失败重跑、并行执行、参数化在很多场景下都是现成的插件不用自己造轮子。拿我们实际项目来说原来用unittest写一个登录相关的用例setUp里要写driver初始化、打开浏览器、登录操作tearDown里还要处理截图和退出一套下来80行代码有效用例逻辑也就20行。换成pytest之后driver的创建和销毁交给fixture登录变成一个公共fixture测试函数本身只需要关心业务行为和断言代码量直接砍掉一半。另外还有一个很实际的好处pytest对断言失败的处理更细腻。当你在一个多步骤的用例中断言失败pytest的输出会让你迅速定位到具体是哪一行挂的哪个断言实际值是什么。配合--pdb选项甚至可以直接调起调试器这对于排查Selenium那种“元素没找到”的诡异问题帮助特别大。2. 核心fixture设计与conftest.py布局conftest.py是pytest里最容易被低估的文件。很多人以为它只是放全局fixture的地方实际上它的层级机制决定了整个测试工程的组织方式。conftest.py是可以嵌套的也就是说你可以在根目录放一个在某个业务子模块下再放一个嵌套的conftest只对同一层级及以下的测试文件生效。这给了我们一个非常好的约定权限设计结构根目录conftest.py只放最通用的fixture比如driver的创建与销毁、全局配置读取、日志和报告的钩子。业务模块层的conftest.py放这个业务模块独有的前置操作比如用户模块的登录态、订单模块的测试数据准备。小范围的公共步骤尽量放在测试文件内部定义能不放conftest就不放避免conftest过度膨胀。在实操中我推荐把driver封装成一个带作用域的fixture并且配合yield返回driver实例这样可以在用例结束后的teardown阶段统一处理浏览器的关闭。你千万不要在driver创建的时候把这个逻辑写进每个测试文件里一旦浏览器启动参数要改动你就要全局搜索替换。一个比较典型的conftest里driver fixture长这样import pytest from selenium import webdriver from selenium.webdriver.chrome.options import Options pytest.fixture(scopefunction) def driver(): chrome_options Options() chrome_options.add_argument(--headlessnew) chrome_options.add_argument(--window-size1920,1080) chrome_options.add_argument(--ignore-certificate-errors) chrome_options.add_argument(--disable-gpu) driver webdriver.Chrome(optionschrome_options) driver.implicitly_wait(10) yield driver driver.quit()注意scopefunction这个值。如果你的用例没有涉及并发或者每个用例需要完全干净的浏览器上下文那用function作用域最安心。如果用例之间有明确的先后依赖关系可以调整成scopemodule或scopesession但这样做一定要想清楚因为这意味着上一个用例对于浏览器状态的污染会传递给下一个用例排查问题的时候非常头疼。我个人的习惯是日常回归用function作用域需要执行效率的场景才考虑module或session级别并且只对无状态的读取型用例做升级。还有一个容易踩坑的点implicitly_wait设置成全局的10秒看起来没问题但如果你在个别用例里需要更长或者更短的等待就没办法用局部覆盖的方式去改因为你拿到的driver已经被这个fixture设置好了。更优雅的做法是封装成显示等待的工具函数而不是依赖全局隐式等待。后面第4部分我会单独展开等待这个话题。3. 五步搭出一套简洁的Selenium测试工程先把整体的落地路径说一下这个路径不是我拍脑袋想的是带着团队里几个新人跑过好几轮的流程时间成本最低、出错率也最少。整个过程就像搭一套积木每一层都是固定结构。3.1 初始化项目结构与依赖管理无论项目大小我建议一上来就建立一个清晰的项目骨架。下面是我常用的目录结构test_project/ ├── conftest.py ├── pytest.ini ├── requirements.txt ├── testcases/ │ ├── test_login.py │ ├── test_order_flow.py │ └── test_user_center.py ├── pages/ │ ├── base_page.py │ ├── login_page.py │ └── order_page.py ├── data/ │ ├── login_data.json │ └── test_data.yaml ├── reports/ ├── logs/ └── utils/ ├── driver_factory.py └── wait_utils.pypages目录放的是页面对象模型data目录放测试数据utils放通用工具testcases是测试用例本体。不要觉得页面多一层封装很麻烦当你面对的是一个大型系统页面上元素的变更频繁到无法想象如果没有这一层隔离任何一次前端改动都会让你的测试用例全军覆没。requirements.txt里除了pytest和selenium我强烈建议加上pytest8.x.x selenium4.x.x pytest-html pytest-rerunfailures pytest-xdist pytest-ordering webdriver-managerwebdriver-manager这个库可以自动维护浏览器driver的版本省去每次浏览器升级带来的driver路径不匹配问题。如果你们公司用的是固定的测试环境也可以不用它。3.2 用Page Object模式封装页面操作这一节其实是在讲怎么写测试之外的代码但它直接决定了测试用例的简洁程度。没有Page Object的测试工程用例里通常充满了find_element和send_keys的裸调用读起来像流水账。有了一层页面对象之后测试用例读起来就变成了日常操作的自然语言。拿登录页举例我会封装成这样from selenium.webdriver.common.by import By from selenium.webdriver.remote.webdriver import WebDriver from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: def __init__(self, driver: WebDriver): self.driver driver self.username_input (By.ID, username) self.password_input (By.ID, password) self.login_button (By.CSS_SELECTOR, button[typesubmit]) def input_username(self, username: str): self.driver.find_element(*self.username_input).send_keys(username) def input_password(self, password: str): self.driver.find_element(*self.password_input).send_keys(password) def click_login(self): self.driver.find_element(*self.login_button).click() def login(self, username: str, password: str): self.input_username(username) self.input_password(password) self.click_login()注意我用了元组来表示定位器而不是直接调用find_element这么做的好处是定位信息集中在一个地方后续修改选择器只动一处。每个方法只在做一件事这样复用的颗粒度是最合适的。有些初学者会把每一步点击都写成一个方法结果每个方法只有一行又走向了另一个过度设计的极端。3.3 设计可复用的业务级fixture有了页面对象还不够我们通常还需要在用例之间共享更复杂的业务状态比如“已登录状态”或者“购物车里有三件商品”这种前置条件。把这部分做成fixture你的用例就能保持非常干净。pytest.fixture def login_page(driver): page LoginPage(driver) page.driver.get(https://your-test-site.com/login) return page pytest.fixture def logged_in_session(driver, login_page): 返回一个已完成登录的会话 login_page.login(os.getenv(TEST_USERNAME), os.getenv(TEST_PASSWORD)) return driver这里有个设计原则要记住fixture之间是可以互相依赖的pytest会自动根据函数参数解析依赖顺序。你可以把logged_in_session看作是login_page的上层fixture它在login_page完成页面导航的基础上继续执行登录操作。实际项目中我见过不少直接把登录写在conftest的module级别fixture里的我觉得没毛病但要注意一个细节如果登录态的维持依赖于浏览器的cookie你的fixture最好通过操作cookie来创建登录态而不是每次重新走一次UI登录。UI登录的成本要高一个量级而且执行不稳定。3.4 用参数化告别数据重复的用例参数化是pytest对比unittest最大的优势之一。想象你要测不同账号类型的登录逻辑普通用户、管理员、被封禁的用户如果一个个去写用例你会得到三个除了数据以外完全相同的函数。用参数化一个函数就能覆盖所有场景。一个标准的参数化登录用例import pytest from pages.login_page import LoginPage pytest.mark.parametrize(username,password,expected_result, [ (user_normal, pass123, 登录成功), (admin001, admin123, 登录成功), (blocked_user, blocked123, 登录失败账号已被锁定), ]) def test_login_scenarios(driver, username, password, expected_result): login_page LoginPage(driver) login_page.driver.get(https://your-test-site.com/login) login_page.login(username, password) # 这里根据页面结果去断言 assert expected_result in driver.page_source有几个细节值得注意参数顺序要和函数参数顺序保持一致写反了你会查出半天找不到原因。不要把参数化的数据放在、直接在测试函数里写一堆字典。数据量小还好数据量大的话挪到data目录下的文件里用pytest的钩子或者循环方法去动态加载。expect结果尽量用页面上的稳定元素去校验而不是把整个page_source拉出来做字符串断言。page_source的变动太频繁了今天加个异步加载内容就会让断言失效。3.5 组装测试报告与执行策略等测试工程到了一定规模你会开始关心两个东西执行耗时和报告呈现。pytest-xdist并行执行插件解决前者pytest-html或allure解决后者。结合pytest.ini可以做一套比较灵活的默认策略。一个我自己在用的pytest.ini配置[pytest] testpaths testcases addopts -v -s --htmlreports/report.html --self-contained-html markers smoke: 冒烟测试 regression: 回归测试 slow: 慢速测试注意addopts这里不建议写死-n auto这种并行参数因为不是所有场景都适合并行。UI自动化不像纯接口测试每个worker都会启动一个独立的浏览器内存开销很大。我一般在CI里单独指定并行参数本地调试时反而不开并行。pytest testcases/test_login.py -m smoke -n 2 --distloadscope这里用--distloadscope可以让属于同一个模块的用例尽量分配到同一个worker上避免多个worker同时操作同一个浏览器会话导致互相干扰。4. 等待策略Selenium测试稳定性最大的一环如果要从所有Selenium自动化的坑里挑一个最高频的那绝对就是等不到元素。头部网站的前端几乎都是异步渲染的你find_element的时候页面可能刚发出请求数据还没回来这时候元素自然不会存在。处理不当测试脚本就像是在一个加载中的网页上盲点错误频出。4.1 显式等待和隐式等待别混用隐式等待是driver级别的设置设置之后driver.find_element在元素未出现时会轮询等待时间到了才抛异常。显式等待是针对某个条件的WebDriverWait比如“可点击”“可见”“包含某段文本”。这两者的实现机制是独立的但混用会产生一些奇怪的叠加效果等待时间变得可控性很差你很难推断某个动作到底花了多长时间。我的做法是不做全局隐式等待全部用显式等待封装成一个工具函数。这样每条定位语义都很明确超时时长也能按场景调整。一个现成的wait_utils封装from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def wait_and_click(driver, locator, timeout10): element WebDriverWait(driver, timeout).until( EC.element_to_be_clickable(locator) ) element.click() return element def wait_and_input(driver, locator, text, timeout10): element WebDriverWait(driver, timeout).until( EC.visibility_of_element_located(locator) ) element.send_keys(text) return element看到这里你可能会想这不就是把find_element换了个壳吗但壳与壳的区别在于它强制你在编写用例时就思考每个操作依赖的前置条件是什么。点击前要“可点击”输入前要“可见”这比一切等待方式都有确定性。4.2 隐性轮询条件的选择显式等待里的expected_conditions有很多种我踩过不少坑最多的就是误用presence_of_element_located和visibility_of_element_located。前者只代表元素在DOM树中存在哪怕它在页面之外、不可见、宽高为0都会返回True。后者要求元素可见且占据页面空间。如果我要操作一个按钮等待“可点击”是比上面两个都严格的因为它除了可见之外还要求元素处于可交互状态。需要特别注意的是无论选哪种条件在页面单页应用SPA里都要警惕另一个问题需要等待的目标元素可能很早就出现在DOM里但它的文本或者状态还没更新完成。这种情况下最稳的做法是轮询校验元素内的文本自己写一个lambda函数而不是依赖封装好的条件WebDriverWait(driver, 15).until( lambda d: d.find_element(*locator).text.strip() 预期文本 )这种写着虽然丑但在异步渲染下极其好用因为它等的不是“存在”而是“内容正确”。5. 常见问题排查与避坑实录这一部分记录的全是我自己实际踩过的坑有些是安装配置层面的有些是代码组织层面的。每一条后面都会给排查思路希望你能直接抄作业。5.1 driver启动失败的排查清单每次换一台机器跑测试driver启动失败几乎是必现的问题。报错信息通常五花八门什么chromedriver timeout、session not created、cannot find Chrome binary。我把排查顺序固定成一套检查系统里Chrome的版本和chromedriver的版本是否匹配。确认chromedriver是否在PATH里或者直接用webdriver-manager自动下载。查看是不是多版本浏览器共存导致默认打开的浏览器和driver不匹配。如果在容器或CI环境里运行检查是不是缺少必要的依赖库常见的是libnss3、libgconf等。这四个问题里版本不匹配覆盖了八成以上的启动失败。用webdriver-manager之后这个问题基本从源头被解决了它会在运行时检测本地浏览器版本并自动下载对应的driver。5.2 用例相互影响的常见场景UI自动化用例之间互相污染是最让人抓狂的一类问题。常见表现是单独跑某个用例没问题一跑全量就挂。根源通常有三个浏览器会话没有隔离如果你用了function作用域的driver这不应该发生但如果你自己手写了一个启动浏览器的setUp而且放在module级两个模块就会互相污染。测试数据冲突每个用例都在往数据库写“测试用户”、“测试订单”跑完了不清理第二个用例拿到的就是脏数据。全局状态残留比如某个用例把界面语言切换了下一个用例掉了页面的初始语言版本。对于第三种情况我推荐在fixture的teardown阶段做一次页面状态的快照恢复而不是依赖用例自己清理。把清理逻辑放在fixture里比放在用例末尾更可靠因为用例如果中途失败末尾的清理逻辑很可能不会执行但fixture的teardown一定会执行。5.3 失败用例的现场信息收集用例挂了之后你第一反应是想知道那个时刻的页面长什么样。但等你手动打开浏览器去看页面早变了。所以在fixture的teardown阶段、或者pytest的钩子函数里自动收集现场信息是非常重要的一环。用pytest的pytest_runtest_makereport钩子来实现自动收集是一个比较标准的方案pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): outcome yield report outcome.get_result() if report.when call and report.failed: driver item.funcargs.get(driver) if driver: # 截图存到指定目录 driver.save_screenshot(freports/screenshots/{item.name}.png)这个方案最大的好处就是对现有用例代码零侵入你不需要在每个用例里手动处理失败分支。加上日志记录驱动本身的console日志一套相对完整的现场信息就够了。我建议在截图命名里带上时间戳否则同一用例多次失败会互相覆盖保留不了历史记录。5.4 并行执行时踩过的性能坑pytest-xdist用起来很方便-n 4就能让用例并行跑。在接口测试里这是神器但在UI自动化里四个worker意味着同时四个浏览器窗口操作目标服务器这对被测系统的压力是不可忽视的。我遇到过一次并行跑完之后后台服务因为session数超限直接崩溃的。建议做到三点第一只对无业务依赖的用例开启并行第二把并行的worker数量控制在1到2之间除非被测服务明确能扛住更高并发第三搭配pytest-ordering用插件标出哪些用例必须串行执行比如只能顺序执行的支付流程。5.5 Selenium 4与旧代码的兼容注意Selenium 4发布之后很多旧代码还是能跑但之前的find_element_by_id这类方法被标记为废弃直到后来的版本被移除。如果你还在用旧写法升级之后会遇到批量报错。解决方案很简单把代码里所有find_element_by_xxx统一改成find_element(By.XXX, xxx)。这一步工作量很大但建议做一次彻底迁移毕竟旧的API在被清除之后修复成本只会更高。另外一个Selenium 4带来的好东西是相对定位器Relative Locator可以用above、below、near等关系来定位元素在处理某些结构没法加稳定class的页面时这个能力非常实用。虽然不算高频但关键时刻能救命。6. 一些很实用的组合打法把pytest和selenium结合起来它的价值远不只是“替代unittest”。你可以在这个基础上继续叠加一些工作流和效率工具让整个UI自动化的产出质量更高。6.1 基于标签管理用例分层我在上一节讲过pytest.ini里可以自定义marker。实际使用里我会建议分成烟雾测试、回归测试、慢速测试三层。CI流程里每天跑一次全量回归但是每次代码提交后只跑冒烟层。通过-m smoke这样的命令测试工程可以非常灵活地被组合进多个流水线场景。pytest -m smoke --tbshort -q pytest -m regression and not slow -n 2组合标记的好处是可以精确控制每一次执行的粒度和时间成本。这在项目后期尤其重要因为全量UI用例的数量一旦超过三百个即使并行跑耗时也不是个位数分钟能解决的。6.2 失败自动重跑的正确姿势pytest-rerunfailures插件给了我们失败用例自动重跑的能力。但你得想清楚为什么要重跑。UI自动化里有些失败是暂时性的网络抖动、元素加载延迟重跑确实能把这些误报消除掉。可如果是真实的业务逻辑变更导致的失败重跑一百次也是失败只会掩盖问题。所以建议设置pytest --reruns 2 --reruns-delay 5同时一定配合报告插件把重跑成功的用例标记出来。这样你回顾报告时既能知道最终结果是绿色又能看到哪些用例曾经出现过不稳定方便后续去优化这些用例本身的稳定性而不是放任不管。6.3 截图报告内嵌的另类用法上一节讲了失败截图自动存盘但你要知道pytest-html的报告里是可以直接内嵌图片的。把截图以base64的形式塞进报告整个报告就自带现场照片同事们看完报告都不用再翻文件夹找截图。实现方式就是在conftest里写一个pytest_html报告追加的钩子把刚才的截图文件转换成base64拼进extra数据。我用了之后最大的感受是排查效率变高了很多尤其是给开发和产品看测试报告的时候一张截图抵得上一百字描述。6.4 断言失败后是否继续执行同一用例pytest默认在断言失败时立即终止当前用例。这对大多数场景是对的因为后续步骤已经没有了执行的意义。但有些场景你会希望收集更多的失败信息比如进入一个页面之后你同时校验标题、面包屑、按钮文案、表格数据失败一个还要知道其他几个是不是也挂了。这种情况可以用pytest-assume插件来实现from pytest import assume def test_multi_assertions(driver): with assume: assert driver.title 我的站点 with assume: assert driver.find_element(By.ID, crumb).text 首页订单这样即使第一个断言失败用例还会继续执行并且最终报告里会列出所有失败的断言而不是只看到第一个错误就停下来。7. 最后再分享一个稳定性提升小技巧我最后想提的是一个很不起眼但极其影响UI自动化稳定性的细节浏览器启动参数。很多默认配置下Chrome启动会有各种动画效果、通知弹窗、密码提示这些都会干扰Selenium的元素定位。强烈建议在driver初始化时把下面这一组参数全部加上chrome_options.add_argument(--disable-notifications) chrome_options.add_argument(--disable-popup-blocking) chrome_options.add_argument(--disable-infobars) chrome_options.add_argument(--no-first-run) chrome_options.add_experimental_option(prefs, { credentials_enable_service: False, profile.password_manager_enabled: False, profile.default_content_setting_values.notifications: 2, })这些参数看上去都是细枝末节但在跑三五百条用例时每一个未关闭的通知弹窗都可能在某一条用例里变成那个诡异的“看不到按钮”。把基础环境做到最干净你才能说测试用例的失败是真实的业务问题而不是环境干扰。另一个很实用的点是如果你在本地开发调试建议不要开着headless模式。我见过不少人在本地也一直用headless跑结果元素交互时哪些细节有问题根本看不见排错全靠猜。开发时带界面运行调试完再切回headless做CI。这种切换只需要改一下fixture里的启动参数成本很低收益却很实在。选择pytest这套体系不是在炫技它就是把那些本来不该写的重复代码去掉把所有的注意力留给真正有业务价值的用例逻辑本身。希望这些经验能让你少走几趟我走过的弯路。

用Pytest重构Selenium自动化测试：从样板代码到高效工程

相关推荐

PyTorch深度学习框架实战：从动态图原理到模型部署全流程

上帝视角：复杂系统统一观测层的设计与性能优化实战

UI自动化面试高频考点：Selenium、PO模式与稳定性排查

更多资讯

Themida WinLicense脱壳实战：V1.8与V2.X工具链选择与避坑指南

相机标定板选型全解析：棋盘格、圆点与ArUco/ChArUco对比

STM32直流电机PID闭环控制实战：从编码器测速到参数整定

行波测距仿真全解析：小波分解与卡伦堡变换在配网故障定位中的应用

洗衣机里的“智慧大脑”：单片机控制源码与状态机全解析

AI论文写作工具有哪些？4类工具实测拆解与避坑指南

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？