2010年为《程序员》杂志写了一篇《敏捷测试的方法和实践》，我们可以回过头来，看看过去的一年，敏捷测试发生了哪些变化。首先，我做了一个实验，分别打开2010年和2011年的“STAREAST Conference at-a-Glance”，输入Agile，2010年显示10个结果，而2011年显示17个结果，有一个很大的增长，说明敏捷测试越来越引起大家的关注。这只是一个表面的现象，我们还需要真正了解发生了哪些实质性的变化。

举一个例子，《敏捷测试：测试人员和测试团队的实践指南》的作者Lisa Crispin在StarEast 2011上有一个演讲??Agile Testing: After the First Year， What’s Next? 其中提到，我们从传统开发方法转向敏捷方法，由于开发人员掌握了测试驱动开发（TDD，Test Driven Development），而测试人员部分地实现了验收测试和回归测试的自动化，所以我们活下来了，但我们在接下来深入实施敏捷测试时，还会面临新的挑战，甚至要克服更大的困难。当测试人员有了一年的经验，并拥有了敏捷方法的价值观、原则和实践之后，我们还不得不考虑如何不断改进持续的发布、如何有效地管理技术债务、如何对客户的需求有更好的理解，这要求我们掌握更深的敏捷测试技术，例如将“精益（Lean）方法”用于改进敏捷测试的绩效，以及重构自动化测试的设计或脚本以提高投入产出比。

TDD 向ATDD、BDD转化？

以前人们谈到敏捷方法，会谈到TDD或UTDD（Unit TDD），但是究竟有多少个公司在采用TDD方法来写代码？而在采用TDD开发方法的公司中，又有多少程序员在全面使用TDD方法呢？TDD是一个纠结的问题。一方面，TDD的确是一个好东西，先写测试用例、后写代码，保证程序员第一次把代码写对，也彻底解决了代码的可测试性问题，在代码层次上把缺陷的预防做到淋漓尽致。另一方面，多数项目很紧张，不可能给程序员足够时间去实施TDD，程序员对实现有极大兴趣，而对测试缺乏兴趣，多数程序员也不愿意或不会主动去做TDD。这样，TDD实践还存在较大困难，有比较多的争议。我看到一位作者写道：组里头TDD说了3年，据我所知，看完两本TDD名著，并坚持写单元测试的人只有我一个（我组里有开发人员15名）。

图1 TDD和ATDD之间的关系为了解决TDD实施不力，在过去一年，越来越多的人关注ATDD，即验收测试驱动开发（Acceptance Test Driven Development）。从2003年开始，人们逐渐实践TDD，而ATDD 是在2007年Lasse Koskela写了一本书《测试驱动：Java开发人员的TDD和ATDD》 ，才开始引起大家的更多关注。从那时算起也有四年了，但在国内，则是近一两年的事。当然，我们可以将TDD和ATDD结合起来使用，形成一种混合的方法模型。TDD和ATDD之间的关系，可以用图1来描述。

接着，BDD（行为驱动开发，Behavior Driven Development）也开始大行其道，那BDD是不是“做得比较好的TDD”呢？概念越来越多，概念的界限难以确定，BDD可以看成ATDD的延伸，只是BDD更强调用户的视角、用户的行为，为ATDD注入了“Given，When，Then”这样特定的需求描述语言。2009年，BDD创始人在伦敦发表的“敏捷规格、BDD和极限测试交流”中，对BDD给出了如下定义：

BDD是第二代的、由外及内的、基于拉动的（pull）、多方利益相关者的（stakeholder）、多尺度的、高度自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。