Web自动化测试中登录状态判定的三层策略与实战实现

1. 项目概述与核心挑战

最近在带团队做自动化测试项目，发现一个挺有意思的现象：很多同学在掌握了Selenium、Playwright这些工具的基本操作后，一遇到需要处理登录状态的场景就有点懵。特别是面对一个完整的开源电商商城系统，比如我们常用的Shopware、Magento或者一些基于Spring Boot+Vue的商城项目，如何让自动化脚本“聪明地”识别当前是已登录、未登录还是登录已过期，成了从“会写脚本”到“写出健壮脚本”的关键一步。这不仅仅是技术问题，更是一种测试思维的体现——你的脚本得像个真人用户一样，能感知应用的状态。

这个系列的第32篇，我们就来啃这块硬骨头。登录状态区分，听起来简单，不就是检查页面上有没有“退出登录”按钮或者用户昵称吗？但实际做起来，你会发现坑不少。比如，有些商城首页用户未登录时也显示“你好，请登录”，登录后变成“你好，XXX”，但元素定位器可能完全一样；再比如，登录后的会话（Session）和令牌（Token）如何与自动化测试框架的生命周期绑定；还有，如何处理那些烦人的验证码（虽然实战中我们常绕过或Mock）。今天，我就结合一个具体的开源电商项目，把这里面的门道和实战代码给大家拆解明白。

2. 登录状态判定的核心思路与策略

2.1 状态判定的三个维度

在Web UI自动化中，判断用户登录状态，我们通常从三个层面去考虑，由表及里，逐步深入。

2.1.1 页面元素层（最直观）这是最直接的方法，通过查找页面上登录后特有的元素来判断。例如：

• 用户信息区域：登录后显示的用户名、昵称、头像。例如，定位//div[@class='user-info']/span元素，检查其文本内容是否包含预期用户名或非默认提示。
• 导航菜单变化：“登录/注册”链接变为“我的订单”、“账户设置”或“退出登录”。检查这些链接的存在性与文本。
• 权限相关入口：比如“卖家中心”、“发布商品”等只有登录用户才可见的入口。

这种方法的优点是简单、快速，直接模拟了用户的视觉判断。但缺点也很明显：UI易变。前端改个样式或文案，你的定位器可能就失效了。因此，它适合作为快速检查或辅助判断，不应作为唯一依据。

2.1.2 浏览器存储层（更可靠）现代Web应用普遍使用浏览器本地存储来维持会话状态，这是比UI更稳定的判断依据。

• Cookies：登录成功后，服务器通常会设置一个或多个包含会话标识的Cookie（如sessionid,token）。我们可以通过Selenium的driver.get_cookies()方法获取所有Cookie，然后检查是否存在特定的、表示已登录的Cookie键值对。
• LocalStorage / SessionStorage：很多前后端分离的应用（如Vue、React开发的商城）喜欢将认证令牌（如JWT）存储在localStorage或sessionStorage中。通过执行JavaScriptdriver.execute_script("return localStorage.getItem('access_token');")可以读取这些信息。

检查存储层的状态，不依赖于UI渲染，更加稳定。它是我们判断登录状态的核心手段。

2.1.3 网络请求层（最底层）这是最底层的判断，通过监听或分析浏览器发出的网络请求来判断状态。

• 请求头携带认证信息：登录后，后续的API请求会在请求头（如Authorization: Bearer <token>）中携带令牌。我们可以通过代理工具（如BrowserMob Proxy）或在支持网络拦截的测试工具（如Playwright）中监听请求来验证。
• 接口响应状态：尝试访问一个需要登录权限的API接口（如/api/user/profile），如果返回401（未授权）或403（禁止访问），则说明未登录或令牌失效；如果返回200并包含用户数据，则说明已登录。

这种方法最准确，因为它直接检验了应用的核心认证逻辑。但它实现起来相对复杂，通常用于更深层次的验证或特定场景。

2.2 策略选择：组合拳才是王道

在实际项目中，我推荐采用“存储层为主，元素层为辅，网络层兜底”的组合策略。

1. 主要依据：检查浏览器Cookies或LocalStorage中是否存在有效的认证令牌。这是稳定且快速的。
2. 辅助验证：快速检查页面上的一个或多个登录后特征元素，作为双重验证，增加判断的置信度。
3. 深度校验（可选）：对于关键业务流程（如下单支付），可以增加一个对核心API的静默调用，确保状态在业务层面也是通的。

这样构建的状态判断逻辑，既兼顾了稳定性，又具备了良好的可维护性和执行效率。

