请选择行业
请选择职位
请选择省份
请选择城市

从测试执行到测试经理5年时间的积累

时间: 2015-07-21 11:44   作者: gehuanyang   点击次数: 
 

  我从知道有软件测试这个职业到现在共五年不到时间。也潜伏在51testing论坛里差不多五年时间,基本没怎么发过贴,也没怎么回过贴,只是有空时偶尔看看论坛里的帖子。
  从正儿八经从事测试工作到现在也有4年半时间,我用了这些年的时间从一个初始的测试执行到测试组长,成为测试主管,再到测试经理甚至同时带着产品经理团队。这四年半时间积累了一些东西,但不敢说自己是技术大牛或者自己试测试专家。因为这些名头都是相对的,在菜鸟前夸夸其谈也会被人称作专家大牛,但真正说技术到了什么阶段,其实在整个测试领域里面也仅仅在某些方面是比一些人多了解东西,多接触了些东西而已。一直想写些东西,算是给自己这么些年做个总结,对测试这个职业做个总结。 当然也仅仅是个人的一些意见


  初级阶段
  在N年前,进了一家国内较知名的移动互联网公司,刚接触软件测试。虽然这个职业在国内已经发展了将近有十年时间了,但是对于初出社会的学生来说,还是相对陌生的(包括现在在软件开发相关学科里面很少有软件测试相关的课程)。那时候有一些自动化测试的概念,但是在大部分公司里面其实大多数还是手工测试,更何况是刚刚兴起的移动互联网行业,压根就没什么自动化的方式,完全手工。所以一天到晚都是拿个手机对着用例执行、参加各种评审会议、写个各种文档(虽然那时候有敏捷的说法,但是公司还是按照传统瀑布式的流程,于是乎难免就有很多很多文档,很多很多评审)。开始也没觉得什么,毕竟是自己选择的职业,也还算比较新奇的。但是久而久之就发现一些问题:
  为什么在一个研发团队中测试的地位不高?
  为什么测试每天做的都是同样的工作,但是应聘要求要这个那个的?
  怎么规划职业发展比较合理?
  那时候想想都想不明白,但是后来慢慢的都有了答案:
  1. 这样一个研发团队中,测试仅仅是去验证软件是否按照产品的要求去完成相应的功能。不了解完成相关功能如何实现,从而在产品出来后如果有问题就比较被动。如果碰到一些可改可不改问题,开发就会说这个问题解决不了,这个问题就是这样不算问题,我相信很多测试都碰到过类似的情况。测试仅仅是当做一个用户这样去工作,这样一来测试的地位就很尴尬了,随便来一个人只要思维清晰一点就可以代替你的工作。从整个公司管理角度看到的情况就是,测试仅仅是来做功能测试的,这样的职业门槛很低,所以地位不会得到重视。
  要如何去解决这样的问题呢?我目前的做法,测试介入产品设计阶段,介入开发设计方案阶段。在产品角度,测试对需求的把握程度比开发跟精确,更细致。而且通过对测试工程师能力培养,使之能够知道在完成这块功能的时候,需要怎么去设计,会用到哪些技术。
  久而久之就会变成我部门目前的状态:产品经理出了需求后,测试和产品经理、开发做大量沟通。后续到研发阶段,测试俨然就是这个项目的产品经理了,会和开发讨论需求,并监督其在开发阶段按照需求来研发。另一方面,在研发阶段,虽然测试不需要给出一个设计方案,但是很多时候测试的方案往往会被开发主管直接使用,或者做参考,有时甚至为一个功能的实现方式争论。后期测试阶段,测试会按照一些自己的逻辑去执行,覆盖面明显有提高。
  这样一来,产品的质量明显提高,测试地位也提高。
  2. 第二个问题,其实分两个方面来讲。第一个方面,很多公司的HR有时候不大专业,在发布一个岗位招聘信息的时候,往往看了别人信息中写了会LR、会QTP等等等 就往上贴,也不会去考虑自己招的这个岗位具体是怎么个要求。有时候去跟这个招聘的需求方去沟通,相关的测试经理也就按照行业内的一些工具,不管三七 二十一就往上贴,显得自己要招的岗位是多么多么牛逼。这样就会出现一些纯粹黑盒测试岗位,要求精通代码。做功能的测试岗位,要求会用LR。
  但是从我的个人角度来看,大部分的要求其实并不过分。一个测试如果仅仅做功能测试,有时候可能不会用到一些工具。但是如果想更深的去了解实现方式,稍微的代码能力还是需要的。对于不同的项目,可能会用到不同的知识点,可是千变万变就那么些东西,无非是代码,数据库,操作系统,缓存,算法 等等等等 。而其他的一些技能,是对自己提升身价有很好的帮助,也对自己职业发展有很好的帮助。所以我一直认为测试是对知识广度要求比较高的职业,既然选择了这个行业就要不停的去拓展自己的知识面。
  3.对于第三个问题,也是见仁见智了。很多人选择测试转管理,转开发等等 都有。从我角度来看,测试发展一般有那么几种:
  对技术比较感兴趣,肯往深的去钻研的,后期发展成测试技术专家,或者专开发成为开发领域的专家,抑或变成技术管理。对某些领域的测试,有很高的技术修养。
  沟通能力,团队概念比较强的,转测试管理。当然专管理也是要看机会的。测试管理 就有一定的测试技术  和测试理论 ,但主要还是管理能力。
  有些同志就直接换个职业,转成项目经理 或者 产品经理。在这些岗位,测试工程师是很有优势的。

  过了一些时间,我碰到个机会,转去了系统测试部门,并且慢慢的成为一个组的leader。从那时候起就开始接触到了一些自动化和性能测试方面的内容。那时候的系统测试有很多时是去写一些接口代码。然后用这些接口代码去过用例,然后通过接口代码去做性能测试。其中也是有一些总结:
  1.什么时候做自动化比较合适?
  2.自动化测试团队需要哪些条件?
  3.性能测试是需要积累什么知识,什么样的环境去做?什么时候去做性能测试比较合理
  关于自动化测试,在这个领域里面已经是老生常谈的一个问题了,很多人夸夸其谈自动化能带来生产效率的提升,能怎么怎么样。我不全面反对,但是也要看公司的发展阶段和项目的发展阶段。就我目前经历的而言,在一般项目里自动化其实相对来说成本是非常大的,因为需要的必备条件很多:1.我的测试团队得有设计自动化的能力 2.我需要人去编写新的自动化代码的同时,维护老的回归代码 3.需要和有人对整套自动化体系有比较深刻的认知和理解。4.产品或者项目已经到了一个稳定的阶段,在大的方面不会怎么改动。5.项目给予我比较宽裕的时间
  综上所诉,当公司发展到一定规模,可以有一定资金和时间成本,且项目已经稳定到一定阶段或者正好碰到一些比较合适的项目再去做这个自动化效果是最好的。如果真的做成了对团队的提升,甚至对公司的技术层面的形象是很有帮助的。
  不过换一种方式,我觉得可以两者兼备。在团队不大,项目不稳定的情况下,其实可以做单一几个点的自动化,仅仅是手工测试的补充和扩展。这样不成体系的自动化在前期带来的时间成本可能不会很高,但是后期一旦项目稳定下来。将几个点整个到一起,就可以作为一个完整的自动化测试体系了。我在很多个项目中都这样来做,要求测试工程师在重复工作的几个点,写成相对独立的测试代码。在锻炼工程师的代码能力和自信心的同时,为后期做整体回归做了一部分准备。后期等项目进入维护阶段,找几天时间整合这些分散的点,集成在Hudson中。后面的回归全部通过这个测试去做,外加一些手工的回归,这样后期回归的成本可以降低很多。
  自动化也是不是全部,很多情况下自动化只能是一种补充,还是有很多东西要靠手工测试去做的。在我看来接口的测试,完全自动化还是比较可行的。一来它本来就需要编写一些测试代码去做测试,2来他不像页面甚至终端会出现一些复杂的操作,他仅仅是一些数据的输入和输出。
  自动化测试团队的根本还是测试团队,目的还是保证项目和产品质量的。所以测试的知识逻辑还是最重要的,我宁愿要一个不会写代码的但是测试逻辑清晰的自动化工程师,也不愿意要一个代码能力强但完全没有测试概念的。其次还需要有自动化的一些基本的知识,包括如何去写一个有效的测试,一个可复用的测试,如何在研发代码提交后去集成测试,怎么样去维护这个测试,维护你的测试环境。除了这些之外,其他部门的支持,领导的支持当然也不能少。
  关于性能测试,我这里就随便扯一扯吧。我个人虽然不想把性能测试,压力测试,负载测试这些分的很清楚,但是不得不说确实是因为目的不同做的不同内容的测试,不过有时候他们其实是类似的,是目的不同的相同类型的测试,所以暂且就允许我统一叫性能测试吧。性能测试肯定是在功能全部完成,系统已经趋于稳定的基础上做。性能测试的目的:1.确认产品是否达到了预期的性能要求,是否会有性能方面的bug,是否可优化2.确认在某个负载情况下,对硬件网络等的消耗情况,对后期生产环境的搭建和运维提供可用数据。3.系统能稳定承受的最大压力是多少,在该负载情况下,系统运行情况,是否可扩展来解决。
  总的来说它的目的是为了运营和运维做数据支撑,和确认产品目标已经完成。所以要做这个类型测试前的准备也和这个相关:
  1.确定产品的性能的指标性数据,一般产品说明书上都会确认这个数据,产品规模啊、日访问量 等等
  2.在以上数据、应用特性、业务分布等多种数据基础上,建立测试模型。打个比方:某系统存在两种业务类型,一种登陆,第二种登陆后自动上传或者下载数据。产品要求日访问量在1000万,日吞吐数据500万。一般情况下移动互联网应用的日最高点击量是日均点击的3倍(像这种数据来源一个是靠业界的一些统计数据,另外一个来源可能来自运维团队的一些运维经验),也就是说我们系统性能指标是    1000W/3600*3 的登陆性能标,和同样的数据上传下载性能指标。 而压力测试和负载测试的时候也必须得考虑这些场景的混合场景。
  3.了解未来生产环境的情况,如网络情况、机器硬件情况等。确保你做的测试更实际情况类似,提供的数据可参考。
  4.完成以上工作后,才会做着手测试。不管用LR,Jmeter或者啥,只要能达到目的就可以。
  5.发现问题去排查问题。找到瓶颈调优,提供数据和建议 从而完成测试。这个环节就要靠知识的积累了,很多同学第一次做性能测试,最后发现问题全部在基础的一些基础数据调优甚至压力机的问题上,所以出来的数据不可用。
  整个过程最关键是在建立测试模型和排查解决问题的时候。
  所以性能测试需要很多的专业知识,包括一些数据分析啊,产品业务剖析啊,系统和网络的知识,还得对系统架构啊,甚至某一项语言的特性等等有了解。性能测试经验丰富的工程师,甚至可以在产品设计之初就会发现设计中存在可能出现的性能问题。这些都靠积累了。
  后来跳槽换了一家公司,因为之前公司的名声在外,所以那时候跳槽换个管理职位还是相对容易。我也一样很容易拿到一个测试主管的职位。从那时候起慢慢就开始不去做一些技术方面的东西,很多时间是在培养新人,带团队等等事情上。这个阶段我反而对一些最更本的东西感兴趣,不再去花很多时间去钻研技术方面的,更多的是把之前的东西完善巩固,然后在自己的部门里面实施,甚至更多是去思考员工的问题。

打印本页 | 加入收藏

上一篇:90分钟内完成全天工作     下一篇:成为优秀程序员的十个Tips

关闭  
主要城市: 北京 上海 杭州 广州 南京 武汉 长沙
全部城市: