Playwright融合测试：统一UI与接口自动化的架构与实践

1. 项目概述：为什么我们需要融合UI与接口自动化？

如果你做过一段时间的自动化测试，大概率会遇到这样的场景：一个完整的业务流程，前半段需要登录、填写表单、上传文件，这些操作依赖UI界面；后半段则涉及到订单状态查询、数据校验、消息通知，这些功能通过调用后端接口来完成更高效。传统的做法是，UI自动化用Selenium或Playwright写一套脚本，接口自动化用Requests或Pytest写另一套脚本。两套脚本独立运行，数据难以共享，状态无法衔接，维护起来简直是灾难。更头疼的是，当UI因为一个元素的轻微变动而失败时，整个端到端的测试流程就中断了，你无法验证后续的接口逻辑是否正确。

这正是“用Playwright实现接口自动化与UI自动化的无缝融合”这个项目要解决的核心痛点。它不是一个简单的工具使用教程，而是一种测试架构思想的实践。其核心价值在于，利用Playwright这一个工具，统一测试执行上下文，让UI操作和HTTP请求在同一个会话、同一个状态管理下协同工作。想象一下，你可以先用Playwright模拟用户登录拿到Cookie，然后用这个Cookie直接去调用需要鉴权的API接口进行数据准备，接着再回到浏览器界面进行UI操作验证结果，整个过程一气呵成，数据流和状态流完全打通。

这套方案特别适合测试现代Web应用，尤其是那些前端交互复杂、后端API众多的单页面应用（SPA）或中后台管理系统。对于测试开发工程师、全栈开发者以及任何需要保证Web应用质量的同学来说，掌握这种融合能力，意味着你能设计出更健壮、更高效、也更贴近真实用户场景的自动化测试用例。接下来，我会从设计思路拆解开始，带你一步步实现这套融合框架。

2. 整体设计与核心思路拆解

在开始写代码之前，理清思路至关重要。我们不是简单地把两个东西拼在一起，而是要思考如何让它们“1+1>2”。

2.1 为什么选择Playwright作为融合的核心？

市面上UI自动化工具不少，Selenium历史悠久，Cypress对前端友好。但我选择Playwright作为融合基座，主要基于以下几个无可替代的优势：

1. 原生的网络请求拦截与模拟能力：这是实现融合的技术基石。Playwright的page.route()和browserContext.route()方法，允许你在浏览器发起真实请求之前，就拦截并修改或直接响应它。这意味着，你可以在UI测试中“注入”一个接口测试。反过来，Playwright也提供了直接发送HTTP请求的API（如page.request或context.request），让你能在浏览器上下文之外，以编程方式调用接口，并且自动携带浏览器中已有的Cookie等认证状态。
2. 统一的执行上下文与状态共享：Playwright的BrowserContext（浏览器上下文）是一个独立的会话环境，它包含了Cookie、本地存储、索引数据库等。无论是通过UI操作（page.goto()）还是通过API调用（context.request.get()），只要在同一个BrowserContext下进行，所有的状态都是共享的。这完美解决了UI和接口之间状态隔离的问题。
3. 强大的自动化与可靠性：相比Selenium，Playwright自动等待机制更智能，对现代Web渲染支持更好，能有效减少因元素加载时序导致的“flaky tests”（不稳定的测试）。这保证了融合测试的稳定性。
4. 多语言支持与丰富的生态系统：支持Python、Node.js、Java、.NET，能与Pytest、Jest等主流测试框架无缝集成，方便我们构建完整的测试套件。

基于以上几点，我们的核心设计思路就清晰了：以Playwright的BrowserContext为统一沙箱，在此沙箱内，UI操作（Page对象）和接口调用（API Request对象）并行存在，并自由交换数据和状态。

2.2 融合架构的三种典型模式

在实际项目中，融合并非千篇一律，我根据测试目标总结了三种常用模式：

1. 接口优先，UI验证模式：

   • 场景：需要准备大量测试数据，或执行某些UI操作成本很高的前置步骤。
   • 流程：首先，使用Playwright的API请求功能（不打开浏览器）直接调用后端接口，完成数据创建、用户登录态获取等操作。然后，利用这些接口返回的数据（如ID、Token）初始化测试状态，再启动浏览器进行UI操作，验证数据是否正确展示或流程是否完整。
   • 示例：测试一个电商订单列表页。先通过接口批量生成10个不同状态的订单，然后打开浏览器登录，进入订单列表页，断言页面上是否正确地显示了这10个订单及其状态。