3. 实战环境搭建与目标系统分析

3.1 目标开源电商系统选择

为了实战，我们需要一个目标。这里我选择Saleor，一个基于Python（Django）和React开发的开源、高性能电商平台。选择它的原因有几个：一是技术栈现代，代表了当前很多电商系统的架构（前后端分离、GraphQL API）；二是它足够完整，拥有完整的用户认证、商品、订单流程；三是它易于本地部署，有详细的Docker部署文档。

当然，你也可以替换成你熟悉的任何开源电商系统，如Magento、Shopware、Odoo电商模块等，核心的测试思路是相通的。我们将基于Saleor的演示环境或本地部署版本来进行自动化测试脚本开发。

3.2 自动化测试环境配置

工欲善其事，必先利其器。我们的技术栈如下：

• 编程语言：Python 3.8+
• 自动化框架：Playwright。为什么选Playwright而不是Selenium？因为它对现代Web技术（如单页应用SPA）支持更好，自带网络拦截、自动等待等强大功能，且API简洁。当然，核心思路同样适用于Selenium。
• 依赖管理：pip和requirements.txt。
• 项目结构：采用Page Object Model (POM) 设计模式，这是保持测试代码可维护性的黄金标准。

首先，初始化项目并安装依赖：

# 创建项目目录 mkdir webui-auto-saleor && cd webui-auto-saleor # 创建虚拟环境（推荐） python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Mac/Linux: source venv/bin/activate # 安装核心依赖 pip install playwright pytest pytest-playwright # 安装Playwright浏览器内核 playwright install chromium

创建requirements.txt文件记录依赖：

playwright==1.40.0 pytest==7.4.0 pytest-playwright==0.4.0 # 可添加其他辅助库，如requests用于API检查 requests==2.31.0

3.3 分析Saleor的登录机制

在写代码之前，我们必须先手动操作一下，理解目标系统的登录行为。启动Saleor本地服务（假设运行在http://localhost:8000），打开浏览器开发者工具（F12）。

1. 手动登录：输入用户名密码登录。
2. 观察网络请求：在“网络”(Network)标签页，过滤XHR/Fetch请求，找到登录请求。通常是一个发送到/graphql/的POST请求， payload里包含mutation { tokenCreate(...) }。成功后的响应里会包含token（访问令牌）和refreshToken。
3. 观察应用存储：
   • 切换到“应用”(Application)标签页。
   • 查看Cookies：Saleor通常会将一个sessionid或类似的Cookie标记为HttpOnly（安全考虑，前端JS无法直接读取）。
   • 查看Local Storage：你会发现一个或多个键，比如saleor:auth_token，其值就是刚才获取到的JWT令牌。这是关键！Saleor前端（React）将登录令牌存储在这里，用于后续API请求的认证。
4. 观察UI变化：登录后，页面右上角的“登录”按钮会变成用户邮箱或“账户”下拉菜单。

通过这番侦察，我们得出结论：Saleor的登录状态核心标志是LocalStorage中是否存在有效的auth_token。UI上的用户信息是据此渲染的。这为我们设计状态判断函数提供了明确依据。

4. 核心代码实现：状态判断与会话管理

4.1 基础Page Object与工具类搭建

我们先建立项目的基础结构。创建pages/base_page.py，这是所有页面对象的基类，封装了Playwright的常用操作和我们的状态判断逻辑。

from playwright.sync_api import Page, expect import json import logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) class BasePage: """所有页面对象的基类，封装通用操作和状态判断""" def __init__(self, page: Page): self.page = page # 定义目标系统的关键存储键名（根据前期分析得来） self.AUTH_TOKEN_KEY = "saleor:auth_token" self.USER_EMAIL_KEY = "saleor:user_email" # 可能存储的其他信息 def get_local_storage_item(self, key: str) -> str: """获取LocalStorage中指定键的值""" try: value = self.page.evaluate(f"window.localStorage.getItem('{key}');") return value if value else None except Exception as e: logger.error(f"获取LocalStorage项 '{key}' 失败: {e}") return None def get_auth_token(self) -> str: """专门获取认证令牌""" return self.get_local_storage_item(self.AUTH_TOKEN_KEY) def is_logged_in_by_storage(self) -> bool: """ 通过检查LocalStorage判断是否登录（核心方法） 返回: True 如果存在有效的auth_token，否则 False """ token = self.get_auth_token() if not token: logger.info("LocalStorage中未找到认证令牌，判断为未登录状态。") return False # 简单校验token是否有内容（实际可增加JWT解码校验是否过期，但需注意密钥） # 这里我们假设有非空字符串即代表有效（前端会负责过期跳转） if len(token.strip()) > 10: # 粗略判断，JWT通常较长 logger.info(f"检测到认证令牌存在（前10位: {token[:10]}...），判断为已登录。") return True else: logger.warning("检测到认证令牌但内容异常，判断为未登录。") return False

