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。策划的测试可以使策划更清楚的看到目前产品的现状,亲自体验自己设计的系统。而用户的测试则可以给我们带来我们的终用户的反馈,这是有价值的信息。