1. 项目概述与核心价值最近在团队里做了一次技术分享主题就是如何用 pytest 和 Selenium 这套组合拳高效地编写网页 UI 自动化脚本和用例。我发现很多刚开始接触自动化的同学要么被各种框架和概念绕晕要么写出来的脚本脆弱不堪维护成本极高。其实UI 自动化测试的核心目标很明确用机器模拟人的操作验证网页功能是否正常并且这个过程要稳定、可重复、易维护。pytest 和 Selenium 的组合恰好能很好地满足这些要求。pytest 提供了强大灵活的测试组织、运行和报告能力而 Selenium 则是操控浏览器的“金手指”。这篇文章我会从一个实战者的角度拆解如何从零开始搭建这套体系并分享那些在官方文档里不会写的“踩坑”经验和设计思路。无论你是测试工程师、开发同学想自测前端还是对自动化感兴趣的学习者这篇内容都能给你一套可直接落地的方案。2. 环境搭建与核心工具选型解析2.1 Python 与包管理工具避坑指南一切开始之前一个干净、可管理的 Python 环境是基石。我强烈建议使用venv或conda创建独立的虚拟环境这能避免项目间的包版本冲突。如果你在 Windows 的 PowerShell 中遇到类似无法将“pip”项识别为 cmdlet、函数、脚本文件...的错误这通常是系统执行策略限制所致。解决方法是以管理员身份打开 PowerShell执行Set-ExecutionPolicy RemoteSigned选择Y。这个操作放宽了脚本执行权限让 pip、npm 等工具能正常运行。但请注意这只是一个临时的本地环境解决方案在生产服务器上需谨慎评估安全策略。注意更改执行策略存在安全风险仅建议在个人开发或测试环境中进行。完成后可考虑改回默认的Restricted策略。安装核心依赖非常简单。在你的项目虚拟环境中执行以下命令pip install pytest selenium webdriver-manager这里特别提一下webdriver-manager它是一个神器。传统方式需要手动下载不同浏览器对应版本的驱动如 chromedriver并配置 PATH过程繁琐且易出错。webdriver-manager能自动检测你本地安装的浏览器版本并下载匹配的驱动极大简化了环境配置。2.2 Selenium 与浏览器驱动详解Selenium 本身是一个用于 Web 应用程序测试的工具它提供了一组 API通常称为 WebDriver API允许我们用代码如 Python向浏览器发送指令模拟点击、输入、跳转等操作。而浏览器驱动如 ChromeDriver, GeckoDriver则是 Selenium 和真实浏览器Chrome, Firefox之间的“翻译官”和“桥梁”。为什么需要驱动因为浏览器厂商如 Google, Mozilla为了安全和控制不会直接暴露一个让外部程序随意操控的接口。他们各自实现了一套远程控制协议如 Chrome DevTools Protocol。Selenium WebDriver 定义了一套统一的、面向多种浏览器的标准 API。浏览器驱动则负责1. 启动并管理浏览器进程2. 接收来自 Selenium 的标准 API 调用3. 将其“翻译”成自家浏览器能听懂的原生协议指令并执行。使用webdriver-manager后初始化驱动的代码变得非常简洁from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager # 自动管理 ChromeDriver service Service(ChromeDriverManager().install()) driver webdriver.Chrome(serviceservice)这段代码会检查本地是否有匹配的 chromedriver没有则自动下载省去了手动管理的麻烦。2.3 Pytest 框架优势与基础概念为什么是 pytest 而不是 unittest 或其他从我多年的经验看pytest 有几点碾压性优势零样板代码不需要继承任何类写一个以test_开头的函数就是一个用例。丰富的断言直接使用 Python 原生的assert语句断言失败时信息清晰。强大的 Fixture这是 pytest 的灵魂用于提供测试依赖如浏览器驱动实例、执行前置后置操作如打开/关闭浏览器、管理测试数据等实现高度的代码复用和模块化。灵活的插件体系有海量插件支持如生成美观的 HTML 报告 (pytest-html)、控制用例执行顺序 (pytest-ordering)、分布式执行 (pytest-xdist) 等。参数化测试轻松实现用多组数据驱动同一个测试逻辑。一个最简单的 pytest 用例长这样# test_simple.py def test_example(): assert 1 1 2在命令行运行pytest test_simple.py即可。对于 UI 自动化我们会将 Selenium 的操作封装在测试函数中并利用 Fixture 来管理浏览器生命期。3. 自动化框架核心设计PO模型与Fixture3.1 为什么必须使用Page Object (PO) 模型如果你写的脚本是那种在测试函数里直接堆满find_element_by_id(“username”).send_keys(“admin”)的代码那么当页面元素 ID 一变你就得满世界去修改所有用到这个元素的测试用例。这种脚本的维护成本是灾难性的。Page Object (PO) 模型的核心思想是将页面封装成对象将页面元素定位和元素操作封装成对象的方法。测试用例脚本只关心业务逻辑和测试数据不关心具体的元素定位细节。这样做的好处高可维护性页面元素定位符只在一个地方Page 类定义。页面变动时只需修改对应的 Page 类。高可读性测试用例读起来像自然语言例如login_page.input_username(“admin”)。高复用性页面操作逻辑被封装可以在多个测试用例中复用。3.2 基础PO模型实现示例我们以一个登录页面为例。首先定义页面元素定位和基本操作# pages/login_page.py from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC class LoginPage: # 定位器 (Locators) USERNAME_INPUT (By.ID, ‘username’) PASSWORD_INPUT (By.ID, ‘password’) LOGIN_BUTTON (By.XPATH, ‘//button[type“submit”]’) ERROR_MSG (By.CLASS_NAME, ‘alert-error’) def __init__(self, driver): self.driver driver self.wait WebDriverWait(driver, 10) # 显式等待 def open(self, url): self.driver.get(url) return self def input_username(self, username): # 使用显式等待确保元素可交互 element self.wait.until(EC.element_to_be_clickable(self.USERNAME_INPUT)) element.clear() element.send_keys(username) return self def input_password(self, password): element self.wait.until(EC.element_to_be_clickable(self.PASSWORD_INPUT)) element.clear() element.send_keys(password) return self def click_login(self): self.wait.until(EC.element_to_be_clickable(self.LOGIN_BUTTON)).click() def get_error_message(self): try: return self.wait.until(EC.visibility_of_element_located(self.ERROR_MSG)).text except: return None这里我使用了WebDriverWait配合expected_conditions进行显式等待这是编写稳定 UI 自动化脚本的黄金法则。绝对要避免使用time.sleep()进行固定休眠那会导致测试速度慢且不可靠。方法链return self的写法可以让测试用例的调用更加流畅。3.3 Pytest Fixture 设计管理浏览器会话Fixture 是 pytest 用于提供测试依赖的机制。对于 UI 自动化最核心的 Fixture 就是管理 WebDriver 实例。# conftest.py import pytest from selenium import webdriver from selenium.webdriver.chrome.service import Service from webdriver_manager.chrome import ChromeDriverManager pytest.fixture(scope“class”) def driver(): “”“创建并返回一个 WebDriver 实例。scope‘class’ 表示每个测试类共享同一个driver。”“” # 配置 Chrome 选项 chrome_options webdriver.ChromeOptions() chrome_options.add_argument(‘--headless’) # 无头模式不显示浏览器窗口 chrome_options.add_argument(‘--no-sandbox’) chrome_options.add_argument(‘--disable-dev-shm-usage’) chrome_options.add_argument(‘--disable-gpu’) chrome_options.add_argument(‘--window-size1920,1080’) service Service(ChromeDriverManager().install()) driver_instance webdriver.Chrome(serviceservice, optionschrome_options) yield driver_instance # 测试执行部分 # 测试执行完毕后执行清理工作 driver_instance.quit()将这段代码放在项目根目录或测试目录下的conftest.py文件中pytest 会自动发现并加载其中的 Fixture。scope参数非常关键“function”(默认): 每个测试函数都重新创建/退出一次浏览器。隔离性好但速度慢。“class”: 同一个测试类中的所有方法共享一个浏览器实例。适合将一系列相关操作放在一个类里。“module”: 同一个.py文件中的所有测试共享一个实例。“session”: 整个 pytest 执行会话只启动一次浏览器所有测试共用。速度最快但测试间可能相互影响需要做好状态清理。我通常根据测试场景选择“class”或“function”。示例中加入了无头模式 (--headless) 参数这在 CI/CD 流水线或服务器上运行时非常有用因为没有图形界面。yield关键字将 Fixture 分为设置yield 之前和清理yield 之后两部分确保了浏览器无论如何都会正确关闭避免资源泄漏。4. 测试用例编写实战与高级技巧4.1 编写第一个健壮的测试用例结合 PO 模型和 Fixture一个完整的测试用例文件如下# tests/test_login.py import pytest from pages.login_page import LoginPage class TestLogin: “”“登录功能测试集”“” pytest.mark.parametrize(“username, password, expected”, [ (“admin”, “admin123”, “Dashboard”), # 正确用例 (“wrong”, “wrong123”, “Invalid credentials”), # 错误用例 (“”, “admin123”, “Username is required”), # 用户名为空 ]) def test_login_with_different_data(self, driver, username, password, expected): “”“使用参数化测试多组登录数据”“” login_page LoginPage(driver) # 流畅的链式调用 login_page.open(“https://your-app.com/login”) .input_username(username) .input_password(password) .click_login() if username “admin” and password “admin123”: # 登录成功断言页面标题或某个成功元素 assert expected in driver.title # 或者更精确地等待某个成功标识出现 # WebDriverWait(driver, 10).until(EC.title_contains(expected)) else: # 登录失败断言错误信息 actual_error login_page.get_error_message() assert actual_error is not None assert expected in actual_error def test_login_success_navigation(self, driver): “”“测试登录成功后页面跳转和元素加载”“” login_page LoginPage(driver) login_page.open(“https://your-app.com/login”) .input_username(“admin”) .input_password(“admin123”) .click_login() # 假设登录后跳转到仪表盘有一个特定的欢迎元素 welcome_element WebDriverWait(driver, 15).until( EC.presence_of_element_located((By.ID, “welcome-msg”)) ) assert “Welcome, admin” in welcome_element.text # 进一步验证导航菜单是否加载 assert driver.find_element(By.LINK_TEXT, “Reports”).is_displayed()这个例子展示了几个关键点参数化测试使用pytest.mark.parametrize装饰器用多组数据驱动同一个测试逻辑避免了写多个重复的测试函数。清晰的断言断言内容明确并且针对成功和失败场景有不同的验证逻辑。页面对象的使用测试函数里没有出现任何具体的find_element定位代码业务逻辑清晰。显式等待在 Page Object 和测试用例中都合理使用了显式等待确保元素状态稳定后再操作或断言。4.2 元素定位策略与等待机制深入Selenium 提供了多种定位元素的方法By.ID, By.NAME, By.XPATH, By.CSS_SELECTOR, By.LINK_TEXT 等。我的经验是首选 ID 和 Name如果元素有稳定且唯一的 ID 或 Name这是最快、最可靠的选择。慎用 XPathXPath 功能强大但脆弱。避免使用绝对路径以/开头尽量使用相对路径和属性组合。例如//button[id‘submit’ and text()‘Login’]比/html/body/div[3]/form/button要好得多。浏览器开发者工具的“Copy - Copy XPath”功能生成的往往是绝对路径尽量不要直接使用。善用 CSS Selector通常比 XPath 性能更好语法也更简洁。例如input.form-control[name‘email’]。关于等待必须理解三种方式强制等待time.sleep(n)。禁止在正式脚本中使用它是导致测试缓慢和不稳定的元凶。隐式等待driver.implicitly_wait(10)。设置一个全局的等待时间在查找任何元素时如果元素没有立即出现WebDriver 会轮询等待至多这个时长。它的问题是不够灵活并且对某些条件如元素可点击、元素消失无效。我通常不推荐作为主要等待机制因为它会和显式等待产生不可预知的交互。显式等待WebDriverWait(driver, timeout).until(condition)。这是推荐的最佳实践。它可以等待特定的条件成立如元素可见、可点击、元素数量增加、文本出现等。它更精确只在需要的地方等待。我常用的条件有presence_of_element_located: 元素出现在 DOM 中不一定可见。visibility_of_element_located: 元素可见。element_to_be_clickable: 元素可见且可点击。text_to_be_present_in_element: 元素中包含特定文本。invisibility_of_element_located: 元素不可见或从 DOM 中移除。4.3 测试数据分离与管理将测试数据硬编码在测试用例中是不可取的。我常用的数据管理方式有Pytest 参数化如上例所示适合数据量小、逻辑简单的场景。JSON/YAML 文件将测试数据存储在外部文件中。# data/login_data.json [ {“username”: “admin”, “password”: “admin123”, “expected”: “success”}, {“username”: “locked_user”, “password”: “pass”, “expected”: “locked”} ] # 在 conftest.py 或用例中读取 import json import pytest def load_login_data(): with open(‘data/login_data.json’, ‘r’, encoding‘utf-8’) as f: return json.load(f) pytest.mark.parametrize(“data”, load_login_data()) def test_login_with_json_data(driver, data): # 使用 data[‘username’], data[‘password’] 等环境变量与配置文件用于管理不同环境测试、预生产、生产的 URL、账号等配置信息。可以使用python-dotenv或configparser。5. 框架增强报告、并发与CI/CD集成5.1 生成美观的HTML测试报告pytest 原生输出是控制台文本不便于存档和分享。使用pytest-html插件可以生成详细的 HTML 报告。pip install pytest-html运行测试时添加参数pytest tests/ --htmlreport.html --self-contained-html--self-contained-html会将 CSS 和图片嵌入到单个 HTML 文件中方便传递。报告里会包含测试通过/失败状态、执行时间、错误追溯信息甚至可以在 Fixture 中通过driver.save_screenshot(‘path/to/screenshot.png’)在测试失败时自动截图并将截图嵌入报告这对调试 UI 问题至关重要。我们可以在conftest.py中写一个 Fixture 来自动化失败截图# conftest.py import pytest from datetime import datetime pytest.hookimpl(hookwrapperTrue) def pytest_runtest_makereport(item, call): “”“Hook函数用于在测试报告生成时执行操作。”“” outcome yield report outcome.get_result() if report.when “call” and report.failed: # 仅当测试执行阶段失败时才截图 # 需要能从item中获取到driver实例这要求driver fixture有特定名字或通过其他方式传递 # 一种常见做法是将driver存储在item的请求上下文中 if hasattr(item, ‘_driver’): driver item._driver timestamp datetime.now().strftime(“%Y%m%d_%H%M%S”) screenshot_name f”screenshot_{item.name}_{timestamp}.png” driver.save_screenshot(screenshot_name) # 将截图路径添加到html报告 if hasattr(report, ‘extra’): from pytest_html import extras report.extra.append(extras.image(screenshot_name))5.2 使用pytest-xdist实现测试并发当用例数量多时顺序执行会非常耗时。pytest-xdist插件可以实现分布式测试在多核 CPU 上并行运行用例大幅缩短反馈时间。pip install pytest-xdist运行命令pytest tests/ -n auto-n auto会自动检测 CPU 核心数并创建相应数量的 worker 进程。需要注意的是并行测试时测试用例之间必须是独立的不能有共享状态如依赖同一个全局变量或数据库的特定序列。我们的 Fixture 如果设置scope“session”或“module”在并行时可能会出现问题因为每个 worker 进程有自己的 Python 解释器和内存空间。通常为并行测试设计的 Fixture 其scope应设为“function”或“class”并且每个 worker 需要能够独立访问其依赖的资源如独立的浏览器实例、临时的测试数据库。5.3 集成到CI/CD流水线以GitHub Actions为例自动化测试只有集成到持续集成/持续部署流程中才能最大化其价值。以下是一个简单的 GitHub Actions 工作流配置示例它会在每次代码推送时自动运行 UI 自动化测试。# .github/workflows/ui-test.yml name: UI Automation Tests on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: ‘3.9’ - name: Install system dependencies (for Chrome) run: | sudo apt-get update sudo apt-get install -y wget unzip wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add - echo “deb [archamd64] http://dl.google.com/linux/chrome/deb/ stable main” | sudo tee /etc/apt/sources.list.d/google-chrome.list sudo apt-get update sudo apt-get install -y google-chrome-stable - name: Install Python dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt # 你的依赖文件 - name: Run UI tests with pytest run: | # 在无头模式下运行测试并生成报告 pytest tests/ --htmlreport.html --self-contained-html -n auto - name: Upload test report uses: actions/upload-artifactv3 if: always() # 即使测试失败也上传报告 with: name: ui-test-report path: report.html这个工作流做了几件事1. 准备 Ubuntu 环境2. 安装 Chrome 浏览器因为我们要用 ChromeDriver3. 安装 Python 依赖4. 并行运行所有测试5. 将生成的 HTML 报告上传为工件供后续查看。6. 常见问题排查与稳定性提升技巧6.1 元素定位失败问题深度排查这是 UI 自动化中最常见的问题。当NoSuchElementException或超时异常出现时不要急着改代码按以下步骤排查确认页面加载完成是不是页面还没加载完就开始找元素在操作前加入一个针对页面关键元素的显式等待。检查定位器在浏览器的开发者工具 Console 中用 JavaScript 验证你的定位器是否正确。例如对于 XPath//button[id‘submit’]在 Console 中输入$x(“//button[id‘submit’]”)看是否能找到元素。对于 CSS Selector用document.querySelector(“button#submit”)。是否存在iframe如果目标元素在iframe内必须先使用driver.switch_to.frame(frame_reference)切换到对应的 iframe 中才能定位其中的元素。操作完后记得用driver.switch_to.default_content()切回主文档。是否存在新窗口/标签页点击某个链接后打开了新窗口使用driver.switch_to.window(driver.window_handles[-1])切换到最新打开的窗口。元素是否被遮挡有时候元素虽然存在且可见但被其他元素如弹窗、遮罩层覆盖导致无法交互。此时element_to_be_clickable会失败。需要检查 DOM 结构或者尝试用ActionChains进行点击。动态ID或类名现代前端框架如 React, Vue经常生成动态的 ID 或类名。避免使用包含动态哈希的部分。尝试使用更稳定的属性如>from selenium.webdriver.common.alert import Alert # 等待弹窗出现并接受 Alert(driver).accept() # 或取消 # Alert(driver).dismiss() # 或输入文本针对prompt # alert Alert(driver) # alert.send_keys(“text”) # alert.accept()注意操作弹窗会阻塞 WebDriver 执行必须处理掉弹窗才能继续。下拉选择框 (Select)不要用click()模拟使用Select类。from selenium.webdriver.support.ui import Select select_element driver.find_element(By.ID, “country”) select Select(select_element) select.select_by_visible_text(“China”) # 按文本选择 # select.select_by_value(“cn”) # 按value属性选择 # select.select_by_index(1) # 按索引选择鼠标悬停 (Hover)需要ActionChains。from selenium.webdriver.common.action_chains import ActionChains menu driver.find_element(By.ID, “dropdown-menu”) ActionChains(driver).move_to_element(menu).perform() # 然后等待或定位出现的子菜单文件上传对于input type“file”元素直接使用send_keys()传入文件的绝对路径即可。upload_element driver.find_element(By.XPATH, “//input[type‘file’]”) upload_element.send_keys(“/home/user/Desktop/test_image.jpg”)绝对不要尝试用click()去触发系统文件选择对话框那是 WebDriver 无法控制的。6.3 提升脚本稳定性的高级策略重试机制对于某些偶发性的网络波动或前端渲染延迟导致的失败可以引入重试。pytest 有pytest-rerunfailures插件。pip install pytest-rerunfailures pytest --reruns 3 --reruns-delay 2 # 失败后重试3次每次间隔2秒但需谨慎使用重试会掩盖真正的稳定性问题。最好还是优化等待条件和定位策略。页面状态检测在关键步骤后加入对页面状态的断言确保操作达到了预期效果再进行下一步。例如点击保存按钮后等待“保存成功”的提示信息出现。使用更稳定的定位策略组合不要依赖单一的定位器。可以尝试组合使用比如先通过相对稳定的属性定位父元素再在其子节点中查找目标元素。隔离测试数据确保每个测试用例使用独立的数据避免用例间因数据依赖而失败。可以在 Fixture 中实现测试数据的创建和清理。pytest.fixture def test_user(driver): “”“创建一个临时测试用户测试后删除。”“” user_id create_user_via_api(“test_user”, “temp_pwd”) yield {“username”: “test_user”, “id”: user_id} delete_user_via_api(user_id)应对反爬和检测一些网站会检测 Selenium 的特征如window.navigator.webdriver属性。如果遇到可以尝试添加实验性选项来隐藏特征但请注意这可能违反网站的使用条款。chrome_options.add_experimental_option(“excludeSwitches”, [“enable-automation”]) chrome_options.add_experimental_option(‘useAutomationExtension’, False) # 更高级的隐藏可能需要用到 undetected-chromedriver 等第三方库7. 进阶思考Playwright vs Selenium 及未来方向在项目技术选型时你可能还会听到 Playwright 这个名字。它是由微软开源的一个较新的浏览器自动化库。简单对比一下两者的优缺点可以帮助你做出选择特性SeleniumPlaywright诞生时间老牌2004年较新2020年支持语言多Java, Python, C#, JS, Ruby等多JS/TS, Python, Java, .NET浏览器支持需各浏览器官方驱动支持 Chrome, Firefox, Safari, Edge等内置驱动统一 API支持 Chromium, Firefox, WebKit执行速度较慢通过JSON Wire Protocol较快通过CDP等现代协议自动等待需手动实现显式等待内置智能等待自动等待元素可操作录制工具有如Selenium IDE录制功能强大可生成健壮代码移动端通过Appium通过设备模拟对移动Web支持好社区生态极其庞大资源多问题易解决快速增长但相对较新上手难度中等需理解等待、驱动等概念相对简单API 设计更现代如何选择选择 Selenium 如果你的项目已经基于 Selenium 有大量积累团队非常熟悉其生态需要支持 Safari 等非 Chromium 系浏览器Playwright 的 WebKit 是打包版本与原生 Safari 有细微差别依赖某些特定的 Selenium 云服务提供商。考虑 Playwright 如果你是新项目追求更快的执行速度和更稳定的 API希望减少在等待和同步问题上花费的调试时间需要更好的移动端浏览器模拟测试欣赏其强大的代码录制和生成功能。我个人认为Selenium 凭借其悠久的历史和庞大的社区在很长一段时间内依然是企业级自动化测试的基石特别是对于需要复杂集成和定制化的场景。而 Playwright 代表了更现代、更一体化的设计思路对于新项目和个人学习而言其上手体验和开发效率可能更高。无论选择哪个理解自动化测试的核心思想PO模型、数据驱动、等待机制都是相通的这些经验可以无缝迁移。