2. UI触发，接口断言模式：

   • 场景：验证前端UI操作是否触发了正确的后端API调用，以及API的响应是否符合预期。
   • 流程：在UI操作（如点击提交按钮）之前，通过page.route()拦截特定的API请求。执行UI操作后，在路由处理函数中获取到实际的请求参数和响应，对其进行断言。甚至可以修改响应，来测试前端对不同API响应的处理逻辑。
   • 示例：测试一个搜索功能。拦截/api/search这个请求，当在搜索框输入关键词并点击搜索后，在路由处理函数中断言：1) 请求的keyword参数是否正确；2) 返回的HTTP状态码是否为200。最后，可以放行请求或返回一个模拟的响应数据。

3. 混合编排，状态接力模式：

   • 场景：复杂的端到端（E2E）业务流程，其中部分环节用UI测试更直观，部分环节用接口测试更高效。
   • 流程：在一个测试用例中，交替使用UI操作和接口调用。状态（如登录Session、业务ID）在整个过程中持续传递。
   • 示例：测试一个从发布商品到下单的完整流程。
     • 步骤1（接口）：调用/api/login接口登录，获取auth_token。
     • 步骤2（UI）：用Playwright打开浏览器，将auth_token写入Cookie，导航到商品管理页。
     • 步骤3（UI）：在页面上填写表单，点击“发布”按钮。
     • 步骤4（接口）：通过拦截请求或直接调用查询接口，获取刚发布的商品ID。
     • 步骤5（UI）：用另一个浏览器上下文（模拟另一个用户），使用商品ID直接生成商品详情页URL并访问，进行下单UI操作。
     • 步骤6（接口）：调用订单查询接口，验证订单状态是否变为“已支付”。

选择哪种模式，取决于你的测试用例目标和系统特点。很多时候，一个用例里会混合使用多种模式。

3. 核心细节解析与实操要点

理解了设计思路，我们深入到Playwright实现融合的几个核心技术细节。这部分是能否玩转融合测试的关键。

3.1 理解并驾驭BrowserContext与APIRequestContext

这是两个最重要的对象，务必厘清它们的关系和用法。

• BrowserContext：你可以把它想象成一个独立的“隐身模式”浏览器会话。每个Context都有独立的Cookie、本地存储、缓存和证书。当你用browser.newContext()创建它时，就得到了一个干净的沙箱。所有在该Context下创建的Page（页面）和发起的APIRequest，都共享这个沙箱的状态。这是实现状态共享的核心。

• APIRequestContext：这是Playwright提供的、用于发送HTTP请求的接口。它可以通过browserContext.request或playwright.request来创建。关键区别在于：

  • browserContext.request：强烈推荐在融合测试中使用。它自动继承并管理对应BrowserContext的所有状态（如Cookie）。你在UI页面里登录后，用这个request对象发起的API调用，自动就带上了登录态。
  • playwright.request：这是一个独立的、不绑定任何浏览器上下文的请求对象。适用于纯接口测试，或者需要完全独立会话的场景。

实操要点： 在编写测试类或Fixture时，我习惯先初始化一个BrowserContext，然后从这个Context派生出Page对象（用于UI）和APIRequestContext对象（用于接口）。这样，它们三位一体，状态天然同步。

import pytest from playwright.sync_api import Playwright, Browser, BrowserContext, Page, APIRequestContext @pytest.fixture(scope="function") def api_request_context(browser: Browser) -> APIRequestContext: # 为每个测试函数创建一个独立的上下文和请求对象 context = browser.new_context() request_context = context.request yield request_context # 测试结束后，关闭上下文，会自动清理所有相关页面和状态 context.close() # 在测试用例中，你可以同时使用 page 和 api_request_context def test_fusion_example(page: Page, api_request_context: APIRequestContext): # UI操作：登录 page.goto("https://example.com/login") page.fill("#username", "testuser") page.fill("#password", "password123") page.click("button[type='submit']") # 此时，登录成功的Cookie已经存在于共享的BrowserContext中 # 接口操作：使用共享了Cookie的request对象调用需要鉴权的API response = api_request_context.get("https://api.example.com/user/profile") assert response.ok profile_data = response.json() assert profile_data["username"] == "testuser" # 你看，无需手动处理Token或Cookie，一切自动完成

3.2 掌握请求拦截与修改（route）的实战技巧

