随着敏捷开发的蓬勃发展、遍地开花，TDD（Test Drive Development测试驱动开发）的概念已经深入软件研发从业者的心中。
TDD讲究的是：“测试在先、编码在后”。有别于以往的“先编码、后测试”的开发过程，而是在编程之前，先写测试脚本或设计测试用例。
“测试先行”，使得开发人员对所做的设计或所写的代码有足够的信心，同时也有勇气进行设计或代码的快速重构，有利于快速迭代、持续交付。
严格来说，TDD是一种开发实践。
从软件开发角度来看，TDD是很棒的！
然而，把需求分析整理，软件开发，到产品化，再到用户使用，这样整个流程来看，单纯的TDD还是有一定瑕疵的。
TDD只涉及到Developer（开发者），只能算是开发工程师个人工作方式的改变。而现代软件开发，往往都是“产品经理（或业务）、测试人员（QA）、开发人员”三者合作的成果，如果开发人员对业务需求理解的不正确，那么写出的测试用例也是错的，这个问题是TDD解决不了的。
在不脱离敏捷开发的大前提下：业务层次，也可以采用类似TDD方法论。
换言之，需求分析时就确定需求（如：用户故事）的验收标准。毕竟软件最终是要给用户使用的，要满足用户需求，解决用户的痛点。否则就会变成程序员的自high！
上面的业务层次的敏捷测试，升华到方法论的高度，就是验收测试驱动开发（Acceptance Test Driven Development，ATDD）。
ATDD的执行逻辑，如下图所示：
ATDD是一种在编码开始之前将客户带入测试设计过程的技术实践。
同时，ATDD也是一个协作实践：用户，测试人员和开发人员，共同定义了自动验收标准。
ATDD有助于确保所有项目成员准确理解需要完成和实施的内容。
如果系统未通过测试可提供快速反馈，说明未满足要求。
验收测试以业务领域术语进行指定。每个功能都必须提供真实且可衡量的业务价值，事实上。
ATDD这样的做法，其实对应着《成功人士的“七个习惯”》之一的“以终为始”。
产品经理、研发人员、测试人员，三个角色的人首先坐到一起，澄清细化最终客户的目标，并把自始至终都基于这个目标工作，这不就是以终为始吗？
ATDD带来的好处也显而易见
• 大家对业务需求的统一理解
• 通过自然语言来描述需求
• 是可以运行的需求或实例
• 是活着的文档
说了这么多，相信大家已经可以明白ATDD绝对不是TDD多了一个“A”。
还没懂？一句话对比法来说明区别：
TDD的目的是：Do the right development；
ATDD的目的是：Do the development right！
具体到测试人员的工作实践中，笔者推荐Python和JAVA的两个框架，基本可以满足工作需求了。
Python背景的测试人员，推荐使用Robot Framework。
官网：https://robotframework.org/
RF的 “keyword-driven” 方式，用来编写测试案例，是一个非常适合用来实践ATDD的工具。
JAVA背景的测试人员，推荐使用FitNess框架。
官网：www.fitnesse.org
TDD，最终还是程序员自己的事情；ATDD，让测试人员更多地参与到产品、研发、交付中。
是时候拥抱ATDD了！
作 者：Testfan Arthur
出 处：微信公众号：自动化软件测试平台
版权说明：欢迎转载，但必须注明出处，并在文章页面明显位置给出文章链接