把用户故事和验收标准转成合法的 .feature 文件。
生成结果适合放进工单、PR 或设计评审。它应在实现开始前写清责任人、决策、证据和后续工作。
Feature: Refund retry protection Scenario: duplicate refund request Given a refund is pending provider confirmation When support submits the same refund again Then the existing refund_id is returned And no second provider call is made
把生成的Gherkin feature 文件当成起点，而不是最终答案。替换示例值，补证据，指定评审人，删掉团队不会维护的字段。
Gherkin 是一种用自然语言描述软件行为的语法。Feature 说明测试对象，Scenario 描述一个具体例子，Given / When / Then 组织前置条件、操作与预期。Cucumber、Behat、SpecFlow 等框架能直接解析 .feature 文件。
好的场景说明已有状态、角色做了什么、结果必须如何成立。除非 UI 本身就是测试对象，否则不要写“点击右上角蓝色按钮”这类脆弱步骤。
每个场景都应该单独读懂。如果一个场景必须依赖另一个场景先执行，把共享状态放进 Background，或拆成更小的 feature 文件。
“登录失败”太模糊。“密码错误时显示错误提示，并且不创建会话”才可测试。能帮助理解预期行为时，直接写具体数据。
每个生成场景都应该能追溯到规格里的某条需求。如果一个场景没有保护真实用户、API 或业务规则，它很可能只是噪声。
Scenario: 重置密码Given 我在页面上When 我提交表单Then 它成功
这个场景没有说明用户状态、提交了什么输入，也没有说明什么结果能证明重置流程成功。
Scenario: 用户请求重置链接Given [email protected] 是已验证用户When 她请求密码重置Then 系统排队发送一次性重置邮件
这个版本写清了状态、动作和可观察输出，QA、自动化测试和实现评审都能直接使用。
算法复杂度、内部缓存策略、数据库索引选择等技术约束，通常用单元测试、性能测试或迁移检查表达更清楚。
如果团队还没有确定用户行为和业务结果，先写普通规格或决策记录。太早写 Gherkin 容易把未决问题伪装成测试。
当场景只是在描述点击、滚动和输入框位置时，维护成本会很高。把步骤提升到用户意图和可观察结果层面。
把生成的场景拿给产品、研发和测试共同评审，确认角色、状态和结果是否使用同一套业务语言。语言一致后再接自动化。
不是所有场景都必须进入端到端测试。优先自动化核心流程、权限边界和高失败成本路径，其他场景可以作为人工验收说明。
接入自动化之前，先确认每个步骤都能在不理解内部实现的情况下验证。如果 Then 需要读数据库内部字段或日志才能判断，就应改写成用户、接口或事件层面的可观测结果。
Gherkin 文件更容易维护的前提是：所需用户状态、种子数据、权限和 feature flag 都能在场景附近找到，而不是藏在很远的共享测试初始化里。
当产品行为变化时，应该在同一个 PR 里更新或删除对应场景。描述旧行为的 feature 文件会制造虚假的安全感，也会让后续重构变慢。
如果某个场景需要大量背景才能读懂，通常说明 feature 文件应拆分，或业务语言还没有统一。先修正表达，再连接测试框架。
导出后建议让 QA 先删掉无法验证的步骤，再让工程接入自动化；顺序反过来会让测试代码固化错误表达。
场景语言稳定后，自动化维护成本会低很多。
评审通过的场景也更容易复用到回归测试。
每个场景都应保护一个真实用户结果、权限边界、接口契约或回归风险。如果它只是描述如何点击页面，很可能只是脆弱脚本，而不是有价值的规格。
评审者应该能指出哪个 UI 状态、响应体、事件、数据库可见状态或审计记录证明 Then 步骤已经通过。
先把导出的场景当作共享行为文档评审，再决定是否转成自动化测试。如果 QA 不能从场景里看出准备数据、执行动作和断言结果，就应该先改文案，而不是急着写步骤定义。
feature 文件、规格、UI 文案和客服文档应使用同一套状态、角色和行为名称。Gherkin 的价值来自共享语言，如果每个团队叫法不同，场景很快会失去约束力。
不一定。适合用 Gherkin 的，是需要可执行示例或共享业务语言的行为。有些技术约束用单元测试、API 契约测试或迁移检查会更清楚。
覆盖关键行为即可：主流程、重要失败路径、权限边界和一两个边界情况。如果文件开始难以扫描，就按工作流拆分。
表单会推动场景写清前置状态、触发动作和可观察结果，避免验收标准在工单里看起来正确，却无法变成有效测试。
生成场景会检查产品、QA 和研发是否能基于同一份 feature 文件理解准备数据、用户动作、期望结果和业务用语。
作者与编辑：Daniel Marsh。复查流程：编辑政策。纠错与工具问题：联系。最近复查：2026 年 4 月 28 日。