接受标准编写Skill acceptance-criteria-authoring

---

名称: 接受标准编写 描述: 使用Given-When-Then格式编写清晰、可测试的接受标准，遵循INVEST原则和BDD最佳实践。 允许工具: 读取, 写入, 全局匹配, 搜索, 任务

接受标准编写

何时使用此技能

在以下情况使用此技能：

• 接受标准编写任务 - 处理编写清晰、可测试的接受标准，采用given-when-then格式，遵循invest原则和bdd最佳实践
• 规划或设计 - 需要关于接受标准编写方法的指导
• 最佳实践 - 希望遵循既定模式和标准

概述

接受标准定义了用户故事必须满足的条件，才能被视为完成。编写良好的接受标准能够实现利益相关者之间的清晰沟通，并推动自动化接受测试。

Given-When-Then格式

Given [前提条件/上下文]
When [动作/事件]
Then [预期结果]

组件

组件	目的	示例
Given	设置初始上下文	“Given 一个已登录的高级用户”
When	触发动作/事件	“When 他们点击’下载报告’”
Then	断言预期结果	“Then 一个PDF报告下载”
And	链接多个条件	“And 报告包括所有订单”
But	否定断言	“But 归档订单被排除”

INVEST原则用于用户故事

字母	原则	描述
I	独立性	可以按任何顺序开发
N	可协商性	细节可以讨论
V	有价值	交付用户/业务价值
E	可估算	团队可以估算大小
S	小规模	适合一个冲刺
T	可测试	有清晰的接受标准

接受标准最佳实践

做 ✅

• 使用业务语言，而非技术行话
• 具体且可测量
• 包括快乐路径和边界情况
• 保持场景聚焦和原子性
• 从用户角度编写
• 包括错误场景

不要 ❌

• 包括实现细节
• 让标准太宽泛
• 使用模糊术语（“快速”、“用户友好”）
• 在一个场景中结合多个行为
• 跳过错误处理场景

示例：电子商务结账

用户故事

作为一个注册客户
我想用保存的支付方式结账
以便我能快速完成购买

接受标准

特性: 使用保存支付结账

  背景:
    Given 我作为注册客户登录
    And 我有一个保存的Visa卡，卡号以4242结尾

  场景: 使用保存卡成功结账
    Given 我的购物车中有总计$50.00的商品
    When 我继续结账
    And 我选择我的保存Visa卡
    And 我点击"下订单"
    Then 我看到订单确认页面
    And 我收到确认电子邮件
    And 我的卡被扣款$50.00

  场景: 使用过期保存卡结账
    Given 我的保存卡已过期
    And 我的购物车中有商品
    When 我继续结账
    And 我选择我的过期卡
    Then 我看到一条消息"此卡已过期"
    And 我被提示更新卡或添加新卡

  场景: 卡被拒绝时的结账
    Given 我的购物车中有商品
    When 我继续结账
    And 我选择我的保存卡
    And 我点击"下订单"
    And 支付被拒绝
    Then 我看到一条消息"支付被拒绝。请尝试其他支付方式。"
    And 订单未创建
    And 我的购物车被保留

  场景: 库存不足时的结账
    Given 我的购物车中有3个"Widget X"单位
    And 只有2个单位在库存中
    When 我继续结账
    Then 我看到一条消息"Widget X: 仅2个可用"
    And 我被提示更新数量

场景模式

快乐路径

场景: 用户成功[动作]
  Given [有效前提条件]
  When [正确动作]
  Then [预期积极结果]

错误处理

场景: [动作]因[原因]失败
  Given [导致失败的前提条件]
  When [会失败的动作]
  Then [适当的错误消息]
  And [系统状态被保留/恢复]

边界情况

场景: [动作]在边界条件下
  Given [边界条件设置]
  When [边界处的动作]
  Then [边界处的预期行为]

安全性

场景: 未授权用户尝试[动作]
  Given 我未登录
  When 我尝试访问[受保护资源]
  Then 我被重定向到登录页面
  And 我看到"请登录以继续"

场景大纲

用于测试多个数据变体：

场景大纲: 基于订单价值的折扣应用
  Given 我的购物车中有总计<order_total>的商品
  When 我继续结账
  Then 我看到<discount>的折扣
  And 我的最终总计是<final_total>

  示例:
    | order_total | discount | final_total |
    | $50.00      | $0.00    | $50.00      |
    | $100.00     | $5.00    | $95.00      |
    | $200.00     | $20.00   | $180.00     |

.NET SpecFlow示例

[Binding]
public class CheckoutSteps
{
    private readonly CheckoutContext _context;

    public CheckoutSteps(CheckoutContext context)
    {
        _context = context;
    }

    [Given(@"我作为注册客户登录")]
    public void GivenIAmLoggedInAsARegisteredCustomer()
    {
        _context.Customer = TestCustomers.CreateRegistered();
        _context.Session = _context.AuthService.Login(_context.Customer);
    }

    [Given(@"我的购物车中有总计\$(.*)的商品")]
    public void GivenIHaveItemsInMyCartTotaling(decimal total)
    {
        _context.Cart = TestCart.WithTotal(total);
    }

    [When(@"我点击""(.*)""")]
    public void WhenIClick(string button)
    {
        _context.Result = _context.CheckoutPage.Click(button);
    }

    [Then(@"我看到订单确认页面")]
    public void ThenISeeAnOrderConfirmationPage()
    {
        Assert.IsType<OrderConfirmationPage>(_context.Result);
    }

    [Then(@"我收到确认电子邮件")]
    public void ThenIReceiveAConfirmationEmail()
    {
        var emails = _context.EmailService.GetEmailsFor(_context.Customer.Email);
        Assert.Contains(emails, e => e.Subject.Contains("订单确认"));
    }
}

覆盖检查清单

对于每个用户故事，确保覆盖：

• [ ] 快乐路径: 主要成功场景
• [ ] 验证错误: 无效输入处理
• [ ] 业务规则违规: 领域约束失败
• [ ] 授权失败: 访问控制
• [ ] 外部服务失败: 第三方集成错误
• [ ] 边界条件: 最小/最大值，空状态
• [ ] 并发: 多用户，竞态条件
• [ ] 状态转换: 有效和无效状态更改

接受标准模板

## 用户故事
作为一个[角色]
我想[动作]
以便[好处]

## 接受标准

### 场景1: [快乐路径描述]
Given [前提条件]
When [动作]
Then [预期结果]

### 场景2: [错误情况描述]
Given [错误诱导条件]
When [动作]
Then [错误处理行为]

### 场景3: [边界情况描述]
Given [边界条件]
When [动作]
Then [边界行为]

## 超出范围
- [明确排除的场景]

## 备注
- [实现提示或业务上下文]

集成点

来自的输入:

• 需求 → 故事上下文
• jtbd-analysis技能 → 任务步骤
• test-case-design技能 → 测试技术

输出到:

• SpecFlow/Cucumber自动化
• test-strategy-planning技能 → 接受测试范围
• 完成定义