企业级Playwright自动化测试框架：从POM设计到CI/CD集成实战

1. 项目概述：为什么需要一个企业级的Playwright框架？

如果你正在用Playwright写自动化测试脚本，可能会觉得它已经足够好用了——毕竟，相比Selenium，它的API更现代，速度也快得多。但当你需要把几十、上百个测试用例组织起来，交给团队不同成员去维护，并且要集成到CI/CD流水线里每天跑上几十遍时，你就会发现，光会写page.click()和page.fill()是远远不够的。脚本散落各处、浏览器配置五花八门、失败后的截图和日志找不到、测试数据互相污染……这些问题会迅速让自动化测试项目变得难以维护，最终沦为摆设。

这就是“构建框架”要解决的问题。它不是一个炫技的概念，而是一套实实在在的工程实践，目的是把那些零散的、脆弱的测试脚本，变成一套稳定、可维护、可协作的资产。一个企业级的框架，核心价值在于标准化和效率提升。它规定了大家怎么写用例、怎么配环境、怎么处理异常、怎么生成报告，让团队里的新人也能快速上手，让老项目在半年后还能被轻易理解和修改。

Playwright Python作为当前UI自动化测试的“当红炸子鸡”，其原生支持Chromium、Firefox、WebKit三大浏览器引擎，且具备自动等待、网络拦截、移动端模拟等强大功能，是构建这类框架的绝佳底座。但原生的Playwright更像是一把锋利的瑞士军刀，而我们要做的，是围绕这把刀打造一个包含刀鞘、磨刀石、使用说明书和保养流程的完整“工具箱”。这个指南，就是带你从零开始，打造这样一个专为团队协作和持续集成设计的工具箱。

2. 框架核心设计哲学与架构选型

在动手写第一行代码之前，我们必须想清楚这个框架要遵循哪些原则。盲目堆砌功能只会制造一个臃肿的怪物。我总结的核心设计哲学是：约定优于配置，模块解耦，职责清晰。

2.1 核心设计原则

1. 可读性与可维护性优先：测试代码也是代码，而且是经常需要被非开发人员（如测试工程师）阅读和修改的代码。因此，我们必须使用清晰的页面对象模型（Page Object Model, POM）来分离页面操作和测试逻辑，让业务流一目了然。
2. 稳定与健壮性：自动化测试最怕“脆皮”。框架必须内置强大的错误处理、重试机制和丰富的日志记录，确保一次意外的网络抖动或元素加载稍慢不会导致整个测试套件失败。
3. 易于集成与执行：框架应该能轻松融入现有的开发流程。这意味着要完美支持命令行执行、与CI/CD工具（如Jenkins, GitLab CI）集成，并能方便地生成人类和机器都可读的测试报告。
4. 配置灵活与数据驱动：测试环境（开发、测试、预生产）、浏览器类型、是否无头模式等都应该通过外部配置文件管理，无需修改代码。测试数据也应与脚本分离，支持数据驱动测试（DDT），用同一套脚本验证多组数据。

2.2 技术栈与架构图

基于以上原则，我们选择以下技术栈来搭建框架的基石：

• 核心测试引擎：Playwright Python。这是我们的绝对核心，负责所有与浏览器的交互。
• 测试组织与运行：Pytest。它是Python社区事实上的标准测试框架，提供了丰富的夹具（fixture）、参数化、钩子（hook）等功能，远超unittest，是我们组织用例、管理生命周期的不二之选。
• 断言库：直接使用Pytest内置的断言，简单直接。也可以搭配assertpy等库获得更丰富的断言表达。
• 配置管理：pydantic-settings+.env文件。pydantic提供了带类型验证的配置模型，结合.env文件管理环境变量，安全又方便。
• 报告生成：pytest-html+allure-pytest。pytest-html用于生成快速查看的HTML报告；Allure用于生成极其详细、美观且可交互的仪表盘报告，是企业级汇报的利器。
• 并发执行：pytest-xdist。允许我们并行运行测试用例，充分利用多核CPU，大幅缩短测试套件执行时间。

整个框架的架构可以想象成一个分层模型：