page.route()是实现“UI触发，接口断言”模式的利器。它的工作原理是，在请求发送到网络之前，将其截获，你可以选择继续发送、修改后发送、或者直接返回一个模拟响应。

一个完整的拦截示例： 假设我们要测试文件上传功能，并验证上传时调用的API参数。

def test_upload_with_api_intercept(page: Page): # 1. 在执行UI操作前，先设置路由拦截 page.route("**/api/upload", lambda route: handle_upload_route(route)) # 2. 执行触发请求的UI操作 page.goto("https://example.com/upload") with page.expect_file_chooser() as fc_info: page.click("input[type='file']") file_chooser = fc_info.value # 注意：这里需要准备一个真实的测试文件，例如 test_image.jpg file_chooser.set_files("path/to/test_image.jpg") page.click("button#upload-btn") # 3. 路由处理函数 def handle_upload_route(route): request = route.request # 断言请求方法 assert request.method == "POST" # 断言请求头中包含 multipart/form-data assert "multipart/form-data" in request.headers.get("content-type", "") # 获取请求的post data (对于multipart，这是一个FormData对象) # Playwright 提供了 request.post_data_buffer 来获取原始数据，但解析multipart较复杂。 # 更常见的做法是：让请求正常发生，但断言它成功了。 # 或者，我们可以模拟一个成功的响应，让UI流程继续。 # 方案A：继续实际请求，并断言响应 # route.continue_() # 方案B：模拟一个成功的JSON响应（用于前端逻辑验证） route.fulfill( status=200, headers={"Content-Type": "application/json"}, body=json.dumps({"code": 0, "data": {"fileId": "mock_file_123"}, "msg": "success"}) ) # 记录或进行更多断言 print(f"拦截到上传请求: {request.url}")

注意事项与避坑指南：

• 匹配模式：**/api/upload中的**是通配符，匹配任何路径下的/api/upload。你也可以用正则表达式，如re.compile(r".*/api/v1/orders/.*")来匹配动态路径。
• route.continue_()vsroute.fulfill()：continue_()是放行请求到真实服务器；fulfill()是直接返回一个模拟响应，请求不会到达服务器。选择哪个取决于你的测试目的。如果想验证后端逻辑，用continue_()并检查真实响应；如果只想验证前端行为或模拟特定场景（如网络错误、慢响应），用fulfill()。
• 异步处理：如果路由处理函数中有异步操作（如从数据库读取模拟数据），记得使用async/await。上面的例子是同步API，如果使用异步API（playwright.async_api），写法略有不同。
• 避免死循环：不要在路由处理函数中，又发起一个会被同一路由规则匹配的请求，这会导致无限循环。
• 清理路由：使用page.unroute()可以在不需要时移除路由，避免对后续测试产生干扰。通常一个测试用例设置的路由，在本用例结束时随着page关闭而自动失效，但如果page被复用，则需要手动清理。

3.3 处理认证与状态保持

在融合测试中，处理登录状态是最常见的需求。我们的目标是：一次认证，UI和接口共用。

最佳实践：通过接口登录，状态注入Context对于需要登录的测试，我强烈建议首先通过API完成登录。因为API登录通常更快、更稳定，不受前端UI变化的影响。

def test_shared_auth_state(playwright: Playwright): browser = playwright.chromium.launch(headless=False) # 1. 创建一个干净的浏览器上下文 context = browser.new_context() # 2. 创建该上下文关联的请求对象 api_request = context.request # 3. 【关键步骤】通过接口登录，获取认证信息 login_response = api_request.post("https://api.example.com/auth/login", data={"username": "test", "password": "123"}) assert login_response.ok auth_token = login_response.json().get("token") # 假设后端通过Authorization头认证 # 4. 【关键步骤】将认证信息设置到请求对象的默认头中 # 这样，后续所有通过这个api_request发起的调用都会自动携带token api_request.set_extra_http_headers({"Authorization": f"Bearer {auth_token}"}) # 同时，这个token也可能需要设置到浏览器上下文中，供UI使用（如果前端通过localStorage或Cookie鉴权） # 例如，通过evaluate将token存入localStorage page = context.new_page() page.add_init_script(f""" window.localStorage.setItem('auth_token', '{auth_token}'); """) # 5. 现在，你可以进行任何需要登录态的UI或接口操作了 # 接口操作：获取用户信息 profile_resp = api_request.get("https://api.example.com/user/profile") assert profile_resp.ok # UI操作：访问需要登录的页面 page.goto("https://example.com/dashboard") # 页面应该能正常加载，因为localStorage里已经有了token browser.close()