接着，创建pages/login_page.py，封装登录页面的操作。

from pages.base_page import BasePage from playwright.sync_api import Page, expect class LoginPage(BasePage): """登录页面""" # 定位器 EMAIL_INPUT = "input[name='email']" PASSWORD_INPUT = "input[name='password']" LOGIN_BUTTON = "button[type='submit']:has-text('登录')" # 根据实际文本调整 ERROR_MESSAGE = ".alert-error" # 错误信息提示框 def __init__(self, page: Page): super().__init__(page) self.page = page def navigate(self): """导航到登录页""" # Saleor的登录页路径可能是 /account/login 或 /login self.page.goto("http://localhost:8000/account/login") expect(self.page).to_have_title(containing="登录") # 等待页面标题包含“登录” return self def fill_credentials(self, email: str, password: str): """填写登录凭证""" self.page.fill(self.EMAIL_INPUT, email) self.page.fill(self.PASSWORD_INPUT, password) return self def submit(self): """点击登录按钮""" # 点击前可以等待按钮可点击 self.page.click(self.LOGIN_BUTTON) # 登录后通常会跳转，这里等待导航发生或关键元素出现 # 我们选择等待LocalStorage被设置（更可靠） # 但Playwright没有直接等待Storage的API，我们可以等待页面导航完成或用户菜单出现 # 这里我们先简单处理，在实际测试中结合状态判断函数 return self def login(self, email: str, password: str): """完整的登录流程""" self.navigate() self.fill_credentials(email, password) self.submit() # 登录后，等待一个登录成功的标志，比如用户菜单出现 # 我们创建一个HomePage或AccountPage的实例来返回 from pages.home_page import HomePage # 避免循环导入，稍后创建 return HomePage(self.page)

4.2 实现多维度的状态判断函数

现在，我们在BasePage中完善我们的状态判断函数，实现之前提到的组合策略。

# 在 base_page.py 的 BasePage 类中添加以下方法 def is_logged_in_by_ui(self, timeout=5000) -> bool: """ 通过检查页面UI元素判断是否登录（辅助方法）。 查找登录后才会出现的元素，如用户菜单、退出按钮。 返回: True 如果找到至少一个特征元素，否则 False """ # 定义一组登录后的特征元素定位器（根据目标系统调整） logged_in_selectors = [ "button:has-text('我的账户')", "a[href*='/account/']:has-text('账户')", "div.user-menu", # 用户菜单容器 "button:has-text('退出')", ] for selector in logged_in_selectors: try: # 使用Playwright的locator和wait_for，带超时 element = self.page.locator(selector) element.wait_for(state="visible", timeout=timeout) logger.info(f"通过UI元素 '{selector}' 判断用户已登录。") return True except Exception as e: # 该元素未找到或不可见，继续尝试下一个 continue logger.info("未找到任何登录后的特征UI元素，判断为未登录（UI层）。") return False def is_logged_in_by_api(self, endpoint: str = "/graphql/") -> bool: """ 通过尝试调用一个需要认证的API来判断登录状态（兜底方法）。 注意：此方法会发送一个真实的网络请求，可能对测试系统产生副作用。 返回: True 如果API返回成功（2xx），否则 False """ # 首先获取令牌 token = self.get_auth_token() if not token: return False # 构建一个简单的GraphQL查询来获取当前用户信息（Saleor使用GraphQL） # 这是一个轻量级的查询，只请求邮箱，避免过大负载 query = { "query": """ query { me { email } } """ } # 从当前页面获取必要的请求头，如CSRF token（如果需要） # 这里简化处理，实际可能需要从cookie或meta标签获取 headers = { "Authorization": f"JWT {token}", # Saleor 可能用 Bearer 或 JWT "Content-Type": "application/json", } # 注意：在Playwright的页面上下文中直接发请求有点绕。 # 更常见的做法是使用独立的requests会话，但需要处理cookie同步。 # 这里我们演示一种在Playwright页面内执行fetch的方法： try: # 通过evaluate在浏览器上下文执行JavaScript的fetch response_json = self.page.evaluate("""async ([url, headers, body]) => { const response = await fetch(url, { method: 'POST', headers: headers, body: JSON.stringify(body), credentials: 'include' // 包含cookies }); return response.json(); }""", [f"http://localhost:8000{endpoint}", headers, query]) # 检查响应中是否有错误，或者是否包含用户数据 if response_json.get('data', {}).get('me'): logger.info("通过API验证，用户已登录。") return True else: logger.warning(f"API验证失败，响应: {response_json}") return False except Exception as e: logger.error(f"API验证请求异常: {e}") return False def is_logged_in(self, strategy: str = "composite") -> bool: """ 综合判断登录状态的主函数。 参数 strategy: 'storage' - 仅依赖存储 'ui' - 仅依赖UI 'api' - 仅依赖API 'composite' - 组合策略（默认）：存储层必须通过，UI层作为快速辅助验证。 返回: 布尔值，表示是否已登录。 """ if strategy == "storage": return self.is_logged_in_by_storage() elif strategy == "ui": return self.is_logged_in_by_ui() elif strategy == "api": return self.is_logged_in_by_api() else: # composite # 核心：存储层必须有有效令牌 storage_ok = self.is_logged_in_by_storage() if not storage_ok: return False # 辅助：UI层最好也能对上（增加置信度，但允许短暂UI延迟） # 给UI检查一个较短超时，因为可能页面还在加载 ui_ok = self.is_logged_in_by_ui(timeout=3000) if not ui_ok: logger.warning("存储层显示已登录，但未检测到UI特征。可能是页面未完全加载或UI已改版。") # 不立即返回False，可以再尝试一次API层兜底，或者记录警告后仍认为登录（取决于策略松紧） # 这里我们策略偏严格：如果UI对不上，用API最终裁决 return self.is_logged_in_by_api() return True