1. 配置层（Config）：最底层，管理所有环境变量、运行时参数（如基础URL、浏览器类型、超时时间、是否录屏等）。
2. 核心驱动层（Core）：基于Playwright，封装浏览器启动、上下文（Context）和页面（Page）的创建与管理。这里会创建一些关键的Pytest fixture供上层使用。
3. 页面对象层（Pages）：将Web应用的不同页面抽象成类，每个类封装该页面的元素定位器和常用操作方法。这是保证代码可读性的关键。
4. 业务逻辑层（Flows/Services）：组合多个页面对象的方法，形成完整的业务流（例如“用户登录-搜索商品-加入购物车”）。这一步是可选的，但对于复杂流程能进一步提升脚本的复用性和可读性。
5. 测试用例层（Tests）：最上层，使用Pytest编写具体的测试函数。这里只包含测试步骤和断言，所有页面操作都调用页面对象层或业务逻辑层。
6. 工具与扩展层（Utils/Extensions）：包含自定义的辅助函数，如数据生成器、数据库操作、API客户端、自定义报告钩子等。

注意：不要试图在第一版就实现所有功能。采用迭代方式，先搭建一个包含配置、核心驱动、页面对象和测试用例的最小可行框架，跑通一个端到端的测试，再逐步添加报告、并发、数据驱动等高级特性。

3. 从零开始：搭建框架基础骨架

理论说再多不如动手。我们现在就来创建项目目录并编写最核心的模块。

3.1 项目初始化与依赖安装

首先，创建一个新的项目目录并初始化虚拟环境，这是保证项目依赖隔离的好习惯。

mkdir enterprise-playwright-framework cd enterprise-playwright-framework python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate

接下来，创建requirements.txt文件，定义我们的核心依赖。

# requirements.txt playwright>=1.40.0 pytest>=7.4.0 pytest-html>=4.1.0 pytest-xdist>=3.5.0 allure-pytest>=2.13.0 pydantic-settings>=2.0.0 python-dotenv>=1.0.0 requests>=2.31.0 # 用于可能的API辅助测试

安装依赖，并让Playwright安装它所需的浏览器二进制文件。

pip install -r requirements.txt playwright install chromium firefox webkit # 建议安装全部，以备不时之需

3.2 配置管理模块设计

配置是框架的“指挥中心”。我们在项目根目录创建.env文件来存储敏感或环境相关的变量，并创建一个Python模块来加载和验证这些配置。

.env文件示例：

# .env APP_BASE_URL=https://demo.testfire.net BROWSER_TYPE=chromium HEADLESS=True SLOW_MO=0 # 操作延迟毫秒数，调试时可设为100-500 VIEWPORT_WIDTH=1920 VIEWPORT_HEIGHT=1080 TIMEOUT=30000 ALLURE_RESULTS_DIR=./allure-results

接下来，创建config目录和settings.py文件。

# config/settings.py from pydantic_settings import BaseSettings from typing import Literal class Settings(BaseSettings): """应用配置，自动从 .env 文件和环境变量中加载""" # 应用配置 app_base_url: str = "https://demo.testfire.net" # 浏览器配置 browser_type: Literal["chromium", "firefox", "webkit"] = "chromium" headless: bool = True slow_mo: int = 0 viewport_width: int = 1920 viewport_height: int = 1080 # 超时配置（毫秒） timeout: int = 30000 navigation_timeout: int = 60000 # 报告与输出 allure_results_dir: str = "./allure-results" screenshot_on_failure: bool = True video_on_failure: bool = False # 可以通过 model_config 指定 .env 文件位置 class Config: env_file = ".env" extra = "ignore" # 忽略未在模型中定义的额外环境变量 # 创建全局配置实例 settings = Settings()

使用pydantic的好处是，如果你在.env里把BROWSER_TYPE错写成chromeium，程序启动时就会立刻报错，而不是等到运行时才出现奇怪的浏览器启动失败，这能极大提升排错效率。

3.3 核心Playwright Fixture封装

Pytest的fixture是我们管理测试资源（如浏览器、页面）的生命周期的最佳工具。我们将在conftest.py文件中定义这些核心fixture。