这种方法的好处是，登录逻辑集中处理，且不依赖UI。即使登录页改版，也只需要更新接口请求的数据，而不会影响成百上千个依赖登录的测试用例。

4. 实操过程：构建一个融合测试框架

理论说再多，不如动手搭一个。下面，我将以Python + Pytest为例，展示如何搭建一个基础但实用的融合测试框架。

4.1 项目结构与依赖安装

首先，初始化项目并安装核心依赖。

# 创建项目目录 mkdir playwright-fusion-framework cd playwright-fusion-framework # 初始化Python虚拟环境（推荐） python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装核心依赖 pip install pytest playwright # 安装Playwright浏览器（Chromium, Firefox, WebKit） playwright install chromium

项目目录结构建议如下：

playwright-fusion-framework/ ├── conftest.py # Pytest全局配置，定义核心fixture ├── requirements.txt # 项目依赖 ├── pages/ # Page Object模型目录 │ ├── __init__.py │ ├── login_page.py │ └── dashboard_page.py ├── api/ # API客户端封装目录 │ ├── __init__.py │ └── user_api.py ├── tests/ # 测试用例目录 │ ├── __init__.py │ ├── test_login_fusion.py │ └── test_order_flow.py └── utils/ # 工具函数 ├── __init__.py └── data_helper.py

4.2 编写核心Fixture（conftest.py）

conftest.py是Pytest的魔力所在，我们在这里定义所有测试用例共享的“装备”。

# conftest.py import pytest from playwright.sync_api import Playwright, Browser, BrowserContext, Page, APIRequestContext import os @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: """会话级别的浏览器实例。""" # 可以根据环境变量决定是否无头运行、使用哪个浏览器 headless = os.getenv("HEADLESS", "true").lower() == "true" browser = playwright_instance.chromium.launch(headless=headless, slow_mo=500) # slow_mo让操作变慢，方便调试 yield browser browser.close() @pytest.fixture(scope="function") def context(browser: Browser) -> BrowserContext: """函数级别的浏览器上下文。每个测试函数一个独立的隔离环境。""" # 可以在这里配置上下文选项，如视口大小、语言、权限等 context = browser.new_context( viewport={"width": 1920, "height": 1080}, locale="zh-CN", # 忽略HTTPS错误（仅测试环境使用） ignore_https_errors=True ) yield context context.close() @pytest.fixture(scope="function") def page(context: BrowserContext) -> Page: """函数级别的页面对象。""" page = context.new_page() yield page page.close() @pytest.fixture(scope="function") def api_request(context: BrowserContext) -> APIRequestContext: """【核心】函数级别的API请求对象，与`context`共享状态。""" # 直接从共享的context中创建request对象 request = context.request # 可以在这里设置一些全局请求头，如Content-Type request.set_extra_http_headers({ "Content-Type": "application/json", }) yield request # request对象不需要显式关闭，它会随context一起销毁。

这个配置为每个测试函数提供了一个干净的沙箱（context），以及在这个沙箱中工作的两个工具：操作页面的page和调用接口的api_request。它们的状态完全同步。

4.3 封装Page Object与API Client

为了代码更清晰、可维护，我们需要对UI操作和接口调用进行分层封装。

封装Page Object(pages/login_page.py)：

# pages/login_page.py from playwright.sync_api import Page class LoginPage: def __init__(self, page: Page): self.page = page self.username_input = page.locator("#username") self.password_input = page.locator("#password") self.submit_button = page.locator("button[type='submit']") self.error_message = page.locator(".alert-error") def navigate(self): self.page.goto("https://example.com/login") def login(self, username: str, password: str): self.username_input.fill(username) self.password_input.fill(password) self.submit_button.click() def get_error_message(self) -> str: return self.error_message.text_content() or ""

封装API Client(api/user_api.py)：

# api/user_api.py from typing import Optional, Dict, Any from playwright.sync_api import APIRequestContext class UserApiClient: def __init__(self, request: APIRequestContext, base_url: str = "https://api.example.com"): self.request = request self.base_url = base_url.rstrip('/') def login(self, username: str, password: str) -> Dict[str, Any]: """通过API登录，返回响应数据。""" response = self.request.post( f"{self.base_url}/auth/login", data={"username": username, "password": password} ) response.raise_for_status() # 如果状态码不是2xx，抛出异常 return response.json() def get_profile(self) -> Dict[str, Any]: """获取当前用户资料（需要登录态）。""" response = self.request.get(f"{self.base_url}/user/profile") response.raise_for_status() return response.json() def update_profile(self, data: Dict) -> Dict[str, Any]: """更新用户资料。""" response = self.request.put(f"{self.base_url}/user/profile", data=data) response.raise_for_status() return response.json()

