BDD是从TDD发展过来的，也属于DDD中一种描述业务的无处不在的统一语言，它的描述格式是：

As a [Role]

I want [Feature]

so that [benefit]

用中文的意思来理解，我认为是：作为某个角色，我需要某些功能或权利，这样能得到相应利益。 正如职责驱动开发中奖职责责任作为分析突破口一样，这里好像是从这个方面作为切入点分析的。

这样一种描述方式能够帮助我们从用户故事中不断寻找到那种传递业务价值核心的信息。因为大部分我们的客户总是这样问：嗯，我希望有这样的功能....你看这样做可以吗？( . . . I want [some feature] so that [I just do, ok?].)

从以上用户故事中，我们能发现如果软件能够正确实施用户这些行为，我们可以将它们作为系统的测试方式和验收标准。

那么如何能保证软件正确实施用户这些需求行为呢？对于简单容易明白的，我们能一下子能知道掌握，但是复杂一点的怎么办？我们可以使用一种模板来套用截取。

这个模板是：

Given some initial context (the givens),

When an event occurs,

then ensure some outcomes.

给出某个场景，但事件发生时，将有什么结果发生。

我们以取款机ATM来举例这个模板的使用，假设用户故事是这样：

As a customer,

I want to withdraw cash from an ATM,

so that I don’t have to wait in line at the bank.

作为一个客户，我想从ATM机中提取现金，这样(好处结果是)，我不用在银行排队等候。

那么我们是如何知道我们已经成功传递了这个用户故事呢？对于这个故事的理解我们需要考虑几种场景情况：该客户账户可能是一个信用卡账户，有可能存在余款不够需要透支，而透支有存在透支额的问题，取款多少或多于或少于透支额等等多个可能情况。

我们使用given-when-then模板变成如下：

+Scenario场景 1: Account is in credit+ 账户是信用卡

Given the account is in credit 给出账户是信用卡

And the card is valid 并且卡是有效的

And the dispenser contains cash 并且ATM机有现金

When the customer requests cash 当客户请求取出现金时

Then ensure the account is debited 那么确保账户余额被扣除

And ensure cash is dispensed 并且确保现金被吐出

And ensure the card is returned 并且确保信用卡能退还。

+Scenario场景 2: Account is overdrawn past the overdraft limit+

账户已经透支。

Given the account is overdrawn 给出账户已经透支场景

And the card is valid 并且这个卡是有效的

When the customer requests cash 但客户请求取出现金时

Then ensure a rejection message is displayed 那么确保拒绝信息显示

And ensure cash is not dispensed 并且确保现金不会吐出

And ensure the card is returned 并且确保信用卡能退还。

对于上面两种不同场景，我们发现相同的点：事件 给出given 结果。

也就是说，given-when-then模板能够充分表达这几种不同场景发生的情况。