BDD目的

行为驱动开发（behavior-Driven Development, BDD）通过关注预期客户行为的解决方案，来满足客户需求，以实现增加价值、减少浪费、增加干系人与交付团队之间沟通的目的。

BDD描述

敏捷主要是为客户协作和可工作的解决方案提供价值，并且BA在敏捷框架下会通过增量的方式为客户交付价值，而BDD是可以通过实例来帮助我们实现这样的目标的。

BBD使用一种客户可以看得懂的，领域相关的语言来说明什么样的行为可以满足客户需求。

BDD聚焦在行为并且只提供需要开发的需求，这样可以提升交付速度，并且为UAT的自动化测试提供输入。

我们一般用BDD来明确需求，帮助大家沟通和理解需求，以便达成一致。比起大段的复杂的文字，BDD更加清晰，更加有逻辑性。

实例用来帮助理解我们要做的解决方案是什么，并且通过测试保证它会按照我们想要的方式工作。

通常实例由PO提供，并且借此澄清说明自己的想法，而BA通过提出一些“假设”问题来确定场景，以便扩展到其他的场景并将其表达为实例。

换句话说，PO给出主要场景的实例（实际发生的例子），BA通过问：

“如果发生了….需要怎么做？” 

“如果没发生…需要怎么做？”

这类的假设性问题将分支、意外场景补充完整，补充的时候依旧通过实例的方式。

使用BDD时，我们对于解决方案的所有讨论是基于容易让干系人理解的实例的，而不是一些经过抽象的UML模型等等。

BDD的简单的格式也便于大家的理解，会让干系人直接协作。

PO、测试人员、开发人员被称为“Three Amigos”，可以通过BDD进行协作沟通。

这样的协作沟通会鼓励交付团队像客户一样思考，并且只交付和实现预期行为所需要的东西。

实例

实例是由干系人提供的一些真实的业务场景。

它可以是一段话，一个故事，一个流程图，一段视频等等。

BA需要挖掘实例当中表达的信息，并且确保与需求相关的实例是完整的、全面的。

这也是之前提到的，BA会需要通过一些“假设”问题的提问来进行实例的补充。

我们都有过这样的经历，干系人表达的可能是他生活和工作中的一个场景，这个场景也许是一个主干场景，也可能是一个在特殊情况下才会发生的故事。

BA需要将其找出来，并且通过实例的方式澄清和表达。

实例确实是可以帮助我们有效的发现客户的信息，但是需要注意的一点是，并不是所有的实例我们都一定要放到解决方案的范围内，不是所有的实例都一定要实现或者交付的。

BDD语法

BDD使用一种简单的语法格式称为Gherkin，我们就填空进去就好了。

一般我会称呼其为Given-When-Then

理解起来非常简单：在一个场景下，当满足了什么条件时，会发生什么事情。

而且这里可以用And连接多个条件。

这里有个例子是ATM取款的简单实例：

通过上面的例子我们可以看出，BDD主要聚焦在场景：事件、条件和操作，并且可以验证。

BDD可以作为用户故事的验收标准，也可以作为测试驱动开发的测试。

我们会发现BDD在帮助不同角色理解需求上对比UML等工具更加容易达成一致。

测试

市面上有支持BDD的一些软件产品，并且可以将其转换为自动化测试，从而实现更加灵活的交付。

自动化测试是另外一个Topic了，我们在这里不进行深入的介绍了。

BA是通过自然语言的方式写BDD的，而自动化测试工程师会通过工具或者人肉将其转化为自动化脚本来实现自动化测试。

但是因为自动化测试的编写和维护成本比较高，我们一般不建议BA提供的所有BDD都转换为自动化测试脚本，我们会建议BA根据实例的商业价值和复用性高低等因素来决定哪些是需要进行转换的。

BDD的优势

容易理解

行为驱动开发（BDD）通过所有团队成员都能轻松理解的方式，用自然语言表达客户需求。并且是基于具体的例子而不是抽象的概念。

与开发联动

“Given When Then”模式直接映射到敏捷开发人员在测试驱动开发中使用的“Setup-Execute-Assert”模式。

这意味着开发人员可以直接实现测试，而不是解释测试。

与测试联动

BDD的结构有助于验收测试自动化，并支持生成有效的测试用例。

利用工具进行度量

市面上有一些支持BDD的工具，这类工具提供了额外的度量，如测试用例覆盖率或需求满足率。

活文档

自动化实例提供了系统的长期文档，有利于内外部干系人（如监管机构）需求的可追溯性。

支持迭代

场景可以很容易地划分优先级，这支持敏捷项目的迭代、增量性质。

轻量灵活

通过创建轻量级、生动的需求和测试文档，实现文档的灵活性。

直接作为AC

可作为用户故事的验收标准。

关注行为

可用于促进和组织设计讨论，使设计团队专注于系统的特定行为。

BDD的使用限制

重要场景可能会遗漏

一个人只能看到他可以看到的东西，一个人也只能知道他能知道的场景。

虽然我们先前说让BA来通过“假设”问题来识别并补充完整场景，但是很难说是否没有遗漏。

目前我看来这种是没有办法避免的，只能尽量减少。

可以通过与多角色以及同一个角色的多个不同的干系人进行“提问”，以及自己在相关领域的知识及经验积累来尽量减少。

说到这里，真心想要强调一下，作为BA一定要时不时的进行复盘和总结，不要总是犯同样的错误。

我发现我“年轻”的时候就是思考太少了。

多思考对于个人和产品都非常有好处。

成本比较高

如果业务规则非常复杂、场景非常多，那么就很难轻松有效的进行管理和跟踪。

创建的时候就不是一个小工程，如果一旦发生一些迭代优化或者需求变更的需要，对这些BDD进行维护是一个比较大的工程。

而如果不更新，那么BDD就失去了其存在的价值。

如果业务规则非常复杂、场景非常多，那么还是建议上工具吧，至少能帮忙解决一部分的问题，比Word和Excel会好一些。

谁来写BDD？

关于到底是谁写BDD脚本这件事情，我个人觉得是要看情况的。

大部分情况如我上面提到的，PO和BA提供的是自然语言的BDD脚本，而自动化测试工程师会根据要求将其中一部分转换为自动化测试语言的BDD脚本。

而在一些维护类项目或者硬件产品中，在一些成熟度比较高的产品中，可能会是另外的情况。

我在此列出了写BDD的几种可能的角色以及各自的职责，大家可以作为参考

写在最后

如果你对BDD感兴趣，推荐看一本书《实例化需求》。

曾几何时，我觉得BDD是绝对不会取代PRD的。

后来我发现其实BDD可能更多是应用在story层面的，作为AC验收标准的。

这比我们写一大堆的文字进行逻辑判断要高效的多。

而如何进行场景的拆分，我觉得这个和拆Story是一个思路，可以参考满足MECE法则。

我之前给客户做PO辅导的时候，发现大家对于BA或者产品来写BDD这件事情的接受程度不是很高，大家更习惯于写PRD。

其实我想说的是，如果你是用敏捷的框架，你用轻量级的Story，你需要快速迭代，基本上是没有多少时间给你写完整的PRD文档的。

而且写完的文档在迭代更新的时候也会比较费力。

而BDD可以作为story的AC，与敏捷的流程更加适配。

我也和一些开发和测试同学聊过，他们都觉得BDD会比PRD的可读性更强，也利于他们进行代码开发和测试验证工作的开展。

我个人的建议是，保持空杯心态，试试看用BDD来写AC，也许你会有新的发现也说不定呢~

至此，你对于BDD是否有了些更加具体的认识？

分享一下你的想法吧~