ATDD

什么是ATDD

• 首先，ATDD不是一种测试方法论，而是一种开发方法论。
• UTDD涉及的人员仅仅是开发人员，那么ATDD仅仅涉及测试人员吗？不是，产品、开发、测试都需要参与到ATDD中来。
• 在ATDD活动中团队需要就需求定义出期望的质量标准和验收细则，以明确而且达成共识的验收测试计划（包含一系列测试场景）来驱动产品的代码开发和测试脚本开发。
• ATDD一定是基于测试自动化和持续集成的。

ATDD的基本流程

ATDD的流程

和TDD的 “红-绿-重构” 类似，ATDD的流程也是类似的思路（如上图）。

• 讨论澄清阶段
  • 全组参与的针对需求和方案的讨论
  • 大家产出对需求和方案共同的理解
  • 通过明确验收测试方式澄清我们的实现方案
  • 验收测试方式将被自动化
• 开发阶段
  • 用明确具体的验收测试方式来指导开发工作
  • 验收测试的自动化和特性的开发可以并行开展
  • 全组成员对验收测试的自动化负责，而不仅仅是测试人员
  • 最终，我们的产品实现能让所有的自动化测试通过
• 交付阶段
  • 我们要保证之前迭代所有的自动化验收测试能在新交付上通过
  • 给所有利益相关者演示我们的新特性
  • 收集反馈，讨论改进

ATDD的好处

最好的验证一个研发团队是否对客户需求有统一的理解的方法就是对客户如何验收有统一的理解。
ATDD这样的做法一下子就让我想到了“七个习惯”中的 以终为始 ，我们先澄清细化最终客户的目标，并把自始至终都基于这个目标工作，这不就是以终为始吗？

一般来说，我们认为ATDD的好处有：

• 大家对业务需求的统一理解
• 通过自然语言来描述需求
• 是可以运行的需求或实例
• 是活着的文档

为了更好的把ATDD和UTDD区分开来，你可以尝试记住一句话：

UTDD是为了让你Do things right，但ATDD是为了你Do right things。”

一个方法：实例化需求

Specification by Example

一个列子：

测试就是需求说明，需求说明就是测试

一个工具：Robot framework

Robot framework是一个开源的自动化测试框架，它通过“keyword-driven” 的方式编写测试案例，是一个非常适合用来实践ATDD的工具。
官网：Robot Framework

一个补充：探索性测试

基于抛开了软件系统复杂性的user story而写的验收用例，往往也不可避免在测试覆盖率上会遗漏一些细节上的需求，特别是非功能性的需求。没有人工参与的自动化测试，提高了效率，但也不可避免的阻碍了测试案例的改进，使得杀虫剂效应明显。
所以在引入ATDD和CI/CD后，组织必须也要同时引入 探索性测试 ，不断完善自动化测试的不足。