早在年，LisaCrispin和JanetGergory就写了一本书《AgileTesting：ApracticalGuidefortestersandAgileTeams》，国内在年出了它的中文版本，在第1章就论述了敏捷测试的定义，侧重从测试的敏捷形式和“敏捷测试”的实践等来彰显敏捷测试，对敏捷测试和传统测试的区别进行了分析（虽然作者把传统测试局限于瀑布模型，这显然是不对的），让我们看到一些敏捷测试的特点，如图1所示。但作者也承认“敏捷测试对不同的人意味着不同的含义”。
图1传统测试与敏捷测试
这样看来，“敏捷测试（AgileTesting）”就不是一个新概念了，但为什么不少人还是不理解什么敏捷测试呢？
AD：
Testin核心敏捷测试方案免费领取
点击页面左下角阅读原文领取
现在偶尔还看到一些文章或微博帖子还在讨论什么是敏捷测试，但似乎云里雾里、不知所云，感觉“敏捷测试”在许多人的心目中还是比较模糊。
估计是以前的文章，包括我的文章，没有把“敏捷测试”说透，所以有了再写一篇文章的想法，尽量一次把“敏捷测试”这个内涵给大家说清楚。
以后，有机会再讨论传统测试团队如何转型、敏捷文化下测试团队如何建设等。
首先，可以明确的是，敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。
因为在敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratorytest），也可以采用基于脚本的测试（scriptedtest）。
那敏捷测试是什么？敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。
就像Scrum一样，Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。
简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。
让我们看看Wikipedia是如何描述敏捷测试的：
Agiletestingisasoftwaretestingpracticethatfollowstheprinciplesofagilesoftwaredevelopment.Agiletestinginvolvesallmembersofacross-functionalagileteam,withspecialexpertisecontributedbytesters,toensuredeliveringthebusinessvaluedesiredbythecustomeratfrequentintervals,workingatasustainablepace.
它强调敏捷测试是遵守敏捷开发方法原则之下的软件测试实践，由跨功能敏捷团队的所有人员参与（包括测试人员以其专业特长的特殊贡献）以保证持续的、快速的业务价值交付。所以要理解敏捷测试，我们还是要回过头来仔细看一下“敏捷宣言”背后所蕴含的12条原则。
我相信，大家都已熟悉敏捷宣言，如果不熟悉，可以先认真阅读以下完整的敏捷宣言，不仅仅是那四句话。
1、方法论上的敏捷测试
先从敏捷开发这一方法论层次来讨论什么是敏捷测试，即敏捷测试有什么具体特征，或有哪些主要实践，然后再就目前非常热的敏捷具体框架Scrum来讨论Scrum中的敏捷测试（或称为ScrumTesting）。先研究一下敏捷宣言背后所蕴含的12条原则：
1）我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2）欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3）经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4）业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5）激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6）不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7）可工作的软件是进度的首要度量标准。
8）敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9）坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10）以简洁为本，它是极力减少不必要工作量的艺术。
11）最好的架构、需求和设计出自自组织团队。
12）团队定期地反思如何能提高成效，并依此调整自身的举止表现。
这12条原则中没有一条直接谈到测试，那是否说明没有敏捷测试呢？有开发就有测试，只是原来参加敏捷宣言的17人，基本是清一色程序员，没有在原则中单独阐述一下测试的原则。但其中一些原则和测试的关联性很强，例如：
1）软件测试如何支撑或协助“持续不断地及早交付有价值的软件”？如何在非常有限的时间内进行充分的测试？这就是我们经常在敏捷测试中强调的“自动化测试”，如果没有自动化测试，就没有敏捷，就不能持续不断地及早交付有价值的软件，而且还要“使客户满意”。
2）“欣然面对需求变化，即使在开发后期也一样”和传统的开发原则是不同的，传统的开发希望有严格的需求变更控制，越到后期控制越严。而敏捷开发拥抱变化，那么测试如何适应这种变化？如何快速地完成回归测试？这可能要依赖于开发做好单元测试，或全员参与测试，以及全面支持系统级的、端到端的回归测试的自动化测试执行。
3）传统的开发也要求“业务人员和开发人员必须相互合作”，但存在一定的阶段性，例如前期需求评审、期间产品走查（productwalk-through）、后期验收测试等要求有紧密的沟通与协作。但敏捷开发更强调“项目中的每一天都不例外”，在这样的原则下，如何去做敏捷测试？这样可以减少测试文档，刚开始也没必要把测试计划写得很详细，而是写一页纸测试计划就可以，将来再持续的完善和调整。
4）“可工作的软件是进度的首要度量标准”，不再是测试计划完成情况、完成的测试用例数目、测试脚本量等，而是如何及时验证每天完成的功能特性。开发的工作量也不能按代码行来衡量，而是看多少个具体的用户故事（功能特性）被实现了（done）。某个开发说已完成了某个用户故事，要么是通过他自己的验证，要么是通过测试人员的验证，谁做的测试不重要，关键是要有准备好的测试，随时验证已完成的工作。
5）“坚持不懈地追求技术卓越和良好设计”，一方面要求测试的技术要不断提高，在处理每个测试任务时，都应该找到最有效的办法；另方面，在前期要更多地参与设计评审，及时发现设计的问题。只有良好的设计，才能更好地支持系统的功能扩充和不断的重构。
基于这些原则，我们就可以概括一下敏捷测试的一些特点：
1）敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更