4.3 集成与测试用例编写

创建pages/home_page.py作为登录后的主页对象。

from pages.base_page import BasePage from playwright.sync_api import Page, expect class HomePage(BasePage): """网站主页（登录后/登录前都可能访问）""" USER_AVATAR = "img.avatar" # 用户头像 LOGOUT_LINK = "text=退出登录" def __init__(self, page: Page): super().__init__(page) def navigate(self): self.page.goto("http://localhost:8000") # 等待页面主要内容加载，例如一个商品列表或横幅 self.page.wait_for_selector("main:visible", timeout=10000) return self def logout(self): """退出登录""" # 假设有下拉菜单需要点击 self.page.click(self.USER_AVATAR) self.page.click(self.LOGOUT_LINK) # 等待跳转到登录页或首页 expect(self.page).to_have_url("**/login**") # 或首页 # 退出后，清除本地存储的令牌（可选，通常前端会自动清理） # self.page.evaluate(f"window.localStorage.removeItem('{self.AUTH_TOKEN_KEY}');") from pages.login_page import LoginPage return LoginPage(self.page)

现在，编写一个实际的测试用例tests/test_login_state.py，使用pytest。

import pytest from playwright.sync_api import Page from pages.login_page import LoginPage from pages.home_page import HomePage # 测试用的凭证（应从环境变量或配置文件中读取，切勿硬编码） TEST_EMAIL = "admin@example.com" # Saleor默认管理员邮箱 TEST_PASSWORD = "admin" class TestLoginState: """测试登录状态的识别""" @pytest.fixture(scope="function") def login_page(self, page: Page): """提供一个登录页面实例""" return LoginPage(page) @pytest.fixture(scope="function") def home_page(self, page: Page): """提供一个主页实例""" return HomePage(page) def test_initial_state_not_logged_in(self, home_page: HomePage): """ 测试1：初始状态下，用户应被判断为未登录。 访问首页，检查所有判断方法都应返回False。 """ home_page.navigate() # 分别用三种方法检查 assert not home_page.is_logged_in_by_storage(), "初始状态存储层不应有令牌" assert not home_page.is_logged_in_by_ui(timeout=2000), "初始状态UI不应显示登录特征" # API检查在无令牌时应快速返回False assert not home_page.is_logged_in_by_api(), "初始状态API验证应失败" # 综合策略也应返回False assert not home_page.is_logged_in(), "综合策略判断初始状态应为未登录" def test_state_after_successful_login(self, login_page: LoginPage, page: Page): """ 测试2：成功登录后，状态应被正确识别。 """ # 执行登录 home_page = login_page.login(TEST_EMAIL, TEST_PASSWORD) # 登录后，等待一小段时间让前端完成状态更新和跳转 page.wait_for_timeout(2000) # 显式等待，实际项目中应用更智能的等待 # 验证状态 # 首先，存储层必须有令牌 token = home_page.get_auth_token() assert token is not None and len(token) > 10, "登录后LocalStorage中应有有效令牌" # 使用综合策略判断 assert home_page.is_logged_in(strategy="composite"), "登录后综合策略应判断为已登录" # 也可以单独验证UI层 assert home_page.is_logged_in_by_ui(), "登录后UI层应能检测到登录特征" def test_state_after_logout(self, login_page: LoginPage, home_page: HomePage, page: Page): """ 测试3：退出登录后，状态应恢复为未登录。 """ # 先登录 home_page = login_page.login(TEST_EMAIL, TEST_PASSWORD) page.wait_for_timeout(1000) assert home_page.is_logged_in(), "登录后状态应为真" # 再退出 login_page_after_logout = home_page.logout() page.wait_for_timeout(1000) # 此时应该用退出后返回的LoginPage或重新获取的HomePage来判断状态 # 我们重新初始化HomePage，因为页面上下文已变 home_page_after = HomePage(page) home_page_after.navigate() # 刷新或导航到首页 assert not home_page_after.is_logged_in_by_storage(), "退出后存储层令牌应被清除" assert not home_page_after.is_logged_in(), "退出后综合策略应判断为未登录" def test_state_persistence_across_navigation(self, login_page: LoginPage, page: Page): """ 测试4：登录状态应在页面跳转后保持。 """ # 登录 home_page = login_page.login(TEST_EMAIL, TEST_PASSWORD) page.wait_for_timeout(1000) # 跳转到其他页面，如商品详情页（假设有一个商品ID为1） page.goto("http://localhost:8000/product/1") # 在新页面初始化BasePage（或专用页面对象）来检查状态 from pages.base_page import BasePage product_page = BasePage(page) # 状态应保持 assert product_page.is_logged_in(strategy="storage"), "跳转后存储层状态应保持" # UI检查可能因页面不同而失败，所以主要依赖存储层

