传统开发模式 VS BDD开发模式

传统开发模式

1. 业务人员告诉业务分析师他想要的新功能。

2. 业务分析师将业务人员的请求写入需求文档，通常为Word格式文档。

3. 开发人员将需求转译为代码和单元测试。

4. 测试人员将Word文档中的需求转译成测试用例，并使用它们来验证新功能是否满足要求。

5. 最后，文档工程师将可工作的软件和代码转译回来，转化为简单的技术文档和功能文档。

 

BDD开发模式

1. 业务人员、开发人员和测试人员与业务分析师协作，讨论业务问题、目标以及实现这些目标所需的潜在功能。通过实例来阐明需求，减少误解。

2. 在开发新功能之前，业务分析师与开发人员和测试人员进行更详细的对话，讨论新功能的关键业务目标和结果，并通过具体的实例来更深入地理解需求。对于比较重要的功能，业务人员可能也会参与讨论。在这次对话之后，团队成员以结构化、符合业务可读性的方式编写关键的实例，这些实例与自然语言非常接近。这些实例既作为功能规约，也作为自动化验收测试的基础。

3. 开发人员和测试人员将这些“可执行规约”转换为自动化验收测试，这些自动化测试将指导开发过程，并确定何时完成该功能。

4. 当自动验收测试通过时，团队就有了确凿的证据证明在第二阶段商定的功能规约已被正确履行。测试人员可能会将这些测试结果作为进行任何手动和探索性测试的起点。

5. 业务人员可以查看测试报告，了解已交付的功能以及它们是否符合预期。自动化测试还充当产品文档，提供了系统如何工作的最新的精确实例。    

 

可以看到，传统开发模式存在多个转译过程，极易造成信息丢失或者理解上的歧义，BDD则大量利用对话和实例来减少信息在转译过程中的丢失。BDD基于业务人员提供的具体实例，以结构化且符合业务可读性的风格来编写规约，以此作为基础，代码、报告和文档中的大部分歧义都被消除了。

 

* 如果你对BDD感兴趣，可扫码关注公众号