1、敏捷测试的定义

　　敏捷测试是敏捷的一种，敏捷测试是遵循敏捷宣言进行，把开发作为顾客看待，测试中采用的是敏捷方法论。

　　敏捷测试是遵循敏捷宣言的一种测试实践：

　　●强调从客户的角度，即使用系统的用户的角度，来测试系统；

　　●重点关注持续迭代的测试新开发的功能，而不再强调传统测试过程中严格的测试阶段；

　　●提倡尽早的开始测试，一旦系统某个层面可测，比如提供了模块功能，要开始模块层面的单元测试，同时随着测试深入，持续进行回归测试保证之前测试过内容的正确性。

　　2、敏捷测试中测试人员扮演的角色

　　1）测试是项目的“车头灯”，它告诉大家现在到哪了，正在往哪个方向走。

　　2）测试为项目组提供信息，使得项目组基于可靠的信息作出正确的决定。

　　3）“BUG”是让用户感觉烦恼的东西，测试人员不作出发布的决定。

　　4）测试员不保证质量，整个项目组对质量负责。

　　5）测试不是抓虫子的游戏，它的目的不是纠缠在错误中，而是帮助找到目标。

　　3、敏捷测试的特点

　　传统的测试应该是——可以坐在我们测试部门专用的办公区内，等待产品策划的文档，拿到文档后着手准备用例，并看一下项目的计划，在程序员提交可用版本后对产品进行测试，然后将找到的bug提交bug管理系统，后在产品计划发布之前，拿出几个还未修改的bug说产品还未准备好……然而现在，我们不再和产品团队有空间距离，不再只是看文档写用例，不再只是提交bug，不再只是争论某个bug是否必须修改……敏捷的开发决定了我们必须以敏捷的测试来应对。

　　敏捷测试具有以下几个特点：

　　1）“沟通”成了重要的技能之一

　　敏捷测试更强调人的作用，强调测试人员与开发人员之间的沟通。以往我们总要等到产品的一个正式版本发布，才可以开始测试，否则过多的介入会打乱开发计划。而现在，敏捷测试告诉我们，在产品开发过程中要介入测试。

　　在传统的测试中，当测试人员发现并提交一个bug时，需要写大量的文字来描述bug的环境以及bug的重现步骤。程序员修正bug时，也自信满满的说，该bug已修正。但当测试人员一一复查时，却发现你所认识的那个bug还在，而程序员完全理解错了你所说的bug。这样的事情在以往的测试实践中有很多，而现在，测试人员所需要做的，是与开发人员直接沟通，把问题说清楚，让他能够准确的理解你的意思，甚至包括你对于该bug的分析。接下来一切十分好办了。

　　仅仅是几句话的沟通，能将一个bug在短的时间内修正，这节省了很多时间。这皆得益于比以往更便捷的沟通，同时也大大的提高了开发效率。但这也对测试提出了更高的要求，虽然传统的测试也很强调沟通能力，但现在由于需要更频繁的沟通，测试人员对沟通能力的提高也变得也越来越重要，成为了重要的技能之一。

　　说到这里，其实我们已经能感受到，测试的角色定位已经变了。因为敏捷开发中，要对质量负责的是整个团队，这一目标要求测试人员不再是一个独立的质量监督部门，而是要融入到整个团队中，成为开发中不可分割的一部分。

　　2）调整测试用例的粒度

　　业界通常认为，测试员重要的技能是写用例，通过用例来表达测试思想。我想，即使是到了敏捷时代，这个技能仍然是第一位的。只是，如果你的用例写得过于详细和复杂，那么在团队开始响应变化的时候，你会措手不及了。

　　至于粒度到什么程度才是合适的呢?那要看个人的能力，是否强大到能随时调整一份复杂和详细的用例的程度。一般不推崇十分详细的用例，因为有些很细节的地方，也没有文档可以参考。敏捷的直接的特点是快速，如果设计的用例粒度太细，那是很难开展敏捷测试的。

　　3）更多的测试方法

　　如何开展具有快速特点的敏捷测试呢？单单用一种测试方法是很难开展测试工作的，需要采用多种测试方法。

　　灰盒测试是一种介于黑盒测试和白盒测试之间的测试方法，它设计的用例可以比黑盒测试更简洁，而且随着你对程序框架的理解更加的深入，你对所测的产品会更有把握。当然，传统的黑盒测试是不能抛弃的，因为很多bug都是在你所意料不到的情况下发生的。如何合理的分配灰盒测试和黑盒测试，这还需要在漫长的敏捷测试中慢慢体会。

　　除了简单的灰盒黑盒，测试人员尝试做一下白盒也是很有用处的。虽然程序员也做了白盒测试，但测试人员的测试思路会和程序员有所不同，得到的结果也许会不一样。可以尝试对核心代码进行白盒测试：包括代码的走查，对函数的独立测试，以及使用内存检测工具的检测等等。

　　后还要结合自动化测试方法。由于产品会经常的响应变化，对于某些重要的系统的测试会一次又一次的要重来。若系统简单些还好，若系统是比较复杂，或是比较核心的，如果还是用手动测试，那会很让人头痛了。所以测试人员的自动化测试是很有必要的。为自己容易自动化的系统写一个自动测试脚本，这样，随便他们怎么改动，我们都可以随时的进行回归测试了。

　　4）更多的人参与测试

　　当测试人员已经不再是一个独立的测试部门时，需要进行测试的也不只是测试人员了。程序员要自测，策划也要测试，甚至用户也可以来测试。不同的人可以得到不同的结果，这样才能使我们对产品有全面的把握，才能时刻的知道产品下一步应该怎样“响应变化”。

　　程序员的自测可以减少程序上的bug。策划的测试可以使策划更清楚的看到目前产品的现状，亲自体验自己设计的系统。而用户的测试则可以给我们带来我们的终用户的反馈，这是有价值的信息。