4.4 编写融合测试用例

现在，我们可以编写一个真正的融合测试用例了。这个用例将演示“接口优先，UI验证”模式。

# tests/test_login_fusion.py import pytest from pages.login_page import LoginPage from api.user_api import UserApiClient class TestLoginFusion: """测试登录功能的融合场景。""" def test_login_via_api_then_verify_ui(self, page: Page, api_request: APIRequestContext): """ 场景：通过API完成登录，然后打开UI页面，验证UI上显示的用户信息与API返回的一致。 模式：接口优先，UI验证。 """ # 1. 初始化API客户端和Page Object user_api = UserApiClient(api_request, base_url="https://api.example.com") login_page = LoginPage(page) # 2. 【接口操作】通过API登录，获取用户数据和认证状态 login_data = user_api.login(username="test_user", password="secure_pass_123") assert login_data["code"] == 0, f"API登录失败: {login_data}" auth_token = login_data["data"]["token"] user_info_from_api = login_data["data"]["user"] # 3. 【状态同步】将认证Token注入到Page的上下文中（假设前端通过localStorage校验） # 这步是关键，让UI页面能识别出已登录状态 page.add_init_script(f""" window.localStorage.setItem('auth_token', '{auth_token}'); window.localStorage.setItem('user_info', JSON.stringify({user_info_from_api})); """) # 4. 【UI操作】导航到需要登录后才能访问的仪表盘页面 # 注意：这里不是去登录页，而是直接去受保护的页面 page.goto("https://example.com/dashboard") # 5. 【UI验证】在页面上断言用户信息正确显示 # 假设仪表盘页有一个元素显示用户名 welcome_element = page.locator(".welcome-message") # 等待元素出现并获取文本 welcome_text = welcome_element.text_content() assert user_info_from_api["name"] in welcome_text, f"UI显示的用户名[{welcome_text}]与API返回的[{user_info_from_api['name']}]不符" # 假设有一个用户头像，其src属性包含用户ID avatar_element = page.locator(".user-avatar img") avatar_src = avatar_element.get_attribute("src") assert str(user_info_from_api["id"]) in avatar_src, f"头像链接不包含用户ID: {avatar_src}" # 6. （可选）【二次接口验证】再次调用API，确保UI操作没有破坏登录态 profile_after_ui = user_api.get_profile() assert profile_after_ui["data"]["id"] == user_info_from_api["id"], "UI操作后，API登录态异常" def test_ui_login_intercept_api(self, page: Page, api_request: APIRequestContext): """ 场景：在UI登录过程中，拦截登录API请求，验证请求参数，并模拟一个自定义响应。 模式：UI触发，接口断言（并模拟）。 """ login_page = LoginPage(page) login_page.navigate() # 在点击登录按钮前，先拦截登录API intercepted_request_data = {} def intercept_login_route(route): request = route.request intercepted_request_data["url"] = request.url intercepted_request_data["method"] = request.method # 尝试获取POST数据（JSON格式） try: intercepted_request_data["post_data"] = request.post_data_json except: intercepted_request_data["post_data"] = None # 关键：这里我们不继续真实请求，而是直接返回一个模拟的成功响应 # 这可以用于测试前端对特定响应（如新用户引导）的处理逻辑 route.fulfill( status=200, headers={"Content-Type": "application/json"}, body='{"code": 0, "data": {"token": "mock_token_999", "user": {"name": "MockUser"}}, "msg": "登录成功（模拟）"}' ) # 开始路由监听 page.route("**/auth/login", intercept_login_route) # 执行UI登录操作 login_page.login(username="test", password="test") # 断言拦截到的请求参数 assert intercepted_request_data["method"] == "POST" assert intercepted_request_data["post_data"] == {"username": "test", "password": "test"} # 断言UI根据模拟响应做出了正确反应（例如，跳转到了引导页） # 注意：因为我们模拟了响应，所以实际后端并未收到请求，这里验证的是前端逻辑 page.wait_for_url("**/guide") # 假设模拟响应会让前端跳转到引导页 assert page.locator("h1:has-text('欢迎新用户')").is_visible()