# conftest.py import pytest from playwright.sync_api import Page, Browser, BrowserContext, Playwright from config.settings import settings import logging # 配置日志 logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) @pytest.fixture(scope="session") def playwright_instance() -> Playwright: """会话级别的Playwright实例，整个测试会话只启动一次""" from playwright.sync_api import sync_playwright with sync_playwright() as playwright: yield playwright @pytest.fixture(scope="session") def browser(playwright_instance: Playwright) -> Browser: """基于配置启动浏览器实例""" logger.info(f"启动浏览器: {settings.browser_type}, 无头模式: {settings.headless}") browser = getattr(playwright_instance, settings.browser_type).launch( headless=settings.headless, slow_mo=settings.slow_mo, args=['--disable-blink-features=AutomationControlled'] # 可选：尝试绕过一些自动化检测 ) yield browser # 测试会话结束后关闭浏览器 browser.close() logger.info("浏览器已关闭") @pytest.fixture(scope="function") def context(browser: Browser) -> BrowserContext: """为每个测试函数创建一个独立的浏览器上下文。 上下文相当于一个独立的‘隐身会话’，cookie、缓存互不干扰，是实现测试隔离的关键。""" context = browser.new_context( viewport={'width': settings.viewport_width, 'height': settings.viewport_height}, ignore_https_errors=True, # 忽略HTTPS证书错误，常用于测试环境 # 可以在这里注入初始化脚本或设置权限 ) yield context context.close() @pytest.fixture(scope="function") def page(context: BrowserContext) -> Page: """为每个测试函数创建一个新的页面（标签页）。 这是测试脚本主要交互的对象。""" page = context.new_page() # 设置默认超时 page.set_default_timeout(settings.timeout) page.set_default_navigation_timeout(settings.navigation_timeout) # 监听请求/响应，用于调试或断言（可选） # page.on("request", lambda request: logger.debug(f">> {request.method} {request.url}")) # page.on("response", lambda response: logger.debug(f"<< {response.status} {response.url}")) yield page # 测试结束后，如果失败则截图 if hasattr(page, "_test_failed") and page._test_failed and settings.screenshot_on_failure: import os screenshot_dir = "test_results/screenshots" os.makedirs(screenshot_dir, exist_ok=True) screenshot_path = os.path.join(screenshot_dir, f"{pytest.current_test_name}.png") page.screenshot(path=screenshot_path, full_page=True) logger.info(f"测试失败，截图已保存至: {screenshot_path}") page.close()

这里有几个关键点：

1. 生命周期管理：playwright_instance和browser是session作用域，整个测试过程只创建一次，效率高。context和page是function作用域，每个测试用例都获得全新的、隔离的环境，避免了用例间的状态污染。
2. 测试隔离：使用BrowserContext是实现隔离的推荐做法。每个测试用例在独立的上下文中运行，其cookies、localStorage等都不会影响到其他用例。
3. 失败处理：我们在pagefixture的teardown逻辑中加入了失败截图功能。pytest.current_test_name需要配合一个pytest钩子来获取，我们稍后补充。

3.4 实现测试失败时自动截图与录屏

为了让失败截图功能生效，我们需要在conftest.py中添加一个pytest钩子来捕获测试用例的状态。

# 在 conftest.py 中追加以下内容 def pytest_runtest_makereport(item, call): """pytest钩子，用于在测试执行后获取结果""" if call.when == "call": # 我们只关心测试执行阶段，而不是setup或teardown outcome = call.excinfo # 将测试结果（是否失败）存储到page对象上（如果page存在） for fixture_name in item.fixturenames: if fixture_name == "page": page_fixture = item.funcargs[fixture_name] # 给page对象动态添加一个属性，标记测试是否失败 page_fixture._test_failed = outcome is not None # 同时保存当前测试的名称，用于截图命名 page_fixture._test_name = item.nodeid.replace("::", "_").replace("/", "_").replace(".py", "") break # 同时，修改之前的 page fixture，使用这个保存的名称 # 将原来的 pytest.current_test_name 替换为 page._test_name

对于录屏，Playwright Context本身就支持。我们可以选择性地为失败的测试录屏，但这会消耗更多磁盘空间和性能。修改contextfixture：

@pytest.fixture(scope="function") def context(browser: Browser, request) -> BrowserContext: # 新增 request 参数 """为每个测试函数创建一个独立的浏览器上下文。""" context = browser.new_context( viewport={'width': settings.viewport_width, 'height': settings.viewport_height}, ignore_https_errors=True, record_video_dir="./test_results/videos" if settings.video_on_failure else None, # 条件化录屏 record_video_size={"width": 1280, "height": 720} ) yield context # 如果测试失败且开启了录屏，则保留视频文件并重命名 if settings.video_on_failure and hasattr(context, "_test_failed") and context._test_failed: video = context.video if video: import os video_path = video.path() new_video_path = os.path.join(os.path.dirname(video_path), f"{request.node.name}.webm") os.rename(video_path, new_video_path) logger.info(f"测试失败，录屏已保存至: {new_video_path}") context.close()

实操心得：失败截图和录屏是调试的“救命稻草”，但video_on_failure默认应设为False。因为录屏对性能影响较大，且视频文件很大。建议只在调试难以复现的偶发问题时，在本地或特定CI任务中临时开启。

