敏捷测试之实践篇

发表于:2012-07-31来源:新浪博客作者:淘宝北京测试沙龙 标签:敏捷测试
最近一直在想敏捷测试如何实施的事情,敏捷测试在敏捷开发中贯穿始末,涉及到了多种角色的参与:客户、开发、设计、专职测试等等,每个角色承担着不同的测试任务,客户与设计可以进行验证需求实现的测试,而开发进行单元测试,专职测试人员进行详细测试。

  最近一直在想敏捷测试如何实施的事情,敏捷测试在敏捷开发中贯穿始末,涉及到了多种角色的参与:客户、开发、设计、专职测试等等,每个角色承担着不同的测试任务,客户与设计可以进行验证需求实现的测试,而开发进行单元测试,专职测试人员进行详细测试。

  我们这里主要是来谈谈专职测试人员如何开展敏捷测试,其实这个问题也是很多软件公司在研究的问题,我们公司也在摸索之中,今天就来介绍一下目前的一些情况。

  首先介绍我们公司的情况,我们自己开发产品,大致主要有二条产品线,一条用敏捷方式,另外一条还是用传统的瀑布方式,今天当然是介绍敏捷那条产品线。

  在敏捷中,测试是从头到尾一直参与的,而对于专职测试人员该从何时开始介入测试呢?各个公司都有自己的想法,对于我们公司而言,当一个功能已经设计好并且决定在这个迭代周期中开发时,测试人员就应该开始介入了。

  怎么介入呢?

  1、先从设计文档着手,参考客户需求看看设计文档是否已经实现客户的要求,对有疑问的地方与设计人员沟通清楚。当搞清楚整个设计思路以后,用脑中已经存在着的这个概念功能来写测试用例

  这个测试用例需要共享给设计人员与开发,特别是给开发人员,因为他们开发的时候就能参照到这些测试点,避免出现未考虑到的地方。

  2、当开发人员开发完成后,测试人员开始测试前或者测试中,需要进行讨论会,讨论什么呢,讨论这个功能的测试覆盖点。之前测试用例已经写完了,但是这个测试用例是基于一个想象中的功能的,实际的功能怎么样子,谁都不知道。而现在实际功能做出来了,对于一个测试人员而言,就能得到基本的测试点了。而开讨论会的目的就是尽可能全的把测试点覆盖,毕竟一个人的思维总是有局限性的,众人拾柴火焰高。

  不过,在敏捷中,功能是不定时做完的,可能今天做完2个,明天又做完3个,后天可能一个都没有,所以这种讨论会不是固定间隔的,一般情况下,累积几个功能以后开一个讨论会。

  开讨论会之前必须做好准备工作,也就是参与者需要提前看过这个会议中需要讨论的功能,可以会前给大家一个小时或者半个小时研究一下。而在会议中,功能的实际测试者需要将大家对于这个功能的讨论测试点记下来,之后更新之前写好的测试用例。

  通过这个讨论会的方式,可以有效地提高测试覆盖面,从而提高产品质量。

  当一个功能开发完成以后,测试人员就可以开始按照设计完成的测试用例来进行测试了。在测试过程中,我们也需要注意很多地方:

  1、首先,虽然测试可以根据测试用例来测,但是一个产品如果需要覆盖很多环境,比如数据库,浏览器,操作系统等,你要全部覆盖到,我相信几个Sprint都没法测完,所以怎么解决的呢?我们是按照迭代测试的方式来解决,简单而言,就是把一个功能的测试分成几轮,第一轮可能在SQL+IE+Win7上测,第二轮呢,则在Oracle+Firefox+W2008上测,第三轮。。。。。。这个方法相对于我们现在的人力资源来说比较合适,因为理论上你要测试全的话,测试的组合个数就是各个环境个数乘在一起,DB(SQL+Oracle+Access)×浏览器(IE+Firefox+Chrome)×操作系统(Win7+W2008+W2003)=27,这个是穷尽测试,的确可以测得很全,但是耗费的资源太多,一般都不太可能采用。我们实际测的时候,只需要考虑三个组合: SQL+IE+Win7,Oracle+Firefox+W2008, Access+Chrome+W2003,这种方式有个好处就是既覆盖了所有测试点,又兼顾了时间与人力资源。

  2、既然只有三个组合,那为什么还要分成不同的轮次测同一个功能呢?这个里是很有考虑的,首先,我们测试第一轮的时候,必然会发现Bug,开发修Bug可能会导致其他Bug产生,这些需要我们再做回归测试;第二,敏捷欢迎变更,功能的变更是家常便饭,所以一旦一个已经做完的功能发生变更,就需要我们重新测试过;第三,对于一个功能的测试,我们知道每个人总是有思维定式,如果能有不同人来测试同一个功能,可能会发现很多不一样的Bug。基于这些方面的考虑,我们设计了一个功能需要经过起码三轮的测试,第一轮是最主要的测试,测试完毕这个功能就应该是基本可用了,后面两轮属于回归测试,确保修复Bug和做过变更过的功能依然可靠,并且用不同人的角度来测试同一个功能。

  3、分成三轮,其实还有另外一个也很重要的考虑,由于是敏捷方式,所以对于时间的把握很重要,我们希望每个Sprint都能产生一个可用的产品,可以让客户来体验新做的功能,而测试往往是个拦路虎,因为既然要测,我们就像测得仔细,覆盖很多地方,那这个就需要时间,时间是敏捷的敌人,所以我们就在想,既要能快速得到Build,让客户去看,又要保证质量,只能采用分步的方式来做,先在最常用的环境里进行测试,保证基本功能正常,可以给客户评估测试,然后接下来再通过几轮测试保证这个功能的质量。

  采用了这种方式来进行敏捷测试,其实给整个测试团队带来了很大的压力,我们需要更快的反应速度,更高的责任感,更强的掌控能力,一旦某一环失控,之后都是一个连环失控的局面,比如这个Sprint有功能来不及测完,下一个Sprint已经开始,新的功能又开始过来,你得先测完上个Sprint的,因为有客户等着看,但是这个Sprint又在大量累计功能,最后越堆越多,而且在测试理论上,Bug如果在早期发现,修复成本最低,一旦早期没有发现,之后又在Bug的基础上做了其他功能,最后导致了连环Bug,修复成本会高得离谱。所以如果更高的要求能带来产品更好的质量,当然是很值得的,而且对于员工个人能力的提高也非常有帮助。

  敏捷测试的实践其实很多公司都在研究,但是真正能成功的可能还不多,其实我们已经试验过很多方法,这次也是一个经验总结后的继续尝试,相信很快能找到敏捷测试的真谛。

原文转自:http://www.ltesting.net

评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)