摘抄自：http://www.infoq.com/cn/articles/agile-test?p13nId=9108303b-9265-4535-8851-bcde46cf9a2d&p13nType=content
敏捷软件测试更多的是一种理念，而非过程。
BDD行为驱动开发
ATDD验收测试驱动开发
TDD测试驱动开发
敏捷测试就是持续地对软件质量问题进行及时地反馈。
传统测试团队如何转型、敏捷文化下测试团队如何建设。
敏捷测试既不是一种方法（如黑盒方法、白盒方法等），也不是一种方式（如探索式测试）。
敏捷测试中可以采用已有的各种方法，包括白盒方法、黑盒方法；在敏捷中也可以采用探索式测试（exploratory test），也可以采用基于脚本的测试（scripted test）。
敏捷测试应该是一套解决方案、一类测试操作与管理的框架、一组实践或由一定顺序的测试活动构成的特定的测试流程。
Scrum可以理解为敏捷方法的具体实现的框架、一组实践或具体的解决方案。
简单地说，敏捷测试就是顺应敏捷开发方法、力求达到质量和效率平衡的一系列的测试实践。
敏捷宣言（12条原则）
1) 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2) 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
3) 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4) 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5) 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6) 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
7) 可工作的软件是进度的首要度量标准。
8) 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9) 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10) 以简洁为本，它是极力减少不必要工作量的艺术。
11) 最好的架构、需求和设计出自自组织团队。
12) 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
敏捷测试的一些特点：
1) 敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。
2) 敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，在敏捷测试中，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员。
3) 敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审，意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。
Scrum的敏捷测试
1) Product Backlog （需求定义阶段），在定义用户需求时测试要做什么？测试需要考虑客户的价值大小（优先级）、工作量基本估算之外，需要认真研究与产品相关的用户的行为模式（如BDD），产品的质量需求，哪些质量特性是我们需要考虑的？有哪些竞争产品？这些竞争产品有什么特点（优点、缺点等）？
2) Sprint Backlog（阶段性任务划分和安排），这时候需要明确具体要实现的功能特性和任务，作为测试，这时候要特别关注“Definition of Done”，即每项任务结束的要求——即任务完成的验收标准，特别是功能特性的设计和代码实现的验收标准。ATDD的关键一步也体现在这里，在设计、写代码之前，就要将验收标准确定下来。一方面符合测试驱动开发思想，第一次就要把事情做对，预防缺陷；另方面持续测试和验收测试的依据也清楚了，可以快速做出测试通过与否的判断。
3) 在每个迭代（Sprint）实施阶段，主要完成Sprint Backlog所定义的任务，这时除了TDD或单元测试之外，应该进行持续集成测试或通常说的BVT（Build Verification Test）。而且开发人员在设计、写代码时都会认真考虑每一组件或每一代码块都具有可测试性，因为测试任务可能由他们自己来完成。如果有专职的测试人员角色，一方面可以完善单元测试、集成测试框架，协助开发人员进行单元测试；另方面可以按照针对新实现的功能特性进行更多的探索式测试，同时开发验收测试的脚本。如果没有专职的测试人员角色，这些事情也是要完成，只是由整个团队共同完成。虽没有工种的分工，但也存在任务的分工。
4) 验收测试可以由自动化测试工具完成，但一般情况下，不可能做到百分之百的自动化测试。例如易用性测试就很难由工具完成。即使对性能测试，是由工具完成，但还需要人来设计测试场景，包括关键业务选择、负载模式等。敏捷的验收测试，和传统的验收测试不同，侧重对“Definition of Done”的验证，但基本的思想和传统开发是一致的，任何没有经过验证的产品特性是不能直接发布出去的。
敏捷测试就是符合敏捷宣言思想，遵守敏捷开发原则，在敏捷开发环境下能够很好地和其整体开发流程融合的一系列的测试实践，这些实践具有鲜明的敏捷开发的特征，如TDD、ATDD、结对编程、持续测试等。
敏捷测试和传统测试的区别
1) 传统测试更强调测试的独立性，将“开发人员”和“测试人员”角色分得比较清楚。而敏捷测试可以有专职的测试人员，也可以是全民测试，即在敏捷测试中，可以没有“测试人员”角色，强调整个团队对测试负责。
2) 传统测试更具有阶段性，从需求评审、设计评审、单元测试到集成测试、系统测试等，从测试计划、测试设计再到测试执行、测试报告等，但敏捷测试更强调持续测试、持续的质量反馈，阶段性比较模糊。
3) 传统测试强调测试的计划性，认为没有良好的测试计划和不按计划执行，测试就难以控制和管理，而敏捷测试更强调测试的速度和适应性，侧重计划的不断调整以适应需求的变化。
4) 传统测试强调测试是由“验证”和“确认”两种活动构成的，而敏捷测试没有这种区分，始终以用户需求为中心，每时每刻不离用户需求，将验证和确认统一起来。
5) 传统测试强调任何发现的缺陷要记录下来，以便进行缺陷根本原因分析，达到缺陷预防的目的，并强调缺陷跟踪和处理的流程，区分测试人员和开发人员的各自不同的责任。而敏捷测试强调面对面的沟通、协作，强调团队的责任，不太关注对缺陷的记录与跟踪。
6) 传统测试更关注缺陷，围绕缺陷开展一系列的活动，如缺陷跟踪、缺陷度量、缺陷分析、缺陷报告质量检查等，而敏捷测试更关注产品本身，关注可以交付的客户价值。在快速交付的敏捷开发模式下，缺陷修复的成本很低。
7) 传统测试鼓励自动化测试，但自动化测试的成功与否对测试没有致命的影响，但敏捷测试的基础就是自动化测试，敏捷测试是具有良好的自动化测试框架支撑的快速测试。