4. 构建可维护的测试用例：页面对象模型（POM）实践

有了稳固的基础设施，现在我们来构建测试代码本身。直接在被测页面上写page.locator(“#username”).fill(“admin”)是“脚本”，而不是“框架”。我们需要用页面对象模型（POM）来封装。

4.1 创建基础页面类

首先，在项目中创建pages目录。然后，创建一个所有页面对象都将继承的base_page.py。这个基类封装了常用的操作和等待逻辑，并提供更清晰的日志。

# pages/base_page.py from playwright.sync_api import Page, Locator from config.settings import settings import logging logger = logging.getLogger(__name__) class BasePage: """所有页面对象的基类""" def __init__(self, page: Page): self.page = page self.timeout = settings.timeout def navigate(self, url: str = None): """导航到指定URL或页面自身的URL""" target_url = url or self.URL # 假设子类定义了 self.URL logger.info(f"导航至: {target_url}") self.page.goto(target_url, timeout=settings.navigation_timeout) self.wait_for_page_loaded() def wait_for_page_loaded(self): """等待页面加载完成的通用方法。 可以扩展为等待特定元素出现，或使用Playwright的`page.wait_for_load_state()`""" self.page.wait_for_load_state("networkidle") logger.debug("页面加载完成") def find(self, selector: str) -> Locator: """查找元素，并记录日志。这是对page.locator的简单封装，便于统一添加行为。""" logger.debug(f"查找元素: {selector}") return self.page.locator(selector) def click(self, selector: str, **kwargs): """点击元素，并等待导航完成（如果会触发导航）""" logger.info(f"点击元素: {selector}") element = self.find(selector) element.click(**kwargs) # 点击后可以等待一小段时间，或等待特定状态，根据实际情况调整 # self.page.wait_for_timeout(500) def fill(self, selector: str, value: str, **kwargs): """填充文本框""" logger.info(f"在元素 {selector} 中填充值: {value}") element = self.find(selector) element.fill(value, **kwargs) def get_text(self, selector: str) -> str: """获取元素文本""" element = self.find(selector) text = element.text_content() logger.debug(f"获取元素 {selector} 的文本: {text}") return text.strip() if text else "" def is_visible(self, selector: str, timeout: int = None) -> bool: """检查元素是否可见""" timeout = timeout or self.timeout try: self.find(selector).wait_for(state="visible", timeout=timeout) return True except: return False

4.2 实现具体的页面对象

以登录页面为例。假设我们有一个简单的登录页，URL是/login，有用户名、密码输入框和登录按钮。

# pages/login_page.py from .base_page import BasePage class LoginPage(BasePage): """登录页面对象""" # 页面URL（相对路径，会拼接config中的base_url） PATH = "/login" # 元素定位器 - 使用字典或类属性管理，便于维护 LOCATORS = { "username_input": "#username", "password_input": "#password", "login_button": "button[type='submit']", "error_message": ".alert-error" } def __init__(self, page): super().__init__(page) self.URL = f"{settings.app_base_url}{self.PATH}" def load(self): """导航到登录页""" self.navigate() return self def login(self, username: str, password: str): """执行登录操作""" logger.info(f"尝试登录，用户名: {username}") self.fill(self.LOCATORS["username_input"], username) self.fill(self.LOCATORS["password_input"], password) self.click(self.LOCATORS["login_button"]) # 登录后，可以返回下一个页面的对象，例如首页 # from .home_page import HomePage # return HomePage(self.page) # 这里我们先不返回，让测试用例自己处理 def get_error_message(self) -> str: """获取登录错误提示信息""" if self.is_visible(self.LOCATORS["error_message"], timeout=5000): # 短超时等待错误信息 return self.get_text(self.LOCATORS["error_message"]) return ""

注意事项：定位器字符串是自动化脚本中最脆弱的部分。一旦前端ID或类名改变，所有相关测试都会失败。因此，强烈建议：

1. 与前端开发团队约定，为关键测试元素添加稳定的># tests/test_login.py import pytest from pages.login_page import LoginPage from pages.home_page import HomePage # 假设我们有首页对象 class TestLogin: """登录功能测试集""" def test_successful_login(self, page): """测试使用有效凭证登录成功""" # 1. 加载登录页 login_page = LoginPage(page).load() # 2. 执行登录操作 login_page.login("jsmith", "demo1234") # 3. 断言：验证登录后跳转到了首页，并且首页显示了用户名 home_page = HomePage(page) assert home_page.is_visible(HomePage.LOCATORS["welcome_message"]), "登录后未跳转到首页" welcome_text = home_page.get_text(HomePage.LOCATORS["welcome_message"]) assert "jsmith" in welcome_text, f"欢迎信息中未包含用户名，实际内容: {welcome_text}" @pytest.mark.parametrize("username, password, expected_error", [ ("invalid", "demo1234", "Invalid username or password"), ("jsmith", "wrong", "Invalid username or password"), ("", "", "Username is required"), ]) def test_login_failure(self, page, username, password, expected_error): """参数化测试：测试各种登录失败场景""" login_page = LoginPage(page).load() login_page.login(username, password) # 断言：页面上显示了预期的错误信息 actual_error = login_page.get_error_message() assert expected_error in actual_error, f"错误信息不匹配。期望包含‘{expected_error}’，实际是‘{actual_error}’"

   这个测试用例展示了良好的结构：

   1. 可读性：像自然语言一样描述了“加载页面-执行登录-验证结果”的流程。
   2. 可维护性：页面细节（定位器、操作）被封装在LoginPage和HomePage中。如果登录按钮的ID变了，你只需要修改LoginPage中的一个地方。
   3. 高效性：使用@pytest.mark.parametrize进行数据驱动测试，用同一个测试函数覆盖了多个负面测试场景。

   5. 高级特性集成：报告、并发与CI/CD

   一个基础框架已经成型。接下来，我们集成那些让框架变得“企业级”的高级特性。

   5.1 生成丰富的测试报告

   漂亮的报告能让测试结果一目了然，也是向团队和管理层展示自动化价值的重要方式。

   1. 使用pytest-html生成快速报告：安装后，只需在运行pytest时添加参数即可。

   pytest --html=test_results/report.html --self-contained-html

   --self-contained-html参数会将CSS和JS内嵌到HTML中，生成单个文件，方便分享。你可以在conftest.py中通过钩子函数自定义报告内容，例如附加截图。

   2. 集成Allure生成交互式报告：Allure报告更加专业和强大。首先确保已安装allure-pytest和Allure命令行工具。 运行测试生成原始数据：

   pytest --alluredir=./allure-results

   然后生成并打开HTML报告：

   allure generate ./allure-results -o ./allure-report --clean allure open ./allure-report

   你可以在测试用例中使用装饰器来增强Allure报告：

   import allure class TestLogin: @allure.title("验证用户使用正确密码可以成功登录") @allure.severity(allure.severity_level.CRITICAL) @allure.feature("用户认证") @allure.story("登录功能") def test_successful_login(self, page): with allure.step("打开登录页面"): login_page = LoginPage(page).load() with allure.step(f"输入用户名和密码"): login_page.login("jsmith", "demo1234") with allure.step("验证登录成功并跳转到首页"): home_page = HomePage(page) assert home_page.is_visible(HomePage.LOCATORS["welcome_message"])

   这样生成的Allure报告会包含清晰的测试步骤、等级和分类，非常适合分析和展示。

   5.2 使用pytest-xdist实现并行测试

   当测试用例成百上千时，串行执行会非常耗时。pytest-xdist插件可以让你轻松实现并行。

   安装后，使用-n参数指定并行进程数：

   pytest -n auto # auto会自动检测CPU核心数 # 或指定数量 pytest -n 4

   踩坑提醒：并行测试时，必须确保测试用例之间是完全独立的。这正是我们之前使用function作用域的context和pagefixture的原因——每个用例都有自己干净的浏览器环境。如果用例间有依赖（比如用例B依赖用例A创建的数据），并行就会导致随机失败。对于少量有状态依赖的用例，可以用pytest.mark.run(order=1)来标记顺序，并将它们与其他用例分开执行。

   5.3 集成到CI/CD流水线（以GitLab CI为例）

   自动化测试只有集成到CI/CD中，每次代码变更后自动运行，才能发挥最大价值。以下是一个简单的.gitlab-ci.yml示例：

   # .gitlab-ci.yml stages: - test variables: PLAYWRIGHT_BROWSERS_PATH: $CI_PROJECT_DIR/.cache/ms-playwright # 缓存Playwright浏览器，避免每次下载 cache: key: playwright-browsers paths: - .cache/ms-playwright playwright-tests: stage: test image: mcr.microsoft.com/playwright/python:v1.40.0-jammy # 使用官方Docker镜像，自带所有依赖和浏览器 before_script: - pip install -r requirements.txt script: - playwright install --with-deps chromium # 确保浏览器已安装 - pytest --browser chromium --headless --alluredir=allure-results -n auto -v after_script: - | if [ -d "allure-results" ]; then allure generate allure-results -o allure-report --clean fi artifacts: when: always paths: - allure-report/ - test_results/ expire_in: 1 week rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" # 在合并请求时触发 - if: $CI_COMMIT_BRANCH == "main" # 在推送到主分支时也触发

   这个配置做了几件事：

   1. 使用Playwright官方Docker镜像，环境一致。
   2. 缓存浏览器二进制文件，加速后续构建。
   3. 在合并请求和推送到主分支时自动运行测试。
   4. 始终生成Allure报告和测试结果（截图等）作为制品，可供下载查看。

   6. 实战避坑指南与性能优化

   框架搭建和用例编写过程中，你会遇到各种“坑”。这里分享一些高频问题的解决方案。

   6.1 元素定位与等待的“艺术”

   问题1：元素找不到（TimeoutError）这是最常见的问题。除了前端变更，很多时候是页面还没加载完或元素处于不可交互状态。

   • 解决方案：
     • 优先使用Playwright的自动等待：page.click(),page.fill()等操作本身会等待元素可操作。相信它，不要自己乱加page.wait_for_timeout(5000)。
     • 使用更精准的等待：如果自动等待不够，使用locator.wait_for(state=”visible”)或page.wait_for_selector()。
     • 检查iframe：如果元素在iframe内，你需要先切换到iframe：frame = page.frame(name=‘frame-name’)，然后在frame上操作。
     • 检查Shadow DOM：Playwright支持Shadow DOM穿透，使用>>>或/deep/组合符，如page.locator(‘my-custom-element >>> .internal-button’).click()。

   问题2：测试在CI环境（如Docker）中失败，本地却成功这通常是因为CI环境资源（CPU、内存）受限，或缺少某些依赖（如字体、库）。

   • 解决方案：
     • 增加超时时间：在CI配置中，将settings.timeout和navigation_timeout适当调大。
     • 使用更稳定的定位器：避免使用依赖于渲染速度或动画的定位器。
     • 确保CI镜像包含必要依赖：使用mcr.microsoft.com/playwright/python官方镜像是最省心的。
     • 查看CI日志和截图：这是最重要的调试手段。确保失败截图和日志已正确上传到CI制品中。

   6.2 测试数据管理

   测试数据（如用户、商品）的管理是另一个挑战。硬编码在脚本里不可取。

   • 策略：
     1. 静态测试数据文件：使用JSON、YAML或CSV文件存储测试数据，通过@pytest.mark.parametrize读取。适用于数据量小、变化不频繁的场景。
     2. 动态数据生成：使用faker库在测试开始前动态生成数据（如随机邮箱、用户名）。测试结束后，如果数据创建在测试环境中，最好有对应的清理机制（如调用清理API）。
     3. 独立测试环境与数据快照：为自动化测试准备一个独立的环境，并定期恢复到一个干净的数据快照。这样测试用例可以依赖固定的数据状态。

   6.3 性能优化技巧

   1. 复用Browser，创建独立Context：正如我们框架设计的，browser是session级fixture，只启动一次。每个测试用例使用独立的context，这比每个用例都开关浏览器快一个数量级。
   2. 并行执行：务必使用pytest-xdist。这是提升执行速度最有效的手段。
   3. 选择性运行测试：使用pytest标记（@pytest.mark.smoke）来分类测试。在CI中，每次提交只运行冒烟测试， nightly build再运行全量测试。
   4. 禁用不必要的功能：在CI的无头模式下，可以禁用GPU、沙箱等以节省资源：browser = chromium.launch(headless=True, args=['--disable-gpu', '--no-sandbox'])。
   5. 优化等待：减少硬性等待（page.wait_for_timeout），多用事件驱动等待（wait_for_selector,wait_for_load_state）。

   构建一个企业级的Playwright自动化测试框架，远不止是学会API调用。它是一次对测试代码的工程化改造，涉及架构设计、配置管理、生命周期控制、报告集成和持续交付。这个指南为你提供了一个扎实的起点和一套经过实践检验的模式。记住，最好的框架不是最复杂的，而是最适合你团队当前需求和技能水平的那个。从最小可行产品开始，在实践中不断迭代和优化，你的自动化测试才能真正成为研发流程中可靠的质量守护者。