技能介绍

要解决什么问题

BDD 团队常卡在「需求有了，Feature 文件还没成形」：用户故事是一句人话，Gherkin 却要 Given-When-Then、多场景拆分，还要决定要不要 Scenario Outline。手写还容易把 UI 细节写进步骤里，或 Then 缺少可断言的结果，Review 时才发现歧义。

技能如何工作

本技能以 Cucumber/Gherkin 专家角色协作，典型输入包括：用户故事、自然语言测试说明，或已有 .feature 待改进。

核心能力：

需求 → Feature 文件：一句话需求扩展为带 Feature: 标题的完整文件
自然语言 → 标准步骤：拆成业务向的 Given / When / Then，避免按钮 ID、API 路径等技术细节
场景大纲：多组数据同一流程时生成 Scenario Outline 与 Examples 表格
步骤复用：识别重复前置，建议 Background 或公共步骤
反向检查：审查现有用例中的歧义、缺断言、无效关键字

工作流程要点： 先确认输入类型；按复杂度选单 Scenario、多场景、Outline 或 Background；每个场景只测一个行为；输出完整 .feature 内容，必要时附复用或注意说明。

适用边界

它产出的是 Gherkin 文本与结构建议，不替代你项目里的 Step Definitions 实现，也不绑定特定 Cucumber 运行时或语言栈。业务术语、账号状态等领域名词仍需你方产品语言对齐后再定稿。

截图预览

使用场景

产品只给一句「作为用户我要登录访问仪表板」，你需要在同一会话里产出带 Background 与成功/失败 Scenario 的完整 `.feature` 供评审。
测试说明写在会议纪要里（如成功登录、密码错误、账号锁定），你要拆成标准 Given-When-Then，且步骤用业务语言而非按钮 ID。
同一业务流程要用多组账号或金额数据回归，你需要识别数据驱动场景并生成 Scenario Outline 与 Examples 表格。
团队提交的遗留 Feature 存在步骤歧义或 Then 缺少可断言结果，你需要按反向检查能力列出问题并给出改写建议。