本帖最后由 treeou 于 2017-1-6 14:30 编辑
前言: 做测试有些年头了,一直没在论坛上发过言,今天开个头和大家聊几句。 在敏捷开发理论框架下,测试人员与开发人员的界限已不在清晰,这让传统测试人员产生非常大的困惑:测试活动的地位被消弱了吗?测试人员没有用了吗?测试人员必须得掌握编码知识吗?这是我们经常遇到的疑问。本文试着从我们2年多的敏捷开发实践经验来分析一下这个问题,为测试人员解解惑。 正文: 部门从2014年开始大力推广敏捷开发模式,我们项目组也不例外,如今,下面这个场景已经司空见惯:进入开发大厅,一眼忘去,四周的黑板、墙面上贴满了纸条,空调开启,随风飘舞。至此后,早晚时间,人头攒动,会议室常满,办公室异常热闹。 引入敏捷模式之后,最大的变化是项目过程明显加快了,每天纸条上的任务像挥不去的梦魇,压得各位兄弟姐妹喘不过气。没办法,自己挖坑自己埋,自己领的任务自己干。项目组人员像拼命三郎一样干活,代码量像吃了激素一样快速增长,一周或二周一个版本,开发、测试;开发、测试...周而复始。可是,过了不久,项目经理就坐不住了,测试、测试、测试呢!为什么这么长时间还没测试完? 其实,开始实施敏捷的时候,大家忽略了一个重要的问题--如何测试,理论上讲,敏捷开发模式要求整个项目组都要敏捷起来,如果有任何一个环节没有敏捷,就像常说的“木桶效应”一样,整个过程就被拖慢了,而在整个环节中,测试活动的敏捷是非常重要的,也是最困难的(以往的测试活动多是手工做的,现在版本释放周期短了,测试工作也自然困难了。) 可是有人要问了,敏捷模式下不是不需要专门的测试人员了吗,因为这事还搞得测试体系人员人心慌慌的,好像是敏捷升起,我将坠落的样子。可是,我们仔细品味下这句话:“敏捷模式下不需要专门的测试人员...”,人家也没说不要测试活动了呀!人家的意思是说开发人员和测试人员的界限划分不明显了,没说不用测试人员啦!于是,心思得解,测试团队表示:先贤已经说过了,测试活动是保证软件质量的最重要、最有效手段,这个是永远不变的真理。 的确,目前看,这名话说得确实没错,在没有出现更加强大的、智能化的开发工具前,测试活动仍然是保证软件质量的最有效手段。只不过,在敏捷盛行的时代,我们要重新理解并完善测试这个活动。说白了,就是与时俱进,如何让测试活动像整个开过程一样敏捷起来。从目前有效的解决办法来看,就是引入自动化测试工具,通过自动化测试手段让测试活动变得更加迅速,并且是全生命周期的引入,从单元测试、集成测试到系统阶段,全面引入。(ps:关于引入自动化测试这个话题比较大,实施起来也很有难度,涉及到在什么时间引入、引入什么工具、与之配合的工作流程是什么等问题,不是一二句可以说清楚的,以后再慢慢聊。) 说到这大家就清楚了,敏捷开发模式不是不需要测试人员了,而是开发活动和测试活动融合得更加深了,可以说是开发人员和测试人员的界限划分不明显了,也可以理解为对测试人员的要求更高了。估计说到这,有的测试人员激动了(还好哥以前码过一阵程序,不用被淘汰。)、有的测试人员被动了(完了,上面刚解完心宽,怎么唠着唠着又要失业了呢!),就会问:你的意思就是说测试人员还得能编几行代码呗,是不是这样?你说?是不是这样? 各位测试界同学先败着急,坐好,喝口水压压惊。大家都是做测试的,再看看上面的文字,仔细核对一遍,那有一句说了测试人员必须要写代码了,肯定没说,上文只是说对测试人员的要求高了,这样才能更好的执行自动化测试工作。 其实,在我看来,敏捷模式下也必须要有专职的测试人员存在,并且,专职测试人员不一定要会写代码(当然,会写更好。)。原因如下: 1、自动化测试覆盖率不高
从目前实施经验来看,一个成熟的组织能够将自动化测试的覆盖率做到50~60%已经十分不易,而对于新功能(系统)的自动化测试,能做到30%的覆盖率就已经很成功了。所以,还要有大量的工作需要手工方式来做。 2、自动化测试工具更加易用了
思想的进步和技术的发展已经让自动化测试工具变得非常易用,优秀的自动化测试框架已将应用人员的技术要求降到最低,彻底摆脱了传统的“录制->调试”的复杂模式,基本上可做到“积木式”脚本的制作过程(直观的通过界面元素编写脚本的模式,所见即所得,简单易用,老少皆宜。),所以即使你不会写代码,也能做自动化测试。 3、集成后的模块(系统)要统一验证
模块内的自动化测试执行起来相对容易,但是整个产品最终集成后,是否能如期完成业务要求却是未知的,甚至有的时候是多个系统间有业务关系,要相互传递数据。所以,整个开发团队里要有专门的人员,负责把整体集成后的测试工作抓起来。这项工作不是具体的某一功能的测试,而是一种更宏观的、面向整个系统的验证工作。换句话说,就是要验证集成在一起的系统是可以工作的,而这个工作往往是自动化工具不能完成的。 以上,通过过往的工作经验整理了一些想法,希望对广大测试人员有所借鉴和帮助。
|