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

      1）敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。
      2）敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），可以见我的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，在敏捷测试中，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员
      3）敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审，意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。
      4）敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长（几个月到几年），即使没有自动化测试也是可以应付的，一般来说，回归测试能够获得几周时间，甚至1-2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在1-3天内就有完成整个的验收测试（包括回归测试）。没有自动化，就没有敏捷。

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

      1）敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其它成员（特别是业务人员、产品设计人员等）的紧密协作，建立良好的测试框架（特别是持续集成测试和自动化回归测试的基础设施）以适应需求的变化，更关注被测系统的本身而不是测试文档（如测试计划、测试用例等）。
      2）敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发（TDD）、验收测试驱动开发（ATDD），可以见我的另一篇文章《敏捷测试的思考和新发展》所讨论的。测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的快速变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，在敏捷测试中，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试——一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员
      3）敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试，包括需求和设计的评审；在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审，意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。
      4）敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有绝对的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长（几个月到几年），即使没有自动化测试也是可以应付的，一般来说，回归测试能够获得几周时间，甚至1-2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在1-3天内就有完成整个的验收测试（包括回归测试）。没有自动化，就没有敏捷。