在我自己写的 Pytest-Bdd-Playwright 系列教程里前面光是“如何用自然语言描述业务规则”“怎么把 Given/When/Then 映射成自动化代码”这些基础话题就已经骗了不少收藏。今天这篇是第 15 篇专门聊 Background背景——这个在 BDD 里容易被忽略但用好了能把测试用例维护量直接砍掉三分之一的家伙。简单说当你发现每个 Scenario 开头都是一模一样的“打开浏览器、登录系统、进入某个页面”时你就该用 Background 了。它类似测试领域里的“公共前置步骤”只要你把这些重复动作从每个 Scenario 里挪到 Feature 层级的 Background 块里所有场景都会自动先执行这一段。配合 Playwright 的浏览器自动化能力Background 能帮你把环境准备、用户登录、数据初始化这类动作收敛到一处改一次全用例生效。这篇教程适合两类人一类是刚开始用 pytest-bdd 写 Playwright 用例的测试开发另一类是已经写了不少用例、正在被海量重复 Given 步骤折磨得想重构的老手。我会先讲清楚 Background 的定位和语法再给出一套完整的 Playwright 示例最后把我在实际项目里踩过的坑和排查思路全都倒出来。1. Background 的角色定位它到底是什么能不能乱用1.1 先看一个典型的痛点场景假设你要给一个电商后台写 20 条测试用例。每一条用例都在说“当管理员登录后点击订单管理看到订单列表然后……”。如果你老老实实把“打开浏览器”“登录管理员账号”“点击订单管理”这三个步骤复制到每一个 Scenario 里feature 文件会长得又臭又长。实际维护的时候更痛苦某天登录流程从“输入账号密码”改成了“扫码登录”你得去这 20 条用例里逐个修改那几段 Given 步骤漏改一条就等着测试失败后熬夜排查。这正是 Background 要解决的。在 BDD 的 Gherkin 语法里Background 块写在 Feature 关键字之后、第一个 Scenario 之前它里面的每一步都会被强制执行到该 Feature 下的所有 Scenario 前面。换句话说Background 是“这个功能模块所有场景都共享的一套前置剧情”。1.2 和 Given/When/Then 的关系很多人会问Background 里的步骤是不是就等于 Given其实不完全一样。Given 通常表达“在某种给定状态下”它属于某个场景的具体前置比如“给定用户已登录”“给定库存数量为 10”。而 Background 表达的是一组对所有场景都生效的公共状态它更像测试代码里的 setUp() 方法。从执行时机看pytest-bdd 会先把 Background 里的步骤全部执行完再接着执行每个 Scenario 自己的 Given、When、Then。这个顺序在 Gherkin 设计里是强制的Background 必须写在所有 Scenario 之前每个 Feature 最多只能有一个 Background。1.3 什么情况下不适合用 Background虽然 Background 很好用但它也不是万能药。我个人的判断标准是只有“真的要被执行多次且完全一致”的公共前置才放进去。如果某个场景需要登录另一个场景不需要登录那就不该把“登录”放进 Background否则你只能痛苦地在每个场景里写“跳过登录”这种丑陋的补偿步骤这会把测试用例的意图搅浑。再比如有些前置步骤只在少数几个场景里用到硬塞进 Background 反而会让其他无关场景白跑一遍不必要的操作拖慢整体执行时间。说到底Background 是一种“收敛重复”的工具不是“收纳所有 public 代码”的垃圾桶。2. Background 的定义语法与组织方式Feature 文件的正确写法2.1 Gherkin 语法速览一个标准的 feature 文件局部会是这样Feature: 订单管理 Background: Given 管理员已经登录系统 And 打开订单管理页面 Scenario: 查看订单列表 When 点击“全部订单”筛选条件 Then 页面展示所有订单记录 Scenario: 搜索指定订单 Given 订单号是“SO2023001” When 在搜索框中输入该订单号并点击查询 Then 页面展示匹配的订单记录注意Background 里的步骤关键字可以用“Given”开头也可以直接用“Given”和“And”混合。不过 pytest-bdd 的解析器对步骤文本的匹配规则很宽容只要你注册的步骤函数能对得上具体文本就行关键字本身不参与匹配。2.2 与 Hook 的对比我为什么更愿意用 Background很多 Playwright 项目里会直接用 pytest 的 fixture 来穿件浏览器实例和页面对象甚至有些团队会在 conftest.py 里写一堆自动化登录的 fixture。那 Background 和 fixture 有什么区别这里有个设计哲学上的差异fixture 是代码层面的复用玩的是 Python 的作用域和依赖注入而 Background 是业务层面、用自然语言写出来的前置条件它在 feature 文件里一目了然。我的团队现在倾向这样的分工用 fixture 管浏览器生命周期比如启动 Chromium、创建上下文、释放资源这些对测试用例来说太“技术化”不适合写进 Gherkin 里用 Background 管业务状态比如登录、导航、初始化数据这些是产品经理、业务分析师也能读懂的步骤。你想想如果产品经理打开一个 feature 文件看到满屏 pychrome 和 context fixture他根本不知所云但他看到“管理员已经登录系统”立刻能明白这是一个前置条件。2.3 多场景下的组织顺序当你在一个 feature 文件里规划多个场景时我推荐先把所有场景都列出来再看它们的共同前缀是什么。比如订单管理这个 Feature20 个场景里可能 18 个都需要“管理员登录 进入订单管理”但你发现有两个场景是“游客访问订单管理页面应跳转到登录页”这就说明“管理员登录”不能放 Background你就得手动把公共登录步骤写进那 18 个场景。如果你发现绝大多数场景都要执行一组公共步骤但少数场景不需要你可以考虑把它们拆成两个 Feature 文件——一个带 Background一个不带。这比在 Background 里加条件判断要干净得多。从实际维护经验来看宁可多建一个 feature 文件也不要做复杂分支。2.4 变量传递与作用域pytest-bdd 在 Background 里定义的变量是在上下文作用域内保留的吗答案是Background 步骤函数和 Scenario 步骤函数会共享同一个场景上下文对象通过 fixtures 注入。你可以在 Background 的步骤实现里给某个 fixture 赋值然后在后续场景步骤里读取。但注意每个 Scenario 执行完后这个上下文就会被清理Background 不会跨 Scenario 累积状态。这很合理保证每个场景是独立可重复的。所以如果你需要把某些数据比如订单 ID在 Background 里生成然后在每个 Scenario 里引用可以直接把这个值存到步骤对象的变量里pytest-bdd 的场景上下文会帮你保留。3. 在 Playwright 中实现 Background 的实操从零搭建一套完整示例3.1 环境准备与项目结构我用一个模拟项目 X 来演示这个名字是我虚构的你们直接照着做就行。项目结构建议这样project_x/ features/ order_management.feature step_defs/ test_order_management.py conftest.py pytest.inirequirements.txt 里至少需要这些包pytest、pytest-bdd、playwright。装完以后记得执行一次 playwright install chromium否则运行会直接报错。3.2 conftest.py 里管理与浏览器生命周期先说浏览器怎么创建。我会在 conftest.py 里定义一个全局 fixture用 yield 的方式保证最终能释放资源这样不管用例成功还是失败都不会残留浏览器进程。import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopefunction) def browser_page(): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context() page context.new_page() yield page context.close() browser.close()这个 browser_page fixture 会作为步骤函数的一个参数传入。为什么我是 function 级别的因为每个场景基本都需要一个干净的浏览器环境省得场景之间互相污染。3.3 step_defs 里的步骤实现在 test_order_management.py 里你会写这样的代码来把 Gherkin 步骤翻译成 Python 代码。我特意用 pytest-bdd 的 given、when、then 装饰器来注册步骤from pytest_bdd import scenarios, given, when, then, parsers scenarios(../features/order_management.feature) given(管理员已经登录系统) def admin_logged_in(browser_page): browser_page.goto(https://example-admin.com/login) browser_page.fill(#username, admin) browser_page.fill(#password, secret) browser_page.click(#login-btn) # 断言登录成功否则后续步骤会走错路 assert Dashboard in browser_page.title() given(parsers.parse(打开订单管理页面)) def open_order_page(browser_page): browser_page.goto(https://example-admin.com/orders)这里要注意 Playwright 的同步 API 和异步 API 差异我习惯用同步 API 配合 pytest因为 pytest-bdd 对同步函数支持得最顺手。如果你一定要用异步 API就得额外引入 pytest-asyncio运行时会多很多心智负担非必要不上。3.4 完整示例带 Background 的 feature 如何运行我现在把整个 feature 文件补完整加入三个场景其中一个故意用 Background 里生成的订单号数据来验证跨步骤变量传递Feature: 订单管理 Background: Given 管理员已经登录系统 And 打开订单管理页面 Scenario: 查看订单列表 When 点击“全部订单”筛选条件 Then 页面展示所有订单记录 Scenario: 搜索指定订单 Given 订单号是“SO2023001” When 在搜索框中输入该订单号并点击查询 Then 页面展示匹配的订单记录 Scenario: 重置搜索条件 Given 订单号是“SO2023002” When 点击“重置”按钮 Then 搜索框内容被清空 And 订单列表恢复为全部订单运行命令就是pytest features/order_management.feature。pytest-bdd 会自动匹配到 step_defs 里的步骤函数。当你运行这个测试时你会发现两个 Scenario 在各自执行第一条 Given 之前都先执行了“管理员已经登录系统”和“打开订单管理页面”这两步一共执行了两次。这正是 Background 的预期行为。它能确保每个场景都在同样的初始业务状态下开始。3.5 步骤里如何从 Background 传递数据到场景我在 Background 里生成的数据怎么在后面的 Given 里用有人会直接定义一个 fixture用它来存数据。举例pytest.fixture def order_data(): return {} given(管理员已经登录系统) def admin_logged_in(browser_page, order_data): browser_page.goto(...) # 模拟生成一个随机订单号并存入 order_data order_data[order_no] SO str(time.time()) then(parsers.parse(搜索框内容被清空)) def check_clear(browser_page, order_data): assert browser_page.input_value(#search-box) # 这里依然能拿到 Background 里存的 order_no因为同一场景共用同一批 fixture 实例 print(order_data[order_no])因为 fixture 的默认作用域是 function同一个测试流程内所有步骤函数拿到的 order_data 是同一个对象所以 Background 里的修改在后续步骤里是可见的。如果你在 Background 里只是创建数据而不是读取这个模式特别顺手。3.6 用表格数据批量跑场景时的 Background 表现feature 文件还可以用 Scenario Outline 配合 Background 一起用例如Scenario Outline: 订单状态筛选 Given 订单号是“order_no” When 筛选状态为“status” Then 页面展示状态为“status”的记录 Examples: | order_no | status | | SO20230001 | 已支付 | | SO20230002 | 已发货 |这种情况下Background 依然会在每一行示例执行前都跑一遍保证每个独立的用例都共享同一套前置环境。我见过有的新手会误以为 Background 会跨表格缓存其实不会它只管每个独立测试流程。3.7 实测中关于等待和超时的经验Playwright 的核心特点是所有操作都自带自动等待它会不断重试直到元素可操作。但在 Background 里登录时如果页面跳转比较慢或者有登录接口的延迟自动等待也可能失效——尤其是当你直接用page.goto后立刻做fill时如果登录页本身有 loading 效果可能前几毫秒定位不到输入框。我在实际项目里会给 login 流程显式加一个page.wait_for_selector(#username, statevisible)别嫌多余这能排除掉 90% 的偶发失败。还有一次我踩到坑开发环境的登录接口经常返回 504但 Playwright 的 goto 会等页面加载完不会报错此时页面停留在服务器错误页assert Dashboard in page.title()直接失败。虽然失败了我很高兴因为用例确实测出了问题但如果是为了验证后续业务流程我建议在步骤里加上重试逻辑或者用一个更稳定的测试环境。4. 常见问题与排查技巧实录Background 真正会踩的坑4.1 语法位置写错导致解析失败这是新手最容易犯的错。pytest-bdd 解析 Gherkin 时要求 Background 必须放在 Feature 关键字后面、第一个 Scenario 前面。如果你误把 Background 放在了某个 Scenario 之后解析器会直接报错告诉你“Background 只能出现在 Feature 的开头”。排查方法很简单看看报错信息里的行列号重点检查 feature 文件里是否把 Background 写在两个 Scenario 之间了。4.2 步骤重复定义冲突我经常会在项目里看到不同步骤文件重复定义了同一个步骤文本比如一个在 conftest 里给全局用的“Given 管理员已经登录系统”另一个在业务 step_defs 里也定义了同样文本。pytest-bdd 碰到这种冲突会抛异常很难排查因为可能会有两个项目分支无意间引入相同步骤。解决方式只在一个地方定义公共步骤。我的个人习惯是在项目根目录建一个共享的 step_defs 文件保证这些公共步骤只在全局出现一次。4.3 变量作用域带来的状态污染有经验的开发会知道fixture 的 function 作用域意味着每个测试过程独立但这有一个例外如果你用了 module/session 级别的 fixture它有可能跨场景共享。Background 里如果你不小心改了这种大作用域 fixture 的数据那它会污染到后续所有场景轻则断言失败重则隐藏逻辑死循环。举个例子我踩过一次坑在 Background 里把全局用户 token 保存到一个 session 级 fixture 中但第二个场景里没有清理 token导致第三个场景登录时拿到了旧的 token所有请求都带着一个过期凭证整个测试套间像多米诺骨牌一样倒下。排查方式很恶心因为报错指向的是具体请求而不是 login。所以我现在有一条铁律任何跨场景共享的数据必须只读如果想模拟不同的登录态直接在 Background 里重新执行登录不要偷懒复用旧 token。4.4 执行顺序与并发问题pytest-bdd 默认按顺序执行 feature 文件里的场景但如果你用了 pytest-xdist 并行跑用例就需要特别注意 Background 里的操作是否会跟其他用例打架。比如浏览器共享端口、后台数据状态冲突等。实际当中并行跑 Playwright 测试最好一个 worker 配一个浏览器实例并且 Background 里不要依赖外部全局状态。我见过有些团队用 xdist 跑 UI 自动化结果发现 Background 里的登录操作被并发执行了十遍把认证服务打成热点大量 429 报错。要做到稳定并行就得在 fixture 里给每个 worker 独立资源并且在 Background 步骤里避免对公共接口做频率过高的调用。4.5 调试技巧如何快速定位 Background 里失败的步骤pytest-bdd 里有个非常方便的--tbshort参数它能直接显示每一步的调用堆栈。但想真正定位 Background 里的失败还得靠 pytest-bdd 自带的运行日志。如果你运行pytest -spytest-bdd 会打印出每一步的文本和执行时间很清楚地看到执行到 Background 的哪一步出了问题。此外我强烈建议在写 Background 步骤时只做和高集成相关的操作不要把一大堆验证逻辑塞进去。它本质是“环境准备”不是“业务断言”。如果 Background 里的验证太多一旦前置环境出错你会看到十几个场景同时失败根本分不清是功能问题还是环境问题。我的原则是 Background 步骤只做动作、不做过重的检查最多加一个轻量断言表示“前置动作成功了”。4.6 后台登录会话的管理用 Playwright 写 Background 频繁登录时如果后台系统对频繁登录有限制比如验证码指纹检测那这种重复登录会让你很头疼。一个比较可靠的方案是复用同一个浏览器 context 的 storage_state。你可以先在测试环境手动登录一次用context.storage_state(pathauth.json)保存登录态然后在每个测试的 fixture 里通过browser.new_context(storage_stateauth.json)加载登录态从而跳过 UI 登录这一整段 Background。这样你甚至可以把“管理员已经登录系统”改成一步通过 storage_state 完成背景步骤只剩一个页面导航。考虑到执行速度和稳定性我在正式项目里越来越倾向于这种方式。不过提醒一下如果你们团队的测试环境会定期清理 session或者登录态有几分钟的过期时效那这种方式反而坑人因为你会因为 auth.json 过期而不断报错。折中方案是把 auth.json 的刷新做成一个独立作业在跑测试前先更新一次。4.7 Feature 文件里的中英文混用很多人喜欢把 Given/When/Then 关键字保持英文然后步骤描述全部用中文。Gherkin 本身支持本地化关键字pytest-bdd 也支持中文关键字比如 假如/当/那么。但在团队协作时我建议统一用一种语言写关键字不要一会儿 Given 一会儿 假如。混在一起会导致部分编辑器插件高亮失灵而且容易让不熟悉这套流程的人困惑。我在示例里用的是英文关键字和中文步骤描述这个组合在多数团队里都算常见。如果你跑不起来先检查 pytest-bdd 版本老版本对新版 Gherkin 关键字的支持可能有差异。4.8 一个我常用来规避 Background 滥用的小技巧如果你发现 Background 里的步骤开始出现条件分支比如“如果用户类型是管理员则执行 A否则执行 B”这就意味着你对 Feature 的拆分粒度出了问题。在 BDD 里不同的前置条件应该对应不同的 Feature 或不同的 Scenario 描述不该用编程式的分支逻辑来掩盖复杂性。我在评审代码时看到这种分支会立刻建议把该 Feature 拆成多个小 Feature每个 Feature 专门描述一类前置条件。这样 Background 就永远是直线结构没有 if/else。5. 在大型测试套件中维护 Background 的经验总结5.1 从项目初期就要规划 Background 的边界我见过太多项目测试代码写了大半年才开始愁重复步骤的问题然后猛然想起 Background 这个功能一顿重构。其实后悔是没用的重构的代价远比一开始就规划好大得多。如果你现在刚开始搭建一套新的 pytest-bdd 测试框架我建议第一步就是把登录、导航这类全局性动作在 Feature 文件里定义成 Background并尽快落地成公共步骤。后面每增加一个新场景先问自己这个场景和同事场景共有哪些前置如果有是不是应该归入 Background5.2 Background 里的步骤也要保持高效每次执行一套完整的 pytest 回归Background 步骤会随着场景数量线性增加执行开销。如果你的套件里有 500 个场景哪怕 Background 只有三步每步要花两秒光是 Background 就要跑 3000 秒非常恐怖。所以 Background 里的步骤一定不能重。能靠 storage_state 绕过的登录就不要做真实 UI 输入能直接从数据库插入的数据就不要走界面创建。把 Background 执行时间压缩到最快能让整个套件跑得更轻。有时候我在公司里会做一个简单的统计用 pytest 的--durations10参数看最耗时的测试步骤如果 Top 10 里全是 Background 相关的步骤那说明 Background 里塞了太多硬核操作需要优化。5.3 与数据清理和测试隔离的关系Background 执行之前最好先保证数据库里是干净状态。否则你登录后进入订单管理页面发现以前测试留下的脏数据还挂在列表里后续 assertEquals 就不可能稳定。我通常在 conftest 里加一个自动清理 fixture在每轮测试开始前把测试表里的数据清空。这样 Background 里的导航操作才会基于一个可预期的初始状态。不过要注意清理操作如果走的是后台接口而接口本身也依赖登录那就要谨慎设计清理顺序避免形成循环依赖。5.4 文档与协作视角让业务同事读得懂Background 真正的价值在协作层面而不是代码层面。传统自动化测试里新同事跑完一条用例他完全看不出哪些操作是业务前置、哪些是断言步骤。但通过 Background你只要打开 feature 文件就能看到一条清晰的剧情线系统前置状态 - 场景操作 - 场景断言。我强烈建议在每个 Feature 文件的顶部用注释写清楚该模块的 Background 用来保证什么状态比如“确保当前登录用户为管理员且已进入订单管理页所有场景都从这个入口开始”。花两分钟写这个注释能让以后接手的人少踩一堆坑。5.5 版本演进当我需要改变公共前置时需求是不断变化的。有一天你们的产品从“必须先登录才能看订单”改成了“游客也能查看部分订单页面”那么整个 Feature 的 Background 逻辑都得动。如果你把登录放进了 Background那就意味着所有场景都会先登录这与“游客可见”的需求直接冲突。这时候就要评估是把这个 Feature 拆成两个游客可见和登录后可见还是移除 Background 里的登录步骤然后逐场景手动补上。我的建议是优先拆 Feature。为什么因为不同的前置状态代表不同的用户故事你这个 Feature 里的场景如果一半需要登录、一半不需要那本质上它们就不是同一个功能模块的二级标题gherkin 文件也会越来越难维护。拆分后每个 Feature 的 Background 都保持稳定后续需求再变你只需改动对应 Feature 的 Background其他场景不受牵连。6. 进阶结合数据驱动与外部工具让 Background 更顺手6.1 从数据库批量初始化数据到 Background你可能会遇到一个场景订单管理页面要先有大量订单才能测试分页和筛选。如果靠 UI 一个个创建订单Background 会慢到让人怀疑人生。这时我在 conftest.py 里会做一个自动化测试用户可以通过调用内部 API 或者直连数据库在 Background 里快速造数。given(系统存在多个订单) def seed_orders(db_client): for i in range(50): db_client.insert_order(...)这个做法能大幅提升执行效率但要注意你是在和数据库耦合一旦表结构变更这个 Background 步骤就得同步改。所以在团队内部要约定好这种造数步骤必须放在专门的基础数据模块里不要让每个业务 feature 都去碰数据库。如果 DB 结构与技术栈经常变那就退化成调用 API 或者走 UI看你们对隔离和速度的取舍。6.2 在 Background 里切换多角色登录如果你们的系统分管理员、运营、客服三种角色且所有场景都需要某个角色登录那就可以在 feature 文件里把角色当作 Background 的一部分描述Background: Given 以管理员身份登录系统然后在 step_defs 里写一个带参数的步骤given(parsers.parse(以{role}身份登录系统)) def login_as_role(browser_page, role): account get_account_by_role(role) browser_page.goto(...) ...这样你只需写一个步骤实现却可以覆盖所有角色的公共前置。如果你还有额外要求比如某些角色需要跳过特定配置那就在该 feature 里额外增加一个 Background 步骤来补充差异不要改共享的公共步骤函数。6.3 通过环境变量控制 Background 行为在我工作过的项目里测试环境分为本地开发、集成测试、预发。有时登录方式不同比如本地环境不需要验证码预发环境需要验证码。我会在 Background 步骤里根据环境变量切换登录行为import os given(管理员已经登录系统) def admin_logged_in(browser_page): if os.getenv(TEST_ENV) preprod: # 走预发专属登录流程 pass else: # 走常规登录 pass虽然这种分支让我在上面刚说了“不要用分支掩盖复杂度”但环境差异确实存在而且和业务领域无关放到 Background 步骤里反而合理。你可以把这种环境适配逻辑封装成 helper不要在步骤函数里堆 if/else。6.4 结合 Allure 报告查看 Background 的执行情况如果你用 allure 生成测试报告你会发现 Background 里的步骤会全部附在每条测试用例的执行步骤里。这是个很好的特性因为它能直观告诉业务人员“每条用例的执行路径是什么样的”。但报告也会因为 Background 太长而显得冗余。我在实际使用中会开启 allure 的步骤折叠功能把 Background 步骤折叠起来需要时再展开这样报告既完整又清晰。6.5 用 pytest 的 fixture 参数化来驱动不同 Background 数据有些系统有多种业务线每种业务线的订单编号前缀不同、页面展示字段不同。你可以在 step_defs 里写一个带有参数的 Background 步骤然后通过 fixture 来传入业务线标识。这个思路我建议只在非常明确的多租户场景下使用否则会把 feature 文件的阅读难度拉高。因为一个 Background 如果带参数别人看 feature 文件时不一定能马上明白当前组合是什么。我更倾向于为不同业务线分别写 Feature 文件每个文件的 Background 写死业务线对应的常量这样反而更直观避免绕来绕去。6.6 聚焦执行只跑某个 Scenario 时 Background 依然生效pytest-bdd 允许你使用-k参数来过滤测试节点比如pytest -k search_order。只有被选中匹配的 Scenario 会执行但 Background 还是会为这个 Scenario 先走一遍。这个特性的实际价值是当你只需要验证一个复杂场景而不想跑整个回归你依旧能保证每一项独立验证都是“从公共前置状态开始”不会因为你只跑了一条用例而破坏这个约束。7. 我实践一年后对 Background 的真实体会从我开始把 pytest-bdd 和 Playwright 组合用于实战到现在也积累了不下两百个 feature 文件。Background 在这套体系里给我的最大帮助不是“少写几行 Given 步骤”而是它逼着我在设计用例前先去思考这个模块真正不变的那条基线在哪里以前写 setUp() 时我总是凭直觉把登录放进去但从来没有像用 Background 那样从业务叙事的角度去审视。用 Background 之后每次新建一个 feature 文件我都要先问产品和开发这几个场景共有的前置条件是什么有没有例外这看起来是个技术讨论实际上把业务的边界厘清了不少还经常能发现以前测试用例设计的盲区。在维护阶段Background 还能让你快速回答一个关键问题“这个功能模块在被测试时系统处于怎样的初始状态” 新同事看代码先从上往下扫 Background比追着 fixture 上下文到处跑要轻松得多。最后分享一个小技巧如果你已经在用 Background 管理登录和页面导航可以考虑给这一步的半结构化数据做一份清单。比如在项目文档里列明“所有 Feature 的 Background 今后统一使用步骤 X 登录不要新建私有步骤。” 这句话能防止团队里大量出现“私有登录”副本进一步压缩重复成本。测试代码本质上也是代码保持 DRY 原则能救你于水火。
在我自己写的 Pytest-Bdd-Playwright 系列教程里前面光是“如何用自然语言描述业务规则”“怎么把 Given/When/Then 映射成自动化代码”这些基础话题就已经骗了不少收藏。今天这篇是第 15 篇专门聊 Background背景——这个在 BDD 里容易被忽略但用好了能把测试用例维护量直接砍掉三分之一的家伙。简单说当你发现每个 Scenario 开头都是一模一样的“打开浏览器、登录系统、进入某个页面”时你就该用 Background 了。它类似测试领域里的“公共前置步骤”只要你把这些重复动作从每个 Scenario 里挪到 Feature 层级的 Background 块里所有场景都会自动先执行这一段。配合 Playwright 的浏览器自动化能力Background 能帮你把环境准备、用户登录、数据初始化这类动作收敛到一处改一次全用例生效。这篇教程适合两类人一类是刚开始用 pytest-bdd 写 Playwright 用例的测试开发另一类是已经写了不少用例、正在被海量重复 Given 步骤折磨得想重构的老手。我会先讲清楚 Background 的定位和语法再给出一套完整的 Playwright 示例最后把我在实际项目里踩过的坑和排查思路全都倒出来。1. Background 的角色定位它到底是什么能不能乱用1.1 先看一个典型的痛点场景假设你要给一个电商后台写 20 条测试用例。每一条用例都在说“当管理员登录后点击订单管理看到订单列表然后……”。如果你老老实实把“打开浏览器”“登录管理员账号”“点击订单管理”这三个步骤复制到每一个 Scenario 里feature 文件会长得又臭又长。实际维护的时候更痛苦某天登录流程从“输入账号密码”改成了“扫码登录”你得去这 20 条用例里逐个修改那几段 Given 步骤漏改一条就等着测试失败后熬夜排查。这正是 Background 要解决的。在 BDD 的 Gherkin 语法里Background 块写在 Feature 关键字之后、第一个 Scenario 之前它里面的每一步都会被强制执行到该 Feature 下的所有 Scenario 前面。换句话说Background 是“这个功能模块所有场景都共享的一套前置剧情”。1.2 和 Given/When/Then 的关系很多人会问Background 里的步骤是不是就等于 Given其实不完全一样。Given 通常表达“在某种给定状态下”它属于某个场景的具体前置比如“给定用户已登录”“给定库存数量为 10”。而 Background 表达的是一组对所有场景都生效的公共状态它更像测试代码里的 setUp() 方法。从执行时机看pytest-bdd 会先把 Background 里的步骤全部执行完再接着执行每个 Scenario 自己的 Given、When、Then。这个顺序在 Gherkin 设计里是强制的Background 必须写在所有 Scenario 之前每个 Feature 最多只能有一个 Background。1.3 什么情况下不适合用 Background虽然 Background 很好用但它也不是万能药。我个人的判断标准是只有“真的要被执行多次且完全一致”的公共前置才放进去。如果某个场景需要登录另一个场景不需要登录那就不该把“登录”放进 Background否则你只能痛苦地在每个场景里写“跳过登录”这种丑陋的补偿步骤这会把测试用例的意图搅浑。再比如有些前置步骤只在少数几个场景里用到硬塞进 Background 反而会让其他无关场景白跑一遍不必要的操作拖慢整体执行时间。说到底Background 是一种“收敛重复”的工具不是“收纳所有 public 代码”的垃圾桶。2. Background 的定义语法与组织方式Feature 文件的正确写法2.1 Gherkin 语法速览一个标准的 feature 文件局部会是这样Feature: 订单管理 Background: Given 管理员已经登录系统 And 打开订单管理页面 Scenario: 查看订单列表 When 点击“全部订单”筛选条件 Then 页面展示所有订单记录 Scenario: 搜索指定订单 Given 订单号是“SO2023001” When 在搜索框中输入该订单号并点击查询 Then 页面展示匹配的订单记录注意Background 里的步骤关键字可以用“Given”开头也可以直接用“Given”和“And”混合。不过 pytest-bdd 的解析器对步骤文本的匹配规则很宽容只要你注册的步骤函数能对得上具体文本就行关键字本身不参与匹配。2.2 与 Hook 的对比我为什么更愿意用 Background很多 Playwright 项目里会直接用 pytest 的 fixture 来穿件浏览器实例和页面对象甚至有些团队会在 conftest.py 里写一堆自动化登录的 fixture。那 Background 和 fixture 有什么区别这里有个设计哲学上的差异fixture 是代码层面的复用玩的是 Python 的作用域和依赖注入而 Background 是业务层面、用自然语言写出来的前置条件它在 feature 文件里一目了然。我的团队现在倾向这样的分工用 fixture 管浏览器生命周期比如启动 Chromium、创建上下文、释放资源这些对测试用例来说太“技术化”不适合写进 Gherkin 里用 Background 管业务状态比如登录、导航、初始化数据这些是产品经理、业务分析师也能读懂的步骤。你想想如果产品经理打开一个 feature 文件看到满屏 pychrome 和 context fixture他根本不知所云但他看到“管理员已经登录系统”立刻能明白这是一个前置条件。2.3 多场景下的组织顺序当你在一个 feature 文件里规划多个场景时我推荐先把所有场景都列出来再看它们的共同前缀是什么。比如订单管理这个 Feature20 个场景里可能 18 个都需要“管理员登录 进入订单管理”但你发现有两个场景是“游客访问订单管理页面应跳转到登录页”这就说明“管理员登录”不能放 Background你就得手动把公共登录步骤写进那 18 个场景。如果你发现绝大多数场景都要执行一组公共步骤但少数场景不需要你可以考虑把它们拆成两个 Feature 文件——一个带 Background一个不带。这比在 Background 里加条件判断要干净得多。从实际维护经验来看宁可多建一个 feature 文件也不要做复杂分支。2.4 变量传递与作用域pytest-bdd 在 Background 里定义的变量是在上下文作用域内保留的吗答案是Background 步骤函数和 Scenario 步骤函数会共享同一个场景上下文对象通过 fixtures 注入。你可以在 Background 的步骤实现里给某个 fixture 赋值然后在后续场景步骤里读取。但注意每个 Scenario 执行完后这个上下文就会被清理Background 不会跨 Scenario 累积状态。这很合理保证每个场景是独立可重复的。所以如果你需要把某些数据比如订单 ID在 Background 里生成然后在每个 Scenario 里引用可以直接把这个值存到步骤对象的变量里pytest-bdd 的场景上下文会帮你保留。3. 在 Playwright 中实现 Background 的实操从零搭建一套完整示例3.1 环境准备与项目结构我用一个模拟项目 X 来演示这个名字是我虚构的你们直接照着做就行。项目结构建议这样project_x/ features/ order_management.feature step_defs/ test_order_management.py conftest.py pytest.inirequirements.txt 里至少需要这些包pytest、pytest-bdd、playwright。装完以后记得执行一次 playwright install chromium否则运行会直接报错。3.2 conftest.py 里管理与浏览器生命周期先说浏览器怎么创建。我会在 conftest.py 里定义一个全局 fixture用 yield 的方式保证最终能释放资源这样不管用例成功还是失败都不会残留浏览器进程。import pytest from playwright.sync_api import sync_playwright pytest.fixture(scopefunction) def browser_page(): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context() page context.new_page() yield page context.close() browser.close()这个 browser_page fixture 会作为步骤函数的一个参数传入。为什么我是 function 级别的因为每个场景基本都需要一个干净的浏览器环境省得场景之间互相污染。3.3 step_defs 里的步骤实现在 test_order_management.py 里你会写这样的代码来把 Gherkin 步骤翻译成 Python 代码。我特意用 pytest-bdd 的 given、when、then 装饰器来注册步骤from pytest_bdd import scenarios, given, when, then, parsers scenarios(../features/order_management.feature) given(管理员已经登录系统) def admin_logged_in(browser_page): browser_page.goto(https://example-admin.com/login) browser_page.fill(#username, admin) browser_page.fill(#password, secret) browser_page.click(#login-btn) # 断言登录成功否则后续步骤会走错路 assert Dashboard in browser_page.title() given(parsers.parse(打开订单管理页面)) def open_order_page(browser_page): browser_page.goto(https://example-admin.com/orders)这里要注意 Playwright 的同步 API 和异步 API 差异我习惯用同步 API 配合 pytest因为 pytest-bdd 对同步函数支持得最顺手。如果你一定要用异步 API就得额外引入 pytest-asyncio运行时会多很多心智负担非必要不上。3.4 完整示例带 Background 的 feature 如何运行我现在把整个 feature 文件补完整加入三个场景其中一个故意用 Background 里生成的订单号数据来验证跨步骤变量传递Feature: 订单管理 Background: Given 管理员已经登录系统 And 打开订单管理页面 Scenario: 查看订单列表 When 点击“全部订单”筛选条件 Then 页面展示所有订单记录 Scenario: 搜索指定订单 Given 订单号是“SO2023001” When 在搜索框中输入该订单号并点击查询 Then 页面展示匹配的订单记录 Scenario: 重置搜索条件 Given 订单号是“SO2023002” When 点击“重置”按钮 Then 搜索框内容被清空 And 订单列表恢复为全部订单运行命令就是pytest features/order_management.feature。pytest-bdd 会自动匹配到 step_defs 里的步骤函数。当你运行这个测试时你会发现两个 Scenario 在各自执行第一条 Given 之前都先执行了“管理员已经登录系统”和“打开订单管理页面”这两步一共执行了两次。这正是 Background 的预期行为。它能确保每个场景都在同样的初始业务状态下开始。3.5 步骤里如何从 Background 传递数据到场景我在 Background 里生成的数据怎么在后面的 Given 里用有人会直接定义一个 fixture用它来存数据。举例pytest.fixture def order_data(): return {} given(管理员已经登录系统) def admin_logged_in(browser_page, order_data): browser_page.goto(...) # 模拟生成一个随机订单号并存入 order_data order_data[order_no] SO str(time.time()) then(parsers.parse(搜索框内容被清空)) def check_clear(browser_page, order_data): assert browser_page.input_value(#search-box) # 这里依然能拿到 Background 里存的 order_no因为同一场景共用同一批 fixture 实例 print(order_data[order_no])因为 fixture 的默认作用域是 function同一个测试流程内所有步骤函数拿到的 order_data 是同一个对象所以 Background 里的修改在后续步骤里是可见的。如果你在 Background 里只是创建数据而不是读取这个模式特别顺手。3.6 用表格数据批量跑场景时的 Background 表现feature 文件还可以用 Scenario Outline 配合 Background 一起用例如Scenario Outline: 订单状态筛选 Given 订单号是“order_no” When 筛选状态为“status” Then 页面展示状态为“status”的记录 Examples: | order_no | status | | SO20230001 | 已支付 | | SO20230002 | 已发货 |这种情况下Background 依然会在每一行示例执行前都跑一遍保证每个独立的用例都共享同一套前置环境。我见过有的新手会误以为 Background 会跨表格缓存其实不会它只管每个独立测试流程。3.7 实测中关于等待和超时的经验Playwright 的核心特点是所有操作都自带自动等待它会不断重试直到元素可操作。但在 Background 里登录时如果页面跳转比较慢或者有登录接口的延迟自动等待也可能失效——尤其是当你直接用page.goto后立刻做fill时如果登录页本身有 loading 效果可能前几毫秒定位不到输入框。我在实际项目里会给 login 流程显式加一个page.wait_for_selector(#username, statevisible)别嫌多余这能排除掉 90% 的偶发失败。还有一次我踩到坑开发环境的登录接口经常返回 504但 Playwright 的 goto 会等页面加载完不会报错此时页面停留在服务器错误页assert Dashboard in page.title()直接失败。虽然失败了我很高兴因为用例确实测出了问题但如果是为了验证后续业务流程我建议在步骤里加上重试逻辑或者用一个更稳定的测试环境。4. 常见问题与排查技巧实录Background 真正会踩的坑4.1 语法位置写错导致解析失败这是新手最容易犯的错。pytest-bdd 解析 Gherkin 时要求 Background 必须放在 Feature 关键字后面、第一个 Scenario 前面。如果你误把 Background 放在了某个 Scenario 之后解析器会直接报错告诉你“Background 只能出现在 Feature 的开头”。排查方法很简单看看报错信息里的行列号重点检查 feature 文件里是否把 Background 写在两个 Scenario 之间了。4.2 步骤重复定义冲突我经常会在项目里看到不同步骤文件重复定义了同一个步骤文本比如一个在 conftest 里给全局用的“Given 管理员已经登录系统”另一个在业务 step_defs 里也定义了同样文本。pytest-bdd 碰到这种冲突会抛异常很难排查因为可能会有两个项目分支无意间引入相同步骤。解决方式只在一个地方定义公共步骤。我的个人习惯是在项目根目录建一个共享的 step_defs 文件保证这些公共步骤只在全局出现一次。4.3 变量作用域带来的状态污染有经验的开发会知道fixture 的 function 作用域意味着每个测试过程独立但这有一个例外如果你用了 module/session 级别的 fixture它有可能跨场景共享。Background 里如果你不小心改了这种大作用域 fixture 的数据那它会污染到后续所有场景轻则断言失败重则隐藏逻辑死循环。举个例子我踩过一次坑在 Background 里把全局用户 token 保存到一个 session 级 fixture 中但第二个场景里没有清理 token导致第三个场景登录时拿到了旧的 token所有请求都带着一个过期凭证整个测试套间像多米诺骨牌一样倒下。排查方式很恶心因为报错指向的是具体请求而不是 login。所以我现在有一条铁律任何跨场景共享的数据必须只读如果想模拟不同的登录态直接在 Background 里重新执行登录不要偷懒复用旧 token。4.4 执行顺序与并发问题pytest-bdd 默认按顺序执行 feature 文件里的场景但如果你用了 pytest-xdist 并行跑用例就需要特别注意 Background 里的操作是否会跟其他用例打架。比如浏览器共享端口、后台数据状态冲突等。实际当中并行跑 Playwright 测试最好一个 worker 配一个浏览器实例并且 Background 里不要依赖外部全局状态。我见过有些团队用 xdist 跑 UI 自动化结果发现 Background 里的登录操作被并发执行了十遍把认证服务打成热点大量 429 报错。要做到稳定并行就得在 fixture 里给每个 worker 独立资源并且在 Background 步骤里避免对公共接口做频率过高的调用。4.5 调试技巧如何快速定位 Background 里失败的步骤pytest-bdd 里有个非常方便的--tbshort参数它能直接显示每一步的调用堆栈。但想真正定位 Background 里的失败还得靠 pytest-bdd 自带的运行日志。如果你运行pytest -spytest-bdd 会打印出每一步的文本和执行时间很清楚地看到执行到 Background 的哪一步出了问题。此外我强烈建议在写 Background 步骤时只做和高集成相关的操作不要把一大堆验证逻辑塞进去。它本质是“环境准备”不是“业务断言”。如果 Background 里的验证太多一旦前置环境出错你会看到十几个场景同时失败根本分不清是功能问题还是环境问题。我的原则是 Background 步骤只做动作、不做过重的检查最多加一个轻量断言表示“前置动作成功了”。4.6 后台登录会话的管理用 Playwright 写 Background 频繁登录时如果后台系统对频繁登录有限制比如验证码指纹检测那这种重复登录会让你很头疼。一个比较可靠的方案是复用同一个浏览器 context 的 storage_state。你可以先在测试环境手动登录一次用context.storage_state(pathauth.json)保存登录态然后在每个测试的 fixture 里通过browser.new_context(storage_stateauth.json)加载登录态从而跳过 UI 登录这一整段 Background。这样你甚至可以把“管理员已经登录系统”改成一步通过 storage_state 完成背景步骤只剩一个页面导航。考虑到执行速度和稳定性我在正式项目里越来越倾向于这种方式。不过提醒一下如果你们团队的测试环境会定期清理 session或者登录态有几分钟的过期时效那这种方式反而坑人因为你会因为 auth.json 过期而不断报错。折中方案是把 auth.json 的刷新做成一个独立作业在跑测试前先更新一次。4.7 Feature 文件里的中英文混用很多人喜欢把 Given/When/Then 关键字保持英文然后步骤描述全部用中文。Gherkin 本身支持本地化关键字pytest-bdd 也支持中文关键字比如 假如/当/那么。但在团队协作时我建议统一用一种语言写关键字不要一会儿 Given 一会儿 假如。混在一起会导致部分编辑器插件高亮失灵而且容易让不熟悉这套流程的人困惑。我在示例里用的是英文关键字和中文步骤描述这个组合在多数团队里都算常见。如果你跑不起来先检查 pytest-bdd 版本老版本对新版 Gherkin 关键字的支持可能有差异。4.8 一个我常用来规避 Background 滥用的小技巧如果你发现 Background 里的步骤开始出现条件分支比如“如果用户类型是管理员则执行 A否则执行 B”这就意味着你对 Feature 的拆分粒度出了问题。在 BDD 里不同的前置条件应该对应不同的 Feature 或不同的 Scenario 描述不该用编程式的分支逻辑来掩盖复杂性。我在评审代码时看到这种分支会立刻建议把该 Feature 拆成多个小 Feature每个 Feature 专门描述一类前置条件。这样 Background 就永远是直线结构没有 if/else。5. 在大型测试套件中维护 Background 的经验总结5.1 从项目初期就要规划 Background 的边界我见过太多项目测试代码写了大半年才开始愁重复步骤的问题然后猛然想起 Background 这个功能一顿重构。其实后悔是没用的重构的代价远比一开始就规划好大得多。如果你现在刚开始搭建一套新的 pytest-bdd 测试框架我建议第一步就是把登录、导航这类全局性动作在 Feature 文件里定义成 Background并尽快落地成公共步骤。后面每增加一个新场景先问自己这个场景和同事场景共有哪些前置如果有是不是应该归入 Background5.2 Background 里的步骤也要保持高效每次执行一套完整的 pytest 回归Background 步骤会随着场景数量线性增加执行开销。如果你的套件里有 500 个场景哪怕 Background 只有三步每步要花两秒光是 Background 就要跑 3000 秒非常恐怖。所以 Background 里的步骤一定不能重。能靠 storage_state 绕过的登录就不要做真实 UI 输入能直接从数据库插入的数据就不要走界面创建。把 Background 执行时间压缩到最快能让整个套件跑得更轻。有时候我在公司里会做一个简单的统计用 pytest 的--durations10参数看最耗时的测试步骤如果 Top 10 里全是 Background 相关的步骤那说明 Background 里塞了太多硬核操作需要优化。5.3 与数据清理和测试隔离的关系Background 执行之前最好先保证数据库里是干净状态。否则你登录后进入订单管理页面发现以前测试留下的脏数据还挂在列表里后续 assertEquals 就不可能稳定。我通常在 conftest 里加一个自动清理 fixture在每轮测试开始前把测试表里的数据清空。这样 Background 里的导航操作才会基于一个可预期的初始状态。不过要注意清理操作如果走的是后台接口而接口本身也依赖登录那就要谨慎设计清理顺序避免形成循环依赖。5.4 文档与协作视角让业务同事读得懂Background 真正的价值在协作层面而不是代码层面。传统自动化测试里新同事跑完一条用例他完全看不出哪些操作是业务前置、哪些是断言步骤。但通过 Background你只要打开 feature 文件就能看到一条清晰的剧情线系统前置状态 - 场景操作 - 场景断言。我强烈建议在每个 Feature 文件的顶部用注释写清楚该模块的 Background 用来保证什么状态比如“确保当前登录用户为管理员且已进入订单管理页所有场景都从这个入口开始”。花两分钟写这个注释能让以后接手的人少踩一堆坑。5.5 版本演进当我需要改变公共前置时需求是不断变化的。有一天你们的产品从“必须先登录才能看订单”改成了“游客也能查看部分订单页面”那么整个 Feature 的 Background 逻辑都得动。如果你把登录放进了 Background那就意味着所有场景都会先登录这与“游客可见”的需求直接冲突。这时候就要评估是把这个 Feature 拆成两个游客可见和登录后可见还是移除 Background 里的登录步骤然后逐场景手动补上。我的建议是优先拆 Feature。为什么因为不同的前置状态代表不同的用户故事你这个 Feature 里的场景如果一半需要登录、一半不需要那本质上它们就不是同一个功能模块的二级标题gherkin 文件也会越来越难维护。拆分后每个 Feature 的 Background 都保持稳定后续需求再变你只需改动对应 Feature 的 Background其他场景不受牵连。6. 进阶结合数据驱动与外部工具让 Background 更顺手6.1 从数据库批量初始化数据到 Background你可能会遇到一个场景订单管理页面要先有大量订单才能测试分页和筛选。如果靠 UI 一个个创建订单Background 会慢到让人怀疑人生。这时我在 conftest.py 里会做一个自动化测试用户可以通过调用内部 API 或者直连数据库在 Background 里快速造数。given(系统存在多个订单) def seed_orders(db_client): for i in range(50): db_client.insert_order(...)这个做法能大幅提升执行效率但要注意你是在和数据库耦合一旦表结构变更这个 Background 步骤就得同步改。所以在团队内部要约定好这种造数步骤必须放在专门的基础数据模块里不要让每个业务 feature 都去碰数据库。如果 DB 结构与技术栈经常变那就退化成调用 API 或者走 UI看你们对隔离和速度的取舍。6.2 在 Background 里切换多角色登录如果你们的系统分管理员、运营、客服三种角色且所有场景都需要某个角色登录那就可以在 feature 文件里把角色当作 Background 的一部分描述Background: Given 以管理员身份登录系统然后在 step_defs 里写一个带参数的步骤given(parsers.parse(以{role}身份登录系统)) def login_as_role(browser_page, role): account get_account_by_role(role) browser_page.goto(...) ...这样你只需写一个步骤实现却可以覆盖所有角色的公共前置。如果你还有额外要求比如某些角色需要跳过特定配置那就在该 feature 里额外增加一个 Background 步骤来补充差异不要改共享的公共步骤函数。6.3 通过环境变量控制 Background 行为在我工作过的项目里测试环境分为本地开发、集成测试、预发。有时登录方式不同比如本地环境不需要验证码预发环境需要验证码。我会在 Background 步骤里根据环境变量切换登录行为import os given(管理员已经登录系统) def admin_logged_in(browser_page): if os.getenv(TEST_ENV) preprod: # 走预发专属登录流程 pass else: # 走常规登录 pass虽然这种分支让我在上面刚说了“不要用分支掩盖复杂度”但环境差异确实存在而且和业务领域无关放到 Background 步骤里反而合理。你可以把这种环境适配逻辑封装成 helper不要在步骤函数里堆 if/else。6.4 结合 Allure 报告查看 Background 的执行情况如果你用 allure 生成测试报告你会发现 Background 里的步骤会全部附在每条测试用例的执行步骤里。这是个很好的特性因为它能直观告诉业务人员“每条用例的执行路径是什么样的”。但报告也会因为 Background 太长而显得冗余。我在实际使用中会开启 allure 的步骤折叠功能把 Background 步骤折叠起来需要时再展开这样报告既完整又清晰。6.5 用 pytest 的 fixture 参数化来驱动不同 Background 数据有些系统有多种业务线每种业务线的订单编号前缀不同、页面展示字段不同。你可以在 step_defs 里写一个带有参数的 Background 步骤然后通过 fixture 来传入业务线标识。这个思路我建议只在非常明确的多租户场景下使用否则会把 feature 文件的阅读难度拉高。因为一个 Background 如果带参数别人看 feature 文件时不一定能马上明白当前组合是什么。我更倾向于为不同业务线分别写 Feature 文件每个文件的 Background 写死业务线对应的常量这样反而更直观避免绕来绕去。6.6 聚焦执行只跑某个 Scenario 时 Background 依然生效pytest-bdd 允许你使用-k参数来过滤测试节点比如pytest -k search_order。只有被选中匹配的 Scenario 会执行但 Background 还是会为这个 Scenario 先走一遍。这个特性的实际价值是当你只需要验证一个复杂场景而不想跑整个回归你依旧能保证每一项独立验证都是“从公共前置状态开始”不会因为你只跑了一条用例而破坏这个约束。7. 我实践一年后对 Background 的真实体会从我开始把 pytest-bdd 和 Playwright 组合用于实战到现在也积累了不下两百个 feature 文件。Background 在这套体系里给我的最大帮助不是“少写几行 Given 步骤”而是它逼着我在设计用例前先去思考这个模块真正不变的那条基线在哪里以前写 setUp() 时我总是凭直觉把登录放进去但从来没有像用 Background 那样从业务叙事的角度去审视。用 Background 之后每次新建一个 feature 文件我都要先问产品和开发这几个场景共有的前置条件是什么有没有例外这看起来是个技术讨论实际上把业务的边界厘清了不少还经常能发现以前测试用例设计的盲区。在维护阶段Background 还能让你快速回答一个关键问题“这个功能模块在被测试时系统处于怎样的初始状态” 新同事看代码先从上往下扫 Background比追着 fixture 上下文到处跑要轻松得多。最后分享一个小技巧如果你已经在用 Background 管理登录和页面导航可以考虑给这一步的半结构化数据做一份清单。比如在项目文档里列明“所有 Feature 的 Background 今后统一使用步骤 X 登录不要新建私有步骤。” 这句话能防止团队里大量出现“私有登录”副本进一步压缩重复成本。测试代码本质上也是代码保持 DRY 原则能救你于水火。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