5. 高级话题：状态管理、依赖注入与常见陷阱

5.1 测试用例间的状态隔离与依赖管理

自动化测试的一个核心原则是用例独立性。每个测试用例应该从一个已知的、干净的状态开始。对于登录状态，这意味着：

• setup和teardown：使用pytest的fixture来确保测试前后状态的清理。例如，一个autouse的fixture可以在每个测试后清除浏览器数据。

@pytest.fixture(scope="function", autouse=True) def clear_browser_context(page: Page): """每个测试函数执行后自动运行，清理状态""" yield # 测试结束后，清除所有cookies和localStorage，确保隔离 page.context.clear_cookies() page.evaluate("window.localStorage.clear();")

• 登录Fixture：对于需要已登录状态的测试，创建一个logged_in_pagefixture，它返回一个已登录的页面对象，避免在每个测试中重复登录代码。

@pytest.fixture(scope="function") def logged_in_home_page(login_page: LoginPage, page: Page) -> HomePage: """提供一个已登录的主页对象""" hp = login_page.login(TEST_EMAIL, TEST_PASSWORD) page.wait_for_timeout(1500) # 等待登录稳定 yield hp # 这个fixture不清除状态，因为clear_browser_context会做

5.2 处理登录状态失效与令牌刷新

在实际的电商系统中，登录令牌（尤其是JWT）都有过期时间。长时间运行的自动化测试脚本可能会遇到令牌过期的情况。我们的状态判断逻辑is_logged_in_by_api可以检测出这种情况（API返回401），但我们需要一个恢复机制。

策略：实现一个智能的“获取已登录页面”方法。这个方法会先检查当前状态是否有效，如果无效（未登录或令牌过期），则自动重新登录。

# 在某个工具类或基础fixture中 def get_authenticated_page(page: Page, force_login=False) -> HomePage: """ 智能获取一个已认证的页面对象。 参数 force_login: 强制重新登录，即使当前状态有效。 """ base_page = BasePage(page) home_page = HomePage(page) if not force_login and base_page.is_logged_in(strategy="composite"): logger.info("当前会话已登录，直接使用。") return home_page else: logger.info("会话未登录或已过期，执行自动登录。") login_page = LoginPage(page) # 这里可以读取配置的测试账号 from config import TEST_CREDENTIALS new_home_page = login_page.login(TEST_CREDENTIALS['email'], TEST_CREDENTIALS['password']) page.wait_for_timeout(2000) # 登录后再次验证 if not new_home_page.is_logged_in(): raise RuntimeError("自动登录失败，请检查凭证或网络。") return new_home_page

