1. 项目概述为什么我们需要关注Playwright的上下文Context如果你已经开始用Playwright做自动化测试并且已经能熟练地用browser.new_page()打开页面、定位元素、点击按钮那你可能会觉得自动化测试不过如此。但当你开始尝试更复杂的场景比如同时操作多个标签页、处理多个独立登录会话、或者需要为每个测试用例配置不同的网络环境比如模拟不同的地理位置、语言或设备类型时仅仅依靠Page对象就会显得力不从心甚至会让你的测试脚本变得混乱不堪。这时Context上下文就该登场了。在Playwright的架构里Context是一个比Page更高一级、但又比Browser更灵活的核心概念。你可以把它想象成一个独立的、沙盒化的浏览器会话环境。每个Context都拥有自己独立的存储如Cookies、LocalStorage、权限设置如地理位置、通知、网络代理配置以及一系列Page对象。它就像是浏览器的一个“分身”每个分身之间互不干扰但又共享同一个浏览器进程的资源这比直接启动多个浏览器实例要高效得多。我刚开始接触Playwright时也一度忽略了Context所有操作都在默认上下文中进行。结果在写一个需要同时登录两个不同账号的测试时Cookies互相覆盖测试直接乱套。后来深入研究Context才发现它才是Playwright设计精髓的体现是构建稳定、高效、可并行化测试套件的基石。理解并善用Context能让你的自动化测试从“能用”跃升到“好用且强大”。2. 核心概念拆解Browser、Context、Page的三层关系要玩转Context必须先彻底理清Playwright的核心对象模型。很多混乱都源于对这三者关系的模糊理解。2.1 对象层级与生命周期Playwright采用了一个清晰的三层结构Browser-Context-Page。这是一个严格的“父子”包含关系。Browser浏览器实例这是最顶层对象代表一个真实的浏览器进程如Chromium、Firefox、WebKit。通过playwright.chromium.launch()启动。一个Browser对象可以创建多个Context。它的生命周期最长通常在整个测试套件开始时启动结束时关闭。Context浏览器上下文这是本次讨论的核心。一个Context隶属于一个Browser你可以通过browser.new_context()来创建。每个Context都是独立的会话环境拥有独立的存储隔离Cookies、LocalStorage、SessionStorage、IndexedDB等。权限隔离摄像头、麦克风、地理位置、通知等权限授予状态。网络配置隔离代理设置、请求/响应拦截、网络模拟离线、慢速3G。视觉配置隔离视口大小、设备缩放、色彩方案明/暗模式、是否支持触摸。JavaScript执行环境虽然共享浏览器内核但通过Context注入的脚本如add_init_script是隔离的。一个Context可以创建多个Page标签页。Context的生命周期通常与一个测试用例或一组相关操作绑定。Page页面/标签页这是我们最常打交道的对象代表一个浏览器标签页。通过context.new_page()或browser.new_page()后者会隐式创建一个默认Context创建。它包含了DOM、执行JavaScript、与页面元素交互的所有能力。一个生动的比喻把Browser想象成一座办公楼。Context就是楼里的一个个独立、隔音的会议室。每个会议室Context有自己的白板存储、会议设备权限、网络接口网络配置并且互不干扰。Page则是会议室里打开的一个个演示文稿或网页你可以在一个会议室里打开多个文稿多个Page但这些文稿都共享这个会议室的资源。2.2 默认上下文的陷阱当你使用browser.new_page()时Playwright实际上为你创建了一个默认的匿名Context然后在这个Context下创建Page。问题在于所有通过这种方式创建的Page都共享同一个默认Context。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建两个页面但它们共享同一个隐式的默认Context page1 await browser.new_page() page2 await browser.new_page() await page1.goto(https://example.com) # 在page1上设置一个cookie await page1.context.add_cookies([{name: token, value: secret123, url: https://example.com}]) # page2访问同一个域名它会携带page1设置的cookie await page2.goto(https://example.com) cookies await page2.context.cookies() print(cookies) # 你会看到包含token的cookie列表 await browser.close() asyncio.run(main())上面的代码展示了陷阱page1和page2因为共享默认Context它们的存储是共通的。这在大多数单用户流测试中可能没问题但一旦涉及多用户、多会话或需要环境隔离的测试就会导致状态污染让测试结果不可预测。实操心得养成好习惯除非是非常简单、独立的单页面测试否则显式地创建和管理Context。使用browser.new_context()来获得一个干净的、可配置的隔离环境这是编写可靠测试的第一步。3. 上下文Context的核心能力与实战配置理解了Context是什么接下来我们看看它能做什么。Context的威力在于其丰富的配置选项让你能精细地控制测试环境。3.1 创建与基础配置创建Context时可以通过传递一个字典来进行全方位配置。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建一个具有特定视口、用户代理和地理位置的上下文 context await browser.new_context( viewport{width: 1920, height: 1080}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, localezh-CN, # 设置浏览器语言为中文 timezone_idAsia/Shanghai, # 设置时区 geolocation{longitude: 121.4737, latitude: 31.2304}, # 上海坐标 permissions[geolocation], # 授予地理位置权限 color_schemedark, # 强制暗黑模式 reduced_motionreduce # 减少动画有助于测试稳定性 ) page await context.new_page() await page.goto(https://maps.example.com) # 该页面将直接拥有上海的地理位置和暗黑模式 # ... 你的测试逻辑 await context.close() await browser.close() asyncio.run(main())配置项解析viewport 控制浏览器窗口大小对测试响应式布局至关重要。user_agentlocale 模拟特定设备和地区用户常用于兼容性测试或本地化测试。geolocationpermissions 配合使用模拟用户地理位置并授予权限测试基于位置的功能。color_scheme 测试应用在明/暗模式下的表现。reduced_motion 这是一个很好的实践减少页面动画可以加快测试执行速度并避免因动画未完成导致的元素定位失败。3.2 存储状态的管理与复用这是Context最实用的功能之一。你可以保存一个Context的完整状态主要是存储然后在另一个测试中还原从而跳过繁琐的登录等前置步骤。import asyncio import json from playwright.async_api import async_playwright async def test_login_and_save_state(): 测试用例1登录并保存状态 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) context await browser.new_context() page await context.new_page() await page.goto(https://your-app.com/login) await page.fill(#username, test_user) await page.fill(#password, test_pass) await page.click(button[typesubmit]) await page.wait_for_url(**/dashboard) # 等待登录成功 # 关键步骤将当前上下文的状态cookies, storage保存到文件 await context.storage_state(path./auth_state.json) await context.close() await browser.close() async def test_use_saved_state(): 测试用例2使用保存的状态直接进入登录后页面 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建新上下文时直接加载之前保存的状态 context await browser.new_context(storage_state./auth_state.json) page await context.new_page() # 无需再次登录直接访问受保护页面 await page.goto(https://your-app.com/dashboard) # 页面应直接显示登录后的内容 await page.wait_for_selector(textWelcome, test_user) await context.close() await browser.close() # 先运行第一个再运行第二个 # asyncio.run(test_login_and_save_state()) # asyncio.run(test_use_saved_state())注意事项storage_state保存的是与特定域名关联的存储。确保加载状态时访问的域名与保存时一致。状态文件可能包含敏感信息如Session Tokens务必妥善管理不要提交到代码仓库。可以考虑使用环境变量或密钥管理服务来传递文件路径或加密内容。对于需要定期更新的登录状态如Token过期需要设计状态刷新机制。3.3 网络层控制与模拟Context提供了强大的网络控制能力可以拦截和修改请求/响应或者模拟不同的网络条件。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 模拟慢速3G网络 context await browser.new_context( **p.devices[iPhone 12], # 使用预设的设备配置 # 覆盖网络条件 offlineFalse, # 模拟网络速度 extra_http_headers{X-Custom-Header: MyValue} ) # 更细粒度的网络模拟需要在创建context后通过context.route或page.route实现 page await context.new_page() # 示例拦截所有图片请求阻止加载以加速测试 await page.route(**/*.{png,jpg,jpeg,webp,gif,svg}, lambda route: route.abort()) # 示例修改特定API请求的响应 async def modify_response(route): response await route.fetch() body await response.text() # 修改响应体例如注入测试数据 new_body body.replace(status: pending, status: success) await route.fulfill( responseresponse, bodynew_body, headers{**response.headers, Content-Type: application/json} ) await page.route(**/api/order/*, modify_response) await page.goto(https://your-app.com) # 此时页面图片不会加载且特定API返回了修改后的数据 await page.wait_for_timeout(2000) await context.close() await browser.close() asyncio.run(main())网络模拟的价值性能测试模拟2G、3G、4G等网络条件测试应用在弱网下的表现和降级策略。稳定性测试模拟网络超时、中断验证应用的错误处理和重试机制。Mock外部依赖通过拦截和修改请求/响应可以模拟第三方API的成功、失败或延迟返回使测试不依赖外部不稳定服务实现真正的单元/集成测试隔离。测试优化通过阻止非必要资源如图片、样式表、分析脚本的加载可以显著加快测试执行速度。4. 高级应用模式与架构设计掌握了Context的基本操作后我们可以将其运用到更复杂的测试架构中解决实际工程问题。4.1 实现真正的并行与隔离测试在UI自动化测试中并行化是缩短测试反馈周期的关键。利用Context的隔离性我们可以安全地在同一个浏览器进程中运行多个独立的测试。import asyncio import pytest from playwright.async_api import async_playwright, Browser # 假设我们使用pytest-playwright插件它已经提供了很好的fixture支持 # 这里展示一个自定义的、更可控的并行模式 class TestIsolationSuite: 演示如何使用独立Context实现测试隔离 pytest.mark.asyncio async def test_user_a_flow(self, browser: Browser): 用户A的完整流程 # 为测试A创建专属的、干净的环境 context_a await browser.new_context( storage_stateNone, # 确保全新状态 viewport{width: 1280, height: 720} ) page_a await context_a.new_page() await page_a.goto(https://your-app.com) # 执行用户A的测试逻辑... await page_a.click(textSign Up) await page_a.fill(#email, user_atest.com) # ... 其他操作 # 断言仅与用户A相关 assert await page_a.inner_text(h1) Welcome, user_a! await context_a.close() # 测试结束清理环境 pytest.mark.asyncio async def test_user_b_flow(self, browser: Browser): 用户B的流程与A完全并行且隔离 # 即使和test_user_a_flow同时运行也互不影响 context_b await browser.new_context( storage_stateNone, viewport{width: 1920, height: 1080} # 甚至可以不同视图 ) page_b await context_b.new_page() await page_b.goto(https://your-app.com) # 执行用户B的测试逻辑可能是完全不同的操作路径 await page_b.click(textLogin) await page_b.fill(#email, user_btest.com) # ... assert await page_b.is_visible(textDashboard) await context_b.close() # 在pytest中可以通过 pytest -n auto 参数让这两个测试用例真正并行执行 # 因为它们使用了独立的Context所以不会发生Cookie冲突或页面干扰。架构优势独立性每个测试用例拥有自己的沙盒测试结果稳定可靠。可并行性多个Context可以在单个Browser实例内高效并行资源利用率高。灵活性可以为不同测试用例配置不同的环境设备、权限、网络。4.2 多场景身份切换测试测试一个支持多角色如普通用户、管理员、审核员的系统时频繁登录注销效率极低。利用Context和storage_state可以轻松实现身份“热切换”。import asyncio from playwright.async_api import async_playwright class MultiRoleTester: 一个管理多角色测试上下文的辅助类 def __init__(self, browser): self.browser browser self.contexts {} # 存储不同角色的上下文 async def login_as_role(self, role_name, login_credentials): 为特定角色登录并创建/缓存上下文 if role_name in self.contexts: print(f角色 {role_name} 的上下文已存在复用中...) return self.contexts[role_name] print(f正在为角色 {role_name} 创建新上下文并登录...) # 创建全新的隔离环境 context await self.browser.new_context() page await context.new_page() # 执行该角色特定的登录流程 await page.goto(https://your-app.com/login) # 根据角色使用不同的凭证 await page.fill(#username, login_credentials[username]) await page.fill(#password, login_credentials[password]) await page.click(button[typesubmit]) await page.wait_for_load_state(networkidle) # 可选保存状态到文件供后续测试直接加载 state_path f./state_{role_name}.json await context.storage_state(pathstate_path) print(f角色 {role_name} 登录状态已保存至 {state_path}) self.contexts[role_name] context return context async def get_page_for_role(self, role_name): 获取指定角色的一个新页面 context self.contexts.get(role_name) if not context: raise ValueError(f角色 {role_name} 的上下文未初始化请先调用 login_as_role) return await context.new_page() async def cleanup(self): 清理所有上下文 for ctx in self.contexts.values(): await ctx.close() self.contexts.clear() async def test_cross_role_interaction(): 测试普通用户提交内容管理员审核的场景 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) tester MultiRoleTester(browser) # 初始化用户和管理员会话 user_ctx await tester.login_as_role(user, {username: alice, password: pass123}) admin_ctx await tester.login_as_role(admin, {username: admin, password: admin123}) # 场景1用户创建一篇帖子 user_page await user_ctx.new_page() await user_page.goto(https://your-app.com/create-post) await user_page.fill(#title, 测试帖子) await user_page.fill(#content, 这是由自动化测试创建的帖子内容。) await user_page.click(button[typesubmit]) post_id await user_page.inner_text(.post-id) # 假设页面返回了帖子ID print(f用户创建了帖子ID: {post_id}) await user_page.close() # 场景2管理员在独立的上下文中审核该帖子 admin_page await admin_ctx.new_page() await admin_page.goto(https://your-app.com/admin/pending-posts) # 管理员页面应该能看到用户刚提交的帖子 await admin_page.wait_for_selector(ftext{post_id}) await admin_page.click(ftext{post_id}) await admin_page.click(button:has-text(Approve)) print(管理员批准了帖子) # 场景3用户刷新页面应看到帖子状态变为“已批准” user_page2 await user_ctx.new_page() await user_page2.goto(fhttps://your-app.com/post/{post_id}) status await user_page2.inner_text(.post-status) assert status Approved, f预期状态为Approved实际为{status} print(用户确认帖子状态已更新) await tester.cleanup() await browser.close() asyncio.run(test_cross_role_interaction())这种模式将测试逻辑与身份管理解耦使测试脚本更清晰也更容易扩展增加新角色只需新增登录逻辑。它完美体现了Context在管理复杂测试状态时的价值。4.3 与Pytest等测试框架的深度集成在实际项目中我们很少直接写裸脚本。与测试框架如Pytest集成能更好地管理Context的生命周期。利用Pytest Fixture管理Context# conftest.py import pytest import asyncio from playwright.async_api import async_playwright, Browser, BrowserContext pytest.fixture(scopesession) def event_loop(): 为异步测试创建事件循环 loop asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() pytest.fixture(scopesession) async def browser(): 会话级别的浏览器实例 async with async_playwright() as p: # 可配置化启动参数例如从环境变量读取 browser await p.chromium.launch( headlessTrue, # 无头模式适合CI环境 args[--disable-dev-shm-usage] # Docker环境常用参数 ) yield browser await browser.close() pytest.fixture async def context(browser: Browser): 函数级别的上下文每个测试函数一个干净的隔离环境 # 可以在这里加载通用的存储状态如基础用户登录态 # storage_state ./auth_state.json if os.path.exists(./auth_state.json) else None context await browser.new_context( viewport{width: 1920, height: 1080}, ignore_https_errorsTrue, # 忽略HTTPS证书错误用于测试环境 # storage_statestorage_state ) yield context await context.close() # 测试结束后自动清理保证隔离 pytest.fixture async def page(context: BrowserContext): 函数级别的页面最常用的fixture page await context.new_page() yield page await page.close() # test_example.py import pytest pytest.mark.asyncio async def test_with_fixtures(page): 使用fixture无需手动管理浏览器、上下文和页面的生命周期 await page.goto(https://example.com) title await page.title() assert Example in titleFixture的优势生命周期管理自动化Pytest自动处理Context和Page的创建与销毁避免资源泄漏。依赖注入清晰测试函数声明需要什么page,context框架就注入什么代码意图明确。灵活的作用域session作用域的browser在整个测试会话中只启动一次高效function作用域的context和page为每个测试提供干净环境可靠。易于配置可以在conftest.py中集中管理所有配置如视口、代理、设备模拟测试文件无需关心环境细节。5. 常见问题、性能优化与避坑指南在实际使用Context的过程中你会遇到一些典型问题和性能考量。这里记录了我踩过的一些坑和总结的优化技巧。5.1 常见问题排查速查表问题现象可能原因解决方案测试用例间状态污染多个测试共享了同一个默认Context或同一个Page对象。为每个独立的测试用例创建独立的Context使用browser.new_context()。在Pytest中使用function作用域的contextfixture。登录状态丢失或无效1.storage_state保存和加载的域名不一致。2. Token已过期。3. 保存的状态文件被损坏或格式错误。1. 检查保存和加载状态时访问的baseURL是否一致。2. 实现状态有效性检查过期则重新登录。3. 手动检查JSON文件格式或尝试重新生成。网络拦截route不生效1.page.route或context.route调用时机太晚请求已发出。2. URL模式匹配不正确。3. 在page.goto()之后才设置路由。1.在导航之前设置路由。对于context级别的路由在创建page之前设置。2. 使用Playwright的调试工具playwright codegen或PWDEBUG1检查网络请求的实际URL。3. 确保路由设置在page.goto()、page.click()等触发导航的操作之前。内存泄漏测试越跑越慢创建的Context和Page对象没有正确关闭。1. 始终使用async with语句或确保在finally块中调用await context.close()和await page.close()。2. 使用Pytest等框架的fixture来自动管理生命周期。并行测试时出现随机失败1. 测试本身非幂等依赖共享的外部状态如数据库序列。2. 硬件资源CPU/内存不足。3.Context配置冲突如端口占用。1. 保证每个测试用例数据独立使用随机或唯一的测试数据。2. 限制并行 worker 数量如pytest -n 2。3. 确保为每个Context配置了不同的、不冲突的选项如通过--proxy-server指定不同端口的代理时。5.2 性能优化实践复用Browser按需创建Context启动浏览器的开销是最大的。最佳实践是在测试会话开始时启动一个Browser实例所有测试共用它但每个测试创建自己独立的Context。这平衡了启动速度和测试隔离性。谨慎使用存储状态虽然storage_state能跳过登录但加载一个大的状态文件也有开销。对于非常短小的、不依赖登录状态的测试如检查首页元素直接使用全新的Context可能更快。阻止非必要资源使用context.route或page.route拦截并中止对图片、样式表、字体、分析脚本等资源的请求可以极大提升测试执行速度尤其是在复杂页面上。# 在创建页面或导航前在context上设置路由 await context.route(**/*.{png,jpg,jpeg,webp,gif,svg,ico,css,woff,woff2}, lambda route: route.abort()) # 或者更激进只允许HTML和必要的JS # await context.route(**/*, lambda route: route.abort() if route.request.resource_type not in [document, script] else route.continue_())注意此操作会改变页面渲染效果仅适用于不依赖这些资源视觉或功能的逻辑测试。对于视觉回归测试或需要完整渲染的测试请勿使用。使用无头Headless模式在CI/CD管道或不需要观察UI的测试中始终使用headlessTrue。无头模式消耗资源更少运行更快。合理配置视口与设备模拟如果没有特定需求使用一个标准的视口大小如{width: 1920, height: 1080}避免频繁切换。设备模拟如p.devices[iPhone 12]会带来额外开销只在需要时使用。5.3 一个关于Context关闭的深度坑我遇到过最隐蔽的一个Bug是测试大部分时间通过但偶尔会超时或失败。最终定位到是因为在一个复杂的测试函数中我创建了多个Page对象但在某些异常分支路径上没有确保每个Page都被关闭。# ❌ 有风险的代码 async def risky_test(context): page1 await context.new_page() page2 await context.new_page() try: await page1.goto(...) if some_condition: # 如果条件成立page2没有被close return await page2.goto(...) finally: await page1.close() # page2 可能没有被关闭导致资源泄漏最佳实践使用async with语句来管理Page的生命周期这是最安全的方式。# ✅ 安全的代码 async def safe_test(context): async with await context.new_page() as page1: await page1.goto(...) if some_condition: return # async with 会确保page1被自动关闭 # 如果需要另一个页面再开一个块 async with await context.new_page() as page2: await page2.goto(...)对于Context同样建议在测试函数或Fixture中使用async with或明确的close()调用。未关闭的Context会占用内存和端口积累多了可能导致浏览器崩溃或端口耗尽错误。理解Context不仅仅是学会一个API调用。它是你设计Playwright自动化测试架构时的核心思维模型。从简单的环境隔离到复杂的多角色场景模拟再到性能优化和资源管理Context都是你手中最得力的工具。下次写测试时不妨先问自己“这个测试需要什么样的上下文环境” 想清楚这个问题你的测试代码离“优雅”和“健壮”就更近了一步。
1. 项目概述为什么我们需要关注Playwright的上下文Context如果你已经开始用Playwright做自动化测试并且已经能熟练地用browser.new_page()打开页面、定位元素、点击按钮那你可能会觉得自动化测试不过如此。但当你开始尝试更复杂的场景比如同时操作多个标签页、处理多个独立登录会话、或者需要为每个测试用例配置不同的网络环境比如模拟不同的地理位置、语言或设备类型时仅仅依靠Page对象就会显得力不从心甚至会让你的测试脚本变得混乱不堪。这时Context上下文就该登场了。在Playwright的架构里Context是一个比Page更高一级、但又比Browser更灵活的核心概念。你可以把它想象成一个独立的、沙盒化的浏览器会话环境。每个Context都拥有自己独立的存储如Cookies、LocalStorage、权限设置如地理位置、通知、网络代理配置以及一系列Page对象。它就像是浏览器的一个“分身”每个分身之间互不干扰但又共享同一个浏览器进程的资源这比直接启动多个浏览器实例要高效得多。我刚开始接触Playwright时也一度忽略了Context所有操作都在默认上下文中进行。结果在写一个需要同时登录两个不同账号的测试时Cookies互相覆盖测试直接乱套。后来深入研究Context才发现它才是Playwright设计精髓的体现是构建稳定、高效、可并行化测试套件的基石。理解并善用Context能让你的自动化测试从“能用”跃升到“好用且强大”。2. 核心概念拆解Browser、Context、Page的三层关系要玩转Context必须先彻底理清Playwright的核心对象模型。很多混乱都源于对这三者关系的模糊理解。2.1 对象层级与生命周期Playwright采用了一个清晰的三层结构Browser-Context-Page。这是一个严格的“父子”包含关系。Browser浏览器实例这是最顶层对象代表一个真实的浏览器进程如Chromium、Firefox、WebKit。通过playwright.chromium.launch()启动。一个Browser对象可以创建多个Context。它的生命周期最长通常在整个测试套件开始时启动结束时关闭。Context浏览器上下文这是本次讨论的核心。一个Context隶属于一个Browser你可以通过browser.new_context()来创建。每个Context都是独立的会话环境拥有独立的存储隔离Cookies、LocalStorage、SessionStorage、IndexedDB等。权限隔离摄像头、麦克风、地理位置、通知等权限授予状态。网络配置隔离代理设置、请求/响应拦截、网络模拟离线、慢速3G。视觉配置隔离视口大小、设备缩放、色彩方案明/暗模式、是否支持触摸。JavaScript执行环境虽然共享浏览器内核但通过Context注入的脚本如add_init_script是隔离的。一个Context可以创建多个Page标签页。Context的生命周期通常与一个测试用例或一组相关操作绑定。Page页面/标签页这是我们最常打交道的对象代表一个浏览器标签页。通过context.new_page()或browser.new_page()后者会隐式创建一个默认Context创建。它包含了DOM、执行JavaScript、与页面元素交互的所有能力。一个生动的比喻把Browser想象成一座办公楼。Context就是楼里的一个个独立、隔音的会议室。每个会议室Context有自己的白板存储、会议设备权限、网络接口网络配置并且互不干扰。Page则是会议室里打开的一个个演示文稿或网页你可以在一个会议室里打开多个文稿多个Page但这些文稿都共享这个会议室的资源。2.2 默认上下文的陷阱当你使用browser.new_page()时Playwright实际上为你创建了一个默认的匿名Context然后在这个Context下创建Page。问题在于所有通过这种方式创建的Page都共享同一个默认Context。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建两个页面但它们共享同一个隐式的默认Context page1 await browser.new_page() page2 await browser.new_page() await page1.goto(https://example.com) # 在page1上设置一个cookie await page1.context.add_cookies([{name: token, value: secret123, url: https://example.com}]) # page2访问同一个域名它会携带page1设置的cookie await page2.goto(https://example.com) cookies await page2.context.cookies() print(cookies) # 你会看到包含token的cookie列表 await browser.close() asyncio.run(main())上面的代码展示了陷阱page1和page2因为共享默认Context它们的存储是共通的。这在大多数单用户流测试中可能没问题但一旦涉及多用户、多会话或需要环境隔离的测试就会导致状态污染让测试结果不可预测。实操心得养成好习惯除非是非常简单、独立的单页面测试否则显式地创建和管理Context。使用browser.new_context()来获得一个干净的、可配置的隔离环境这是编写可靠测试的第一步。3. 上下文Context的核心能力与实战配置理解了Context是什么接下来我们看看它能做什么。Context的威力在于其丰富的配置选项让你能精细地控制测试环境。3.1 创建与基础配置创建Context时可以通过传递一个字典来进行全方位配置。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建一个具有特定视口、用户代理和地理位置的上下文 context await browser.new_context( viewport{width: 1920, height: 1080}, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, localezh-CN, # 设置浏览器语言为中文 timezone_idAsia/Shanghai, # 设置时区 geolocation{longitude: 121.4737, latitude: 31.2304}, # 上海坐标 permissions[geolocation], # 授予地理位置权限 color_schemedark, # 强制暗黑模式 reduced_motionreduce # 减少动画有助于测试稳定性 ) page await context.new_page() await page.goto(https://maps.example.com) # 该页面将直接拥有上海的地理位置和暗黑模式 # ... 你的测试逻辑 await context.close() await browser.close() asyncio.run(main())配置项解析viewport 控制浏览器窗口大小对测试响应式布局至关重要。user_agentlocale 模拟特定设备和地区用户常用于兼容性测试或本地化测试。geolocationpermissions 配合使用模拟用户地理位置并授予权限测试基于位置的功能。color_scheme 测试应用在明/暗模式下的表现。reduced_motion 这是一个很好的实践减少页面动画可以加快测试执行速度并避免因动画未完成导致的元素定位失败。3.2 存储状态的管理与复用这是Context最实用的功能之一。你可以保存一个Context的完整状态主要是存储然后在另一个测试中还原从而跳过繁琐的登录等前置步骤。import asyncio import json from playwright.async_api import async_playwright async def test_login_and_save_state(): 测试用例1登录并保存状态 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) context await browser.new_context() page await context.new_page() await page.goto(https://your-app.com/login) await page.fill(#username, test_user) await page.fill(#password, test_pass) await page.click(button[typesubmit]) await page.wait_for_url(**/dashboard) # 等待登录成功 # 关键步骤将当前上下文的状态cookies, storage保存到文件 await context.storage_state(path./auth_state.json) await context.close() await browser.close() async def test_use_saved_state(): 测试用例2使用保存的状态直接进入登录后页面 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 创建新上下文时直接加载之前保存的状态 context await browser.new_context(storage_state./auth_state.json) page await context.new_page() # 无需再次登录直接访问受保护页面 await page.goto(https://your-app.com/dashboard) # 页面应直接显示登录后的内容 await page.wait_for_selector(textWelcome, test_user) await context.close() await browser.close() # 先运行第一个再运行第二个 # asyncio.run(test_login_and_save_state()) # asyncio.run(test_use_saved_state())注意事项storage_state保存的是与特定域名关联的存储。确保加载状态时访问的域名与保存时一致。状态文件可能包含敏感信息如Session Tokens务必妥善管理不要提交到代码仓库。可以考虑使用环境变量或密钥管理服务来传递文件路径或加密内容。对于需要定期更新的登录状态如Token过期需要设计状态刷新机制。3.3 网络层控制与模拟Context提供了强大的网络控制能力可以拦截和修改请求/响应或者模拟不同的网络条件。import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) # 模拟慢速3G网络 context await browser.new_context( **p.devices[iPhone 12], # 使用预设的设备配置 # 覆盖网络条件 offlineFalse, # 模拟网络速度 extra_http_headers{X-Custom-Header: MyValue} ) # 更细粒度的网络模拟需要在创建context后通过context.route或page.route实现 page await context.new_page() # 示例拦截所有图片请求阻止加载以加速测试 await page.route(**/*.{png,jpg,jpeg,webp,gif,svg}, lambda route: route.abort()) # 示例修改特定API请求的响应 async def modify_response(route): response await route.fetch() body await response.text() # 修改响应体例如注入测试数据 new_body body.replace(status: pending, status: success) await route.fulfill( responseresponse, bodynew_body, headers{**response.headers, Content-Type: application/json} ) await page.route(**/api/order/*, modify_response) await page.goto(https://your-app.com) # 此时页面图片不会加载且特定API返回了修改后的数据 await page.wait_for_timeout(2000) await context.close() await browser.close() asyncio.run(main())网络模拟的价值性能测试模拟2G、3G、4G等网络条件测试应用在弱网下的表现和降级策略。稳定性测试模拟网络超时、中断验证应用的错误处理和重试机制。Mock外部依赖通过拦截和修改请求/响应可以模拟第三方API的成功、失败或延迟返回使测试不依赖外部不稳定服务实现真正的单元/集成测试隔离。测试优化通过阻止非必要资源如图片、样式表、分析脚本的加载可以显著加快测试执行速度。4. 高级应用模式与架构设计掌握了Context的基本操作后我们可以将其运用到更复杂的测试架构中解决实际工程问题。4.1 实现真正的并行与隔离测试在UI自动化测试中并行化是缩短测试反馈周期的关键。利用Context的隔离性我们可以安全地在同一个浏览器进程中运行多个独立的测试。import asyncio import pytest from playwright.async_api import async_playwright, Browser # 假设我们使用pytest-playwright插件它已经提供了很好的fixture支持 # 这里展示一个自定义的、更可控的并行模式 class TestIsolationSuite: 演示如何使用独立Context实现测试隔离 pytest.mark.asyncio async def test_user_a_flow(self, browser: Browser): 用户A的完整流程 # 为测试A创建专属的、干净的环境 context_a await browser.new_context( storage_stateNone, # 确保全新状态 viewport{width: 1280, height: 720} ) page_a await context_a.new_page() await page_a.goto(https://your-app.com) # 执行用户A的测试逻辑... await page_a.click(textSign Up) await page_a.fill(#email, user_atest.com) # ... 其他操作 # 断言仅与用户A相关 assert await page_a.inner_text(h1) Welcome, user_a! await context_a.close() # 测试结束清理环境 pytest.mark.asyncio async def test_user_b_flow(self, browser: Browser): 用户B的流程与A完全并行且隔离 # 即使和test_user_a_flow同时运行也互不影响 context_b await browser.new_context( storage_stateNone, viewport{width: 1920, height: 1080} # 甚至可以不同视图 ) page_b await context_b.new_page() await page_b.goto(https://your-app.com) # 执行用户B的测试逻辑可能是完全不同的操作路径 await page_b.click(textLogin) await page_b.fill(#email, user_btest.com) # ... assert await page_b.is_visible(textDashboard) await context_b.close() # 在pytest中可以通过 pytest -n auto 参数让这两个测试用例真正并行执行 # 因为它们使用了独立的Context所以不会发生Cookie冲突或页面干扰。架构优势独立性每个测试用例拥有自己的沙盒测试结果稳定可靠。可并行性多个Context可以在单个Browser实例内高效并行资源利用率高。灵活性可以为不同测试用例配置不同的环境设备、权限、网络。4.2 多场景身份切换测试测试一个支持多角色如普通用户、管理员、审核员的系统时频繁登录注销效率极低。利用Context和storage_state可以轻松实现身份“热切换”。import asyncio from playwright.async_api import async_playwright class MultiRoleTester: 一个管理多角色测试上下文的辅助类 def __init__(self, browser): self.browser browser self.contexts {} # 存储不同角色的上下文 async def login_as_role(self, role_name, login_credentials): 为特定角色登录并创建/缓存上下文 if role_name in self.contexts: print(f角色 {role_name} 的上下文已存在复用中...) return self.contexts[role_name] print(f正在为角色 {role_name} 创建新上下文并登录...) # 创建全新的隔离环境 context await self.browser.new_context() page await context.new_page() # 执行该角色特定的登录流程 await page.goto(https://your-app.com/login) # 根据角色使用不同的凭证 await page.fill(#username, login_credentials[username]) await page.fill(#password, login_credentials[password]) await page.click(button[typesubmit]) await page.wait_for_load_state(networkidle) # 可选保存状态到文件供后续测试直接加载 state_path f./state_{role_name}.json await context.storage_state(pathstate_path) print(f角色 {role_name} 登录状态已保存至 {state_path}) self.contexts[role_name] context return context async def get_page_for_role(self, role_name): 获取指定角色的一个新页面 context self.contexts.get(role_name) if not context: raise ValueError(f角色 {role_name} 的上下文未初始化请先调用 login_as_role) return await context.new_page() async def cleanup(self): 清理所有上下文 for ctx in self.contexts.values(): await ctx.close() self.contexts.clear() async def test_cross_role_interaction(): 测试普通用户提交内容管理员审核的场景 async with async_playwright() as p: browser await p.chromium.launch(headlessFalse) tester MultiRoleTester(browser) # 初始化用户和管理员会话 user_ctx await tester.login_as_role(user, {username: alice, password: pass123}) admin_ctx await tester.login_as_role(admin, {username: admin, password: admin123}) # 场景1用户创建一篇帖子 user_page await user_ctx.new_page() await user_page.goto(https://your-app.com/create-post) await user_page.fill(#title, 测试帖子) await user_page.fill(#content, 这是由自动化测试创建的帖子内容。) await user_page.click(button[typesubmit]) post_id await user_page.inner_text(.post-id) # 假设页面返回了帖子ID print(f用户创建了帖子ID: {post_id}) await user_page.close() # 场景2管理员在独立的上下文中审核该帖子 admin_page await admin_ctx.new_page() await admin_page.goto(https://your-app.com/admin/pending-posts) # 管理员页面应该能看到用户刚提交的帖子 await admin_page.wait_for_selector(ftext{post_id}) await admin_page.click(ftext{post_id}) await admin_page.click(button:has-text(Approve)) print(管理员批准了帖子) # 场景3用户刷新页面应看到帖子状态变为“已批准” user_page2 await user_ctx.new_page() await user_page2.goto(fhttps://your-app.com/post/{post_id}) status await user_page2.inner_text(.post-status) assert status Approved, f预期状态为Approved实际为{status} print(用户确认帖子状态已更新) await tester.cleanup() await browser.close() asyncio.run(test_cross_role_interaction())这种模式将测试逻辑与身份管理解耦使测试脚本更清晰也更容易扩展增加新角色只需新增登录逻辑。它完美体现了Context在管理复杂测试状态时的价值。4.3 与Pytest等测试框架的深度集成在实际项目中我们很少直接写裸脚本。与测试框架如Pytest集成能更好地管理Context的生命周期。利用Pytest Fixture管理Context# conftest.py import pytest import asyncio from playwright.async_api import async_playwright, Browser, BrowserContext pytest.fixture(scopesession) def event_loop(): 为异步测试创建事件循环 loop asyncio.get_event_loop_policy().new_event_loop() yield loop loop.close() pytest.fixture(scopesession) async def browser(): 会话级别的浏览器实例 async with async_playwright() as p: # 可配置化启动参数例如从环境变量读取 browser await p.chromium.launch( headlessTrue, # 无头模式适合CI环境 args[--disable-dev-shm-usage] # Docker环境常用参数 ) yield browser await browser.close() pytest.fixture async def context(browser: Browser): 函数级别的上下文每个测试函数一个干净的隔离环境 # 可以在这里加载通用的存储状态如基础用户登录态 # storage_state ./auth_state.json if os.path.exists(./auth_state.json) else None context await browser.new_context( viewport{width: 1920, height: 1080}, ignore_https_errorsTrue, # 忽略HTTPS证书错误用于测试环境 # storage_statestorage_state ) yield context await context.close() # 测试结束后自动清理保证隔离 pytest.fixture async def page(context: BrowserContext): 函数级别的页面最常用的fixture page await context.new_page() yield page await page.close() # test_example.py import pytest pytest.mark.asyncio async def test_with_fixtures(page): 使用fixture无需手动管理浏览器、上下文和页面的生命周期 await page.goto(https://example.com) title await page.title() assert Example in titleFixture的优势生命周期管理自动化Pytest自动处理Context和Page的创建与销毁避免资源泄漏。依赖注入清晰测试函数声明需要什么page,context框架就注入什么代码意图明确。灵活的作用域session作用域的browser在整个测试会话中只启动一次高效function作用域的context和page为每个测试提供干净环境可靠。易于配置可以在conftest.py中集中管理所有配置如视口、代理、设备模拟测试文件无需关心环境细节。5. 常见问题、性能优化与避坑指南在实际使用Context的过程中你会遇到一些典型问题和性能考量。这里记录了我踩过的一些坑和总结的优化技巧。5.1 常见问题排查速查表问题现象可能原因解决方案测试用例间状态污染多个测试共享了同一个默认Context或同一个Page对象。为每个独立的测试用例创建独立的Context使用browser.new_context()。在Pytest中使用function作用域的contextfixture。登录状态丢失或无效1.storage_state保存和加载的域名不一致。2. Token已过期。3. 保存的状态文件被损坏或格式错误。1. 检查保存和加载状态时访问的baseURL是否一致。2. 实现状态有效性检查过期则重新登录。3. 手动检查JSON文件格式或尝试重新生成。网络拦截route不生效1.page.route或context.route调用时机太晚请求已发出。2. URL模式匹配不正确。3. 在page.goto()之后才设置路由。1.在导航之前设置路由。对于context级别的路由在创建page之前设置。2. 使用Playwright的调试工具playwright codegen或PWDEBUG1检查网络请求的实际URL。3. 确保路由设置在page.goto()、page.click()等触发导航的操作之前。内存泄漏测试越跑越慢创建的Context和Page对象没有正确关闭。1. 始终使用async with语句或确保在finally块中调用await context.close()和await page.close()。2. 使用Pytest等框架的fixture来自动管理生命周期。并行测试时出现随机失败1. 测试本身非幂等依赖共享的外部状态如数据库序列。2. 硬件资源CPU/内存不足。3.Context配置冲突如端口占用。1. 保证每个测试用例数据独立使用随机或唯一的测试数据。2. 限制并行 worker 数量如pytest -n 2。3. 确保为每个Context配置了不同的、不冲突的选项如通过--proxy-server指定不同端口的代理时。5.2 性能优化实践复用Browser按需创建Context启动浏览器的开销是最大的。最佳实践是在测试会话开始时启动一个Browser实例所有测试共用它但每个测试创建自己独立的Context。这平衡了启动速度和测试隔离性。谨慎使用存储状态虽然storage_state能跳过登录但加载一个大的状态文件也有开销。对于非常短小的、不依赖登录状态的测试如检查首页元素直接使用全新的Context可能更快。阻止非必要资源使用context.route或page.route拦截并中止对图片、样式表、字体、分析脚本等资源的请求可以极大提升测试执行速度尤其是在复杂页面上。# 在创建页面或导航前在context上设置路由 await context.route(**/*.{png,jpg,jpeg,webp,gif,svg,ico,css,woff,woff2}, lambda route: route.abort()) # 或者更激进只允许HTML和必要的JS # await context.route(**/*, lambda route: route.abort() if route.request.resource_type not in [document, script] else route.continue_())注意此操作会改变页面渲染效果仅适用于不依赖这些资源视觉或功能的逻辑测试。对于视觉回归测试或需要完整渲染的测试请勿使用。使用无头Headless模式在CI/CD管道或不需要观察UI的测试中始终使用headlessTrue。无头模式消耗资源更少运行更快。合理配置视口与设备模拟如果没有特定需求使用一个标准的视口大小如{width: 1920, height: 1080}避免频繁切换。设备模拟如p.devices[iPhone 12]会带来额外开销只在需要时使用。5.3 一个关于Context关闭的深度坑我遇到过最隐蔽的一个Bug是测试大部分时间通过但偶尔会超时或失败。最终定位到是因为在一个复杂的测试函数中我创建了多个Page对象但在某些异常分支路径上没有确保每个Page都被关闭。# ❌ 有风险的代码 async def risky_test(context): page1 await context.new_page() page2 await context.new_page() try: await page1.goto(...) if some_condition: # 如果条件成立page2没有被close return await page2.goto(...) finally: await page1.close() # page2 可能没有被关闭导致资源泄漏最佳实践使用async with语句来管理Page的生命周期这是最安全的方式。# ✅ 安全的代码 async def safe_test(context): async with await context.new_page() as page1: await page1.goto(...) if some_condition: return # async with 会确保page1被自动关闭 # 如果需要另一个页面再开一个块 async with await context.new_page() as page2: await page2.goto(...)对于Context同样建议在测试函数或Fixture中使用async with或明确的close()调用。未关闭的Context会占用内存和端口积累多了可能导致浏览器崩溃或端口耗尽错误。理解Context不仅仅是学会一个API调用。它是你设计Playwright自动化测试架构时的核心思维模型。从简单的环境隔离到复杂的多角色场景模拟再到性能优化和资源管理Context都是你手中最得力的工具。下次写测试时不妨先问自己“这个测试需要什么样的上下文环境” 想清楚这个问题你的测试代码离“优雅”和“健壮”就更近了一步。
