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
出 处：微信"大众号：自动化软件测试平台
版权解释：欢迎转载，但必须注明出处，并在文章页面明显位置给出文章链接
