Background 的使用边界是什么
Background 是 Gherkin（Cucumber 语法）中为同一 Feature 内所有场景提供公共前置步骤的结构：登录、基础数据准备这类每个场景都需要的步骤适合放进来，避免在每个场景里重复。要控制数量：过多前置会掩盖场景差异、拖慢执行，并让「场景单独执行失败」难以定位。
基本信息
| 作用域 | 整个 Feature，每个场景执行前都会先跑 Background |
|---|---|
| 适用内容 | 登录、基础数据创建等真正全局的前置 |
| 不适用 | 只与个别场景相关的准备步骤 |
| 命名建议 | 前置步骤描述业务状态而非操作细节 |
| 影响评估 | 修改后需重跑该 Feature 全部场景 |
| 替代手段 | Before 钩子适合技术性准备，不进入阅读层 |
Background 示例
Background 示例
Feature: 租户管理
Background:
Given 已登录管理后台
And 已存在 1 个测试租户
Scenario: 查看租户列表
When 打开租户列表
Then 可以看到 1 个租户
# Background 步骤变更会影响本 Feature 全部场景，评审时评估影响面典型使用场景
- 减少重复：多个场景共享同一段前置时提取到 Background。
- 阅读体验：场景正文聚焦差异化步骤，前提条件一目了然。
- 评审辅助：前置集中展示，评审时一眼看清共同假设。
- 重构手段：场景里出现重复前置时，考虑上移到 Background。
- 测试数据管理：基础数据在统一位置创建，便于核对。
- 失败定位：前置即失败时能快速区分环境问题与场景问题。
使用位置对照
| 使用位置 | 适合放什么 | 注意 |
|---|---|---|
| Background | 登录、基础数据等全局前置 | 变更影响整个 Feature |
| 场景步骤 | 与场景强相关的准备与操作 | 重复两三次可考虑上移 |
| Before 钩子 | 技术性准备（清理、注入） | 不体现在业务阅读层 |
| Scenario Outline | 参数化同一流程 | 与 Background 可叠加使用 |
Background 步骤变更会影响该 Feature 的全部场景，评审时要评估影响面，而不是只看改动的那一行。
把与个别场景相关的步骤放进 Background 是最常见的误用：会产生大量无关准备，还掩盖真实依赖。
Background 不应包含断言：它是准备不是验证，断言留给场景步骤。