Robotframework框架下的BDD（ATDD），比 Behave框架更简洁方便的应用（1/2）

1. 什么是BDD

BDD全称Behavior Driven Development，译作"行为驱动开发"，是基于TDD (Test Driven Development 测试驱动开发)的软件开发过程和方法。

BDD可以让项目成员（甚至是不懂编程的）使用自然语言来描述系统功能和场景，从而根据这些描述步骤进行系统自动化的测试。

2. 常用BDD框架介绍

目前常用的BDD测试框架有Ruby中的Cucumber，Python中的Behave、Lettuce及Freshen等。

 

以上内容摘自：http://lovesoo.org/python-bdd-exploration-of-the-automated-testing-framework.html 

BDD，Gherkin语法以及Behave框架实施等相关内容介绍本文不详述，有兴趣的小伙伴可自行搜索相关内容。

---

此处需要重点说明的有两点：

1. TDD -> BDD -> ATDD（AcceptanceTest Driven Development）是将仅限于开发人员所使用的技术，延展至多角色（产品 / 业务验收、开发、测试）协作互补应用，需求全流程覆盖。
   由于其对编程的技能要求逐级递减，所以若已可支持了ATDD的话，业务（验收）人员亦可以直接进入协同体系，方便地使用。
2. 这里的 “需求全流程覆盖” 有两层含义：一是设计的验收用例对需求的覆盖；二是编写的自动化脚本对验收用例的覆盖。
   前者通常由产品/业务验收人员完成。即直接细化了代码模块们需要实现的业务需求，也间接地促进了架构设计的改善。换句话说，对产品/业务验收人员而言，完成各业务模块验收标准说明，对开发人员而言，间接地帮助了 Driven Development；
   后者可以是测试（开发）人员或者是开发人员来完成，也就是目标明确的将其转化为自动化脚本，拓展对系统全功能的自动化回归覆盖率。

BDD中的Gherkin语法比较简单，易理解，是为不懂编程的业务验收人员可用自然语言书写验收用例而生。

在Behave框架实现体系下，由于由业务验收人员用自然语言描述的每个（验收）业务步骤，其自动化转化层是直接由python代码块来实现，这就使得业务人员的工作（验收用例的设计）与测试（开发）人员的工作（代码实现）之间耦合度很高，所以在实际实施当中，除非两人有着极高的同步协同工作的意愿和可能，否则坚持实施下去的可能性极低，进而可能就退化成是测试（开发）人员一方的工作，也就失去了原不同角色各自发挥自己所擅长的协作的价值。

而许多人可能没有注意到 Robotframework 框架在借鉴了Cucumber（Behave是其python的实现）的设计思路之后也加入了对 BDD 核心语法的支持（Given/When/Then/And/Or），加上其原本就很成熟的关键字（库），模板用例，简单的循环及条件语法的支撑体系，使得许多编码甚至可以不下沉到 python 代码级的解析，也就让业务人员在设计验收用例时更加自由，也与测试（开发）人员的工作更彻底地解耦，两角色可异步的并行工作。

下面以一个简单的User Story场景为例，比方说 “CSDN网站允许用户登录后台，浏览到自己的文章”，说一下具体的实施方式：

1. 产品 / 业务验收人员：
针对上述的 User Story ，编写了一条如下的验收用例

2. 测试人员或者也可以还是产品 / 业务验收人员：
针对上述用例中的描述，将对应的三段关键词翻译成如下编码

参数中的测试数据以 yaml 的形式存储，并在 Test Case的 Test 级引入

此即完成了验收用例以及对验收用例的自动化编码过程。

该案例中甚至没有加入需要通过 python 代码来解析的自定义关键字，只使用robotframework中既有的 selenium库关键字 + 测试数据的配置文件即已足够完成全部工作