​TDD明白了，ATDD测试到底是什么？

随着敏捷开发的蓬勃发展、遍地开花，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

出　　处：微信公众号：自动化软件测试平台

版权说明：欢迎转载，但必须注明出处，并在文章页面明显位置给出文章链接