本技能提供 Cucumber 测试的模式与反模式，目标是让验收测试以业务行为为中心、可读且易维护。
用途：指导团队编写高质量 Gherkin 场景与步骤定义，避免实现细节耦合，并合理定位 Cucumber 在测试金字塔中的位置。
主要能力与要点： 场景设计：写声明式而非命令式场景，聚焦“做什么”而非“怎么做”；一个场景只验证一个业务行为；场景之间保持独立，各自准备前置条件；Background 仅用于真正通用的初始化，避免堆砌过多步骤。 Gherkin 编写：使用业务领域语言而非技术术语；步骤保持同一抽象层级；避免用 And 把多个独立动作合并成一句。 Scenario Outline：仅用于同一行为的不同数据变体，不要用它拼凑互不相关的用例；Examples 应分组并保持含义清晰。 标签：用 @smoke、@critical、@slow、@integration、@wip 等标记场景，并按标签筛选运行，例如 cucumber --tags "@smoke"、cucumber --tags "not @wip"、cucumber --tags "@smoke and @critical"、cucumber --tags "@smoke or @critical"。 步骤定义：编写可复用步骤，如 When('I fill in {string} with {string}', ...)，同时避免过度泛化导致可读性下降。 数据管理：用工厂（如基于 faker 的 UserFactory）生成测试数据，避免硬编码 ID，改用命名实体。 错误处理：同时覆盖正常路径、错误路径与边界情况。 性能与维护：为慢测试打标签，确保场景可并行执行（如 cucumber.js 中配置 --parallel 4）；定期清理过时场景、重构重复步骤、按功能组织 features 目录。
常见反模式：断言数据库记录数等实现细节、在业务场景中断言具体 UI 样式、用 Given 描述动作、使用技术术语（如直接写 POST 请求）。
测试金字塔建议：Cucumber 用于高价值验收测试（关键用户旅程约 20%），集成测试约 30%，单元测试约 50%，不要用 Cucumber 覆盖一切。
限制：资料未提供具体安装命令、版本要求、支持的编程语言范围及收费信息。