时至今日，还讨论这样一个老话题，是否感觉老调重弹？因为两年前（2010年底）时任谷歌中国测试经理的段念先生就 写了一篇文章《什么是敏捷软件测试》（刊登在InfoQ网站上[1]）， 就已经谈到这个话题，“敏捷软件测试更多的是一种 理念，而非过程”。在2011年，我自己也写了一篇文章《敏捷测试的思考和新发展》，刊登在《程序员》杂志上，谈到“在 BDD、ATDD和TDD最根本的、共同的思想基础上，构成一个全新的、更完善的敏捷测试框架”[2]。而更早的时候（2010年10 月），写了一篇《敏捷测试的方法和实践》（也刊登在《程序员》杂志上），开始的那一小节就在讨论 “什么是敏捷测试 ”，简单地说，“敏捷测试就是持续地对软件质量问题进行及时地反馈”[3]。不过，篇幅不多、匆匆而过，说得还不够明 朗。如果再往前，早在2009年，Lisa Crispin和Janet Gergory就写了一本书《Agile Testing: A practical Guide for testers and Agile Teams》, 国内在2010年出了它的中文版本[4]，在第1章就论述了敏捷测试的定义，侧重从测试的敏捷 形式和“敏捷测试”的实践等来彰显敏捷测试，对敏捷测试和传统测试的区别进行了分析（虽然作者把传统测试局限于瀑布 模型，这显然是不对的），让我们看到一些敏捷测试的特点，如图1所示。但作者也承认“敏捷测试对不同的人意味着不同 的含义”。
开发简介">
图1 传统测试与敏捷测试 [4]
这样看来，“敏捷测试（Agile Testing）”就不是一个新概念了，但为什 么不少人还是不理解什么敏捷测试呢？现在偶尔还看到一些文章或微博帖子还在讨论什么是敏捷测试，但似乎云里雾里、不 知所云，感觉“敏捷测试”在许多人的心目中还是比较模糊。估计是以前的文章，包括我的文章，没有把“敏捷测试”说透 ，所以有了再写一篇文章的想法，尽量一次把“敏捷测试”这个内涵给大家说清楚。以后，有机会再讨论传统测试团队如何 转型、敏捷文化下测试团队如何建设等。
首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法 等），也不是一种方式（如探索式测试）。因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷 中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。那敏捷测试是什么？敏 捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。就像 Scrum一样，Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。简单地说，敏捷测试就是顺应敏捷 开发方法、力求达到质量和效率平衡的一系列的测试实践。让我们看看Wikipedia 是如何描述敏捷测试的：
Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all members of a cross-functional agile team, with special expertise contributed by testers, to ensure delivering the business value desired by the customer at frequent intervals, working at a sustainable pace.
它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其 专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们还是要回过头来仔细看一下“敏捷 宣言”背后所蕴含的12条原则。我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先认真阅读以下完整的敏捷宣言，不仅 仅是那四句话。
1. 方法论上的敏捷测试
先从敏捷开发这一方法论层次来讨论什么是敏捷测试，即敏捷测试 有什么具体特征，或有哪些主要实践，然后再就目前非常热的敏捷具体框架Scrum来讨论Scrum中的敏捷测试（或称为Scrum Testing）。先研究一下敏捷宣言背后所蕴含的12条原则[5]：
1) 我们最重要的目标，是通过持续不断地及早交付有 价值的软件使客户满意。
2) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化 。
3) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4) 业务人员和开发人员 必须相互合作，项目中的每一天都不例外。
5) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援， 辅以信任，从而达成目标。
6) 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7) 可 工作的软件是进度的首要度量标准。
8) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调 稳定延续。
9) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10) 以简洁为本，它是极力减少 不必要工作量的艺术。
11) 最好的架构、需求和设计出自自组织团队。
12) 团队定期地反思如何能提高成效 ，并依此调整自身的举止表现。