5.3 实战中遇到的典型问题与排查技巧

1. 问题：is_logged_in_by_ui在CI/CD环境中不稳定，有时失败。

   • 原因：CI环境（如GitHub Actions的Ubuntu runner）可能比本地机器慢，UI渲染延迟更高。固定的timeout可能不够。
   • 解决：增加超时时间，或使用Playwright更智能的等待。例如，用page.wait_for_selector(selector, state='visible', timeout=10000)替代简单的查找。或者，降低对UI检查的依赖权重，在我们的组合策略中，如果存储层通过，即使UI检查因超时失败，我们还可以 fallback 到API检查，而不是直接判负。

2. 问题：LocalStorage中的令牌存在，但is_logged_in_by_api返回失败。

   • 原因：
     • 令牌可能已过期。
     • API的认证方式可能不是简单的Bearer {token}，可能需要额外的请求头。
     • 目标接口地址或GraphQL查询结构可能不对。
   • 排查：
     • 手动在浏览器控制台执行localStorage.getItem('saleor:auth_token')获取令牌。
     • 使用curl或Postman，用该令牌调用/graphql/接口，验证是否成功。这能快速定位是令牌问题还是我们的请求构造问题。
     • 在Playwright脚本中，在调用API前打印出构造的请求头和URL，与实际浏览器开发者工具中看到的成功请求进行对比。

3. 问题：退出登录后，is_logged_in_by_storage偶尔还返回True。

   • 原因：前端退出操作可能是异步的，清除LocalStorage有延迟，或者脚本执行太快。
   • 解决：在退出操作后，增加一个明确的等待，等待令牌被清除。

     def logout_and_wait(self, timeout=3000): self.page.click(self.LOGOUT_LINK) # 明确等待令牌被移除 self.page.wait_for_function("""() => { return window.localStorage.getItem('saleor:auth_token') === null; }""", timeout=timeout)

   • 更稳健的做法：状态判断函数本身应该有一定的容错和重试机制。例如，is_logged_in_by_storage可以在发现令牌后，等待一小段时间（如500ms）再检查一次，确认其稳定存在。

4. 问题：跨子域名的状态共享。

   • 场景：如果你的商城主站在www.example.com，而用户中心在account.example.com，那么LocalStorage是不共享的。Cookie可以通过设置domain=.example.com来共享。
   • 对策：在这种情况下，Cookie成为更可靠的状态判断依据。你需要调整is_logged_in_by_storage方法，优先检查特定的跨域Cookie。使用page.context.cookies()来获取所有Cookie进行分析。

6. 总结与最佳实践建议

区分登录状态远不止一个if-else判断。它是一套基于对应用架构深刻理解的验证体系。回顾一下关键点：

1. 多层验证，主次分明：以浏览器存储（Cookie/LocalStorage）为核心依据，这是最稳定的。UI检查作为快速、直观的辅助，网络API验证作为最终兜底。不要只依赖UI。
2. 为你的目标系统“画像”：在编写任何代码前，花时间手动操作，用开发者工具搞清楚你的系统如何管理会话。是JWT放在LocalStorage？还是Session Cookie？关键键名是什么？这决定了你代码的靶心。
3. 状态判断要“容错”：网络有延迟，前端渲染需要时间。你的判断逻辑里应该包含合理的等待、重试机制，避免因瞬时状态误判。Playwright的wait_for_*系列方法是你的好朋友。
4. 测试用例要“独立”：使用pytest fixture妥善管理测试生命周期，确保每个测试用例都从一个干净、已知的浏览器状态开始。autouse的清理fixture能省去很多麻烦。
5. 日志是你的眼睛：在状态判断的关键节点（如获取到令牌、UI元素找到/未找到、API调用成功/失败）记录清晰的日志。当测试在CI上失败时，这些日志是定位问题的第一手资料。

最后，把状态判断逻辑封装成基类的方法，让你的所有Page Object都能方便地调用。这样，在测试“加入购物车”、“提交订单”这些需要登录状态的功能时，你可以先优雅地调用page.is_logged_in()来确保状态正确，如果未登录，则触发自动登录流程，让整个测试套件更加健壮和智能。

这套方法不仅适用于Saleor或电商系统，任何需要登录态的Web应用自动化测试，其核心思想都是相通的。理解原理，适配细节，你就能写出应对各种复杂场景的、真正可靠的自动化测试脚本。