这个测试类展示了两种典型的融合模式。第一个测试用例test_login_via_api_then_verify_ui高效且稳定，适合用于冒烟测试或核心流程验证。第二个测试用例test_ui_login_intercept_api则更侧重于前端逻辑和异常场景的验证。

5. 常见问题、排查技巧与性能优化

在实际项目中落地融合测试，你会遇到各种挑战。下面是我踩过坑后总结的一些经验和技巧。

5.1 常见问题与解决方案速查表

5.2 性能优化与最佳实践

1. Fixture作用域管理：

   • playwright_instance和browser使用scope="session"，避免重复启动Playwright和浏览器进程，这是最大的性能提升点。
   • context和page使用scope="function"，保证测试之间的隔离性。虽然创建新的Context有一定开销，但远小于启动新浏览器，且能保证测试纯净。

2. 并行测试： Playwright支持并行测试。在Pytest中，可以使用pytest-xdist插件。关键点：并行时，每个Worker进程需要有自己的Browser实例。我们的Fixture配置（browser是session级别）在默认情况下可能不兼容。更安全的做法是将browserfixture也设置为scope="function"或使用@pytest.fixture(scope="class")，但这会牺牲一些性能。或者，使用Playwright提供的playwright.chromium.launch_server()启动浏览器服务器，让多个测试进程连接同一个浏览器实例（更高级，需仔细处理隔离）。

3. 视频与追踪录制： 在调试难以复现的问题时，开启视频录制和追踪（Trace）是救命稻草。可以在contextfixture中配置：

   @pytest.fixture(scope="function") def context(browser): context = browser.new_context( record_video_dir="videos/", record_video_size={"width": 1920, "height": 1080} ) # 或者更强大的追踪功能 # context.tracing.start(screenshots=True, snapshots=True, sources=True) yield context # 测试失败时保存追踪文件 # if request.node.rep_call.failed: # context.tracing.stop(path=f"trace_{request.node.name}.zip") context.close()

   记得在CI流水线中清理或上传这些产物。

4. 数据驱动与测试隔离： 融合测试涉及UI和接口，对测试数据的要求更高。务必保证每个测试用例使用独立的数据，避免用例间相互影响。可以通过在接口准备阶段创建带唯一标识的数据（如f"test_order_{uuid.uuid4().hex[:8]}"），并在测试后通过接口清理（teardown）来实现。

5. 选择正确的等待策略：

   • 网络请求：page.wait_for_load_state(“networkidle”)等待页面主要资源加载完成。
   • 元素状态：locator.wait_for(state=”visible”)等待元素可见。
   • 自定义条件：page.wait_for_function()等待前端JS状态。
   • 绝对避免：除非万不得已，不要使用time.sleep()。它不可靠且低效。

5.3 一个真实的排错案例：Cookie域不匹配

我曾遇到一个棘手问题：通过api_request登录成功，Cookie也已存在context中，但导航到UI页面后，页面显示未登录。

排查过程：

1. 首先，我打印了登录后context中的所有Cookie：print(context.cookies())。发现Cookie的domain字段是.api.example.com。
2. 然后，我导航到的UI页面URL是https://www.example.com/dashboard。
3. 问题浮出水面：Cookie的域（.api.example.com）与UI页面的域（www.example.com）不完全匹配。浏览器出于安全原因（SameSite策略），不会将.api.example.com的Cookie发送到www.example.com。

解决方案：

• 方案一（推荐，治本）：协调开发，将API和前端主站部署在相同的顶级域下（例如，API用https://example.com/api，前端用https://example.com），这样Cookie可以共享（domain设置为.example.com）。
• 方案二（测试环境变通）：在启动测试浏览器时，通过--host-resolver-rules参数或修改系统的hosts文件，将www.example.com和api.example.com都映射到同一个IP（如测试服务器IP），这样浏览器会认为它们是同一个站点（Scheme+Domain+Port相同）。
• 方案三（仅限简单测试）：如果前端支持，在登录API响应中，除了返回Token，也返回用户信息。然后通过page.add_init_script直接将用户信息写入localStorage或sessionStorage，完全绕过Cookie。正如我们在示例代码中所做的那样。

这个案例告诉我们，在融合测试中，对HTTP基础（如Cookie、同源策略）的理解至关重要。当状态共享失败时，第一步就是检查网络请求和响应的头部信息，以及浏览器开发者工具中Application标签页下的Storage状态。