敏捷测试是什么

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

1)敏捷测试一定是敏捷开发方法的一部分，应符合敏捷测试宣言的思想，也遵守上面所列的敏捷开发的原则，强调测试人员的个人技能，始终保持与客户/用户、其它成员(特别是业务人员、产品设计人员等)的紧密协作，建立良好的测试框架(特别是持续集成测试和自动化回归测试的基础设施)以适应需求的变化，更关注被测系统的本身而不是测试文档(如测试计划、测试用例等)。

2)敏捷测试具有鲜明的敏捷开发的特征，如测试驱动开发(TDD)、验收测试驱动开发(ATDD)，测试驱动开发的思想是敏捷测试的核心，或者说，单元测试是敏捷测试的基础，如果没有足够的单元测试就无法应付将来需求的变化、也无法实现持续的交付。这也说明，在敏捷测试中，开发人员承担更多的测试，这也就是我们说的，在敏捷测试中，是整个团队的共同努力。在敏捷测试中，可以没有专职的测试人员，每个人都可以主动去取设计任务、代码任务做，也可以去拿测试任务来做。在敏捷测试中，也可以像开发人员的结对编程那样，实践结对测试，一个测试人员对应一个开发人员、或一个测试人员对应另一个测试人员

3)敏捷测试无处不在、无时不在。在传统测试里也提倡尽早测试，包括需求和设计的评审;在传统测试里也提倡全过程测试。但在传统测试里阶段性特征相对突出一些，例如，需求评审，意味着先让产品人员去写需求，但需求文档写好之后，测试人员再参加评审。而在敏捷测试里，团队每一天都在一起工作，一起讨论需求、一起评审需求。在敏捷测试中，这种持续性更为显著一些。

4)敏捷测试是基于自动化测试的，自动化测试在敏捷测试中占有的主导地位。在传统测试中也提倡自动化测试，但由于传统开发的周期比较长(几个月到几年)，即使没有自动化测试也是可以应付的，一般来说，回归测试能够获得几周时间，甚至1-2个月的时间。而敏捷测试的持续性迫切要求测试的高度自动化，在1-3天内就有完成整个的验收测试(包括回归测试)。没有自动化，就没有敏捷。