时至今日，还讨论这样一个老话题，是否感觉老调重弹？因为两年前（2010年底）时任谷歌中国测试经理的段念先生就写了一篇文章《什么是敏捷软件测试》， 就已经谈到这个话题，“敏捷软件测试更多的是一种理念，而非过程”。在2011年，我自己也写了一篇文章《敏捷测试的思考和新发展》，谈到“在BDD、ATDD和TDD最根本的、共同的思想基础上，构成一个全新的、更完善的敏捷测试框架”。而更早的时候（2010年10月），写了一篇《敏捷测试的方法和实践》，开始的那一小节就在讨论 “什么是敏捷测试”，简单地说，“敏捷测试就是持续地对软件质量问题进行及时地反馈”。不过，篇幅不多、匆匆而过，说得还不够明朗。如果再往前，早在2009年，Lisa Crispin和Janet Gergory就写了一本书《Agile Testing： A practical Guide for testers and Agile Teams》，国内在2010年出了它的中文版本，在第1章就论述了敏捷测试的定义，侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试，对敏捷测试和传统测试的区别进行了分析（虽然作者把传统测试局限于瀑布模型，这显然是不对的），让我们看到一些敏捷测试的特点，如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。

图1 传统测试与敏捷测试

　　这样看来，“敏捷测试（Agile Testing）”就不是一个新概念了，但为什么不少人还是不理解什么敏捷测试呢？现在偶尔还看到一些文章或微博帖子还在讨论什么是敏捷测试，但似乎云里雾里、不知所云，感觉“敏捷测试”在许多人的心目中还是比较模糊。估计是以前的文章，包括我的文章，没有把“敏捷测试”说透，所以有了再写一篇文章的想法，尽量一次把“敏捷测试”这个内涵给大家说清楚。以后，有机会再讨论传统测试团队如何转型、敏捷文化下测试团队如何建设等。

　　首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。那敏捷测试是什么？敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。就像Scrum一样，Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。让我们看看Wikipedia 是如何描述敏捷测试的：

　　它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们还是要回过头来仔细看一下“敏捷宣言”背后所蕴含的12条原则。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先认真阅读以下完整的敏捷宣言，不仅仅是那四句话。

　　1、方法论上的敏捷测试

　　先从敏捷开发这一方法论层次来讨论什么是敏捷测试，即敏捷测试有什么具体特征，或有哪些主要实践，然后再就目前非常热的敏捷具体框架Scrum来讨论Scrum中的敏捷测试（或称为Scrum Testing）。先研究一下敏捷宣言背后所蕴含的12条原则：

　　1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。

　　2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

　　3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。