现在是凌晨两点。持续集成流水线刚刚又失败了——原因仍然是端到端测试超时。你打开 allure 报告，发现 50 个测试用例中有 47 个在登录页面卡住了超过 8 秒。你的团队正在使用 playwright 编写自动化测试，但每个测试都从头到尾完整执行登录流程：输入用户名、输入密码、点击按钮、等待重定向。你心想：“这难道不是在白白浪费时间和金钱吗？”更荒谬的是，竟然没有人想到保存并复用登录状态。
这正是我们今天要讨论的内容：结合使用 playwright 的 storageState 与 pytest 的夹具机制，将重复的登录操作压缩为一次，同时将断言逻辑提取到可复用的“记忆模块”中，从而使你的测试代码更简洁、更稳定。
问题剖析
这种场景太过常见：你有一个管理系统（如运营面板或软件即服务控制台），需要登录才能访问。你编写了 50 个 P0 级功能测试。最简单的做法是在每个用例中都放入 page.goto('/login')，填写表单，登录，然后测试实际的业务逻辑。结果如下：
- 执行时间激增：平均每次登录耗时 2.3 秒（包括页面加载、输入、点击、等待仪表盘加载）。50 个测试用例仅登录就消耗了 115 秒，再加上持续集成资源排队，一次运行轻松超过 8 分钟。
-
维护噩梦：一旦登录页面的选择器发生变化，每一个用例都必须更新。例如，如果按钮从
#login-btn变为[data-testid="submit"]，你就需要进行全局搜索和替换。漏掉一个，就会导致大批测试失败。 -
断言重复：几乎每个用例都包含类似的
expect(page.locator('.toast')).to_have_text('Success')检查。相同的验证逻辑分散在各处。添加新用例意味着复制粘贴断言，因此提示文本的细微变化就可能破坏十几个测试。
根本原因很明确：测试没有将“状态”与“行为”分离。 登录是一种前置状态，而非业务行为——它应当被共享。断言是针对页面状态的检查，应封装为领域语言，而不是充斥着选择器和原始字符串。
那常见的变通方法呢？有些人使用 setUp 在每个测试前登录，并使用 tearDown 注销——但这仍然每次都执行登录操作，只是去除了代码重复，治标不治本。另一些人手动将 cookie 粘贴到代码中，但令牌一旦过期，一切都会崩溃。我们需要一种自动化、可刷新、跨用例可复用的登录状态解决方案，同时还要让断言像库函数一样易于调用。
方案设计
技术选型直截了当：playwright 原生提供 context.storage_state()，它将当前浏览器上下文的 cookie、本地存储和索引数据库序列化为一个 json 文件。下次使用 browser.new_context(storage_state=path) 加载时，它会直接恢复登录状态，完全绕过登录页面。
在架构上，我们使用 pytest 夹具作用域 来实现不同级别的共享：
-
session作用域夹具：负责生成storage_state.json。如果文件已存在且未过期，则直接复用；否则执行一次登录并保存状态。 -
function作用域夹具：每个测试免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
