对ATDD的理解

对ATDD的理解

ATDD：英文全称是：Acceptance Test Driven Development，也就是常常听到的 验收测试驱动开发。

那么，究竟什么才是ATDD呢？首先，我们看看维基百科上对ATDD的解释。

Acceptance Test-Driven Development (ATDD) is a development methodology based on communication between the business customers, the developers, and the testers.^[1] ATDD encompasses many of the same practices as Specification by Example,^[2][3] Behavior Driven Development (BDD),^[4] Example-Driven Development (EDD),^[5] and Story Test-Driven Development (SDD).^[6] All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language.

ATDD is closely related to Test-Driven Development[TDD].^[7] It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding.

大致意思就是，ATDD是一种开发方法论，它是在交流的基础上进行的。通常由客户代表、市场人员，开发、测试等一起进行对需求进行交流，沟通，分解，例举和确认，以便所有角色对需求的理解都是一致的。SbE、BDD等可以帮助开发人员和测试人员更好的理解需求，从而实现满足用户需要的产品。

下图是一个很典型的ATDD的流程图。从图中可以看到，1）首先是一个讨论过程，目的就是将用户需求理解清楚，理解一致，避免后期因理解不一致而做出不满足要求的产品。 2） Distill其实是一个提取的过程，也就是将需求分解成开发人员和测试人员都能理解，切认可的最小单元。 这里为了需求的理解一直，引入了一套满足Gherkins语法的需求描述语言，通过这种满足Gherkins语法的GWT语句需求描述语言，可以让需求理解上更加一致。3）开发和后面的Demo其实就不用说太多了。开发根据GWT需求描述语言进行开发设计，测试根据GWT需求描述语言来写验收测试用例。验证的时候直接执行GWT需求，即：需求可执行。从而验证需求是否被实现。

为了更好地理解ATDD开发过程，以下从其他地方引用。

典型的ATDD开发过程是：

   Step 1：产品负责人向测试人员和开发人员讲解用户故事，澄清他们提出的问题；

   Step 2：
    a. 测试人员列出验收该功能所需要验证的所有测试场景，每个测试场景通常是概要，清晰的一句话；
    b. 同时，开发人员查找和分析现有的相关设计，代码和单元测试，明确开发策略；

   Step3：测试人员和开发人员共同评审和调整测试场景列表，达成共识；必要时寻求产品负责人的参与和确认；并且明确那些场景应该有单元测试；

   Step 4：
    a.基于通过评审和认可的测试场景列表，测试人员开始为每个测试场景创建详细的验收测试用例，准备测试脚本和测试数据；
    b. 同时，基于同样的的测试场景列表，开发人员开始添加单元测试用例，并以TDD方式驱动业务实现；

   Step5：在开发人员将完成的功能部署并交付测试人员执行测试之前，进行代码评审和根据测试场景列表快速验证自己完成的功能，甚至邀请测试人员来观摩；

   Step 6：一旦完成的功能通过构建并部署到测试环境，测试人员立刻开始执行测试脚本；

   Step7：任何测试人员的测试中发现的缺陷都要纪录到工具，并跟踪，立刻反馈给开发人员解决，或进行其它恰当处理；

   Step 8：最后，在迭代结束，团队成员向产品负责人和客户演示完成的功能。具体演示那些场景，可以在Step 3的阶段就确定。