软件测试,想说爱你不容易-2

上一篇 / 下一篇  2012-11-30 11:49:28 / 个人分类:测试经验

 一不留神,毕业后在软件公司里已经工作七年多了。期间经历了民企、国企、美国硅谷小外企和大型外企,做过正规软件开发(团队规模10人以上,有产品经理、开发人员、测试人员、文档工程师,客户为Cisco,出过2个以上的版本,代码量在20万行以上),功能测试性能测试、测试自动化、测试辅助工具开发、国际化测试、本地化测试、兼容性测试、第三方测试、测试团队管理,对软件测试的理解也逐渐深入。特写下以下文字与大家分享。51Testing软件测试网]A)~hT`Y;] W1k!q-S

  l、软件测试的前途

~P sA5^g!Hj{&a0

aK B0AaRv(O$Pp0  软件测试在整个软件生命周期中是必不可少的重要一环,但是其在研发体系中的重要性要弱于软件开发和基础技术研究(如搜索引擎的搜索算法,图像的识别算法,统计分析模型等),要高于大多数外围工作(如安装部署、环境搭建等),很难拿高薪,工作强度适中。51Testing软件测试网h&Y$w*X~/V m#Q

51Testing软件测试网^Z5v kg)I

  做软件测试的同学们看了这个结论可能会很不爽,难以接受,但确确实实是我在工作多年、经历了多家公司后总结出来的切身体会。重要性不是某个人或者公司领导决定的,而是尤其工作自身的特点决定的。为什么测试工程师则经常抱怨自己的工作不受重视,而很少有架构师抱怨呢?因为他们的工作内容门槛高,可替代性低,一般人把他放到那个位置上也干不了。

0k?ae,O)E \8X)J`d0

[:@:W.WYk[*Q0  拿大多数软件公司来说,软件开发和软件测试是两个最常见的工种,拥有最庞大的工程师群体。一般来说,开发工程师比测试工程师可以拿到更高的薪水。核心开发工程师的工作内容技术门槛比较高,可替代性比较低。一个明星产品的原型,或者内核,往往也就是一两个人写出来的,Linux内 核,JBoss,Struts,Spring,Hibernate...太多太多这样的例子。虽然说一个技术原型和成功商业化的产品之间还有很大的距离, 还需要不同工种的人互相协作,但是谁在扮演更重要的角色不言而喻。毕竟,软件是开发出来的,不是测试出来的。核心开发工程师做的工作,初中级工程师根本无 法染指。

p0z;A+J%T.z2@051Testing软件测试网e xpM7F~+U)m

  大多数测试工程师拿到的都是行业平均薪水,差距不大。对一个产品进行测试,80%的工作量是功能测试,性能、可靠性、国际化、 易用性等等加一起一般也就占20%。道理很简单,如果一个产品的主要功能跑不起来,其他东西都白搭。由于种种原因(如需求变化大导致界面变化大),功能测 试又以手工测试为主。这部分是技术含量最低,替代性最强,个人知识积累最少的测试工作了。今天测试产品A,明天测试产品B,就好比今天当力工搬砖头,明天 搬木头,只要力气在,搬就是了,管他搬的是什么。甲做也可以,乙做也可以,经验丰富、耐心细致的可以发现更多、隐藏更深的bug,但是不存在做不做的了的 问题。3年下来,一名开发工程师可以掌握一门编程语言,懂点设计、架构、框架、UML,或者一个人前台后台持久层全部拿下。而一名手工功能测试工程师,只 能成为某个被测试产品的使用专家,不用去懂J2EE或者.Net,Flex或者Html5,MVC或者SSH。被测产品一换,一切重头再来。51Testing软件测试网DV!}b"Z"z;h b

51Testing软件测试网.D^(a8kF9h$Y V9O

  测试中比较有技术含量和门槛的是测试自动化开发、白盒测试和性能测试。51Testing软件测试网n7Vw`c7H

#U!P/@7X/Y `L4~/z8m0  先说说测试自动化开发。测试自动化开发主要有两种,一种是用现成的工具如QTP、WinRunner编写测试脚本。还有一种是自己用Java或者C#编写辅助测试工具。现成的工具都基于某种语言,如QTP基于VBScript,WinRunner基于自己独有的类C语言,Selenium基于Java。自己编写的工具大多用于批量数据生成、导入、处理等。而这两者归根到底还是软件开发,而且大多数是比较简单的开发。

{\ Sz$s(@0

4iG*Z.[:U)|9z.z^d$n0  测试脚本很多不需要界面,是命令行程序,这样GUI开发中的很多难点就不会遇到了。51Testing软件测试网T[ i/a_*j$l1B

'K W%Zj3VX_i0  大多数是单线程运行,因为是脚本,即使是上千个脚本,只要按照顺序跑就可以了,这样多线程的麻烦就不用去处理了。

9Z T'AD(r^c~0

}M,~[1]'h i0  不需要访问数据库,因为测试结果一般记到文件中如html文件,并以表格或者简易报表的形式显示就可以了。这样,在软件开发中的一块重头戏-持久层开发和数据库设计就不用考虑了。51Testing软件测试网 t)e;?@;[O X

51Testing软件测试网0s5}gcd*u4D

  如此这般,对于一般的测试脚本或者工具开发,专业的软件开发人员即使没有什么测试经验,也可以轻松上手,做得游刃有余。51Testing软件测试网 iIWi+H'Qhd

51Testing软件测试网)@aC}$}!O

  白盒测试是相对于黑盒测试而言的,是通过写程序来测试程序,比较常见的如测试Web Service API,测试类库提供的API。和测试脚本开发类似,属于相对简单的开发。这类活儿没有编程基础的人做不了,希望深入钻研技术的资深开发人员又不愿意做,比较适合初级开发人员来做。51Testing软件测试网;C1s1R&n:td5jw

Gj*K:gs0  再说性能测试。51Testing软件测试网t5Hz:cLO4}$a n

51Testing软件测试网"PA h8uTs8lx

  性能测试的主要目的就是验证一个软件产品可以允许多少用户并发访问,性能指标如响应时间、CPU和内存占用率是多少。一般来说这种测试无法手工做,需要借助于工具,如LoadRunner, QALoad,JMeter等等。首先,在录制的脚本基础上做一些编程是必不可少的。其次,在获取到基本的性能指标值后,如何去分析并解决问题,比如调整操作系统、 数据库、中间件的参数,做个集群啦啥的,或者对程序做代码级的优化,又远远超出了测试的范畴,是一般的性能测试工程师根本做不了的,需要架构、IT工程 师、开发人员协同攻关。可以看出,一位性能测试工程师所作的脚本开发工作,对于专业开发人员来说,没有什么门槛。而复杂的测试环境搭建的工作,又需要网络 工程师、数据库工程师的强有力支持,个人难以独自应付。

C:Z;|W/V6\051Testing软件测试网/l8Fq;_"r8D

  国际化测试的门槛一般。核心的东西,挤干了水分,也就两三个月,包括字符集、编码、字体、Bidirectional language、时间日期货币小数点排序布局等。换句话说,一位功能测试工程师,在经过好的导师三个月的专业培训和学习后,就可以基本胜任国际化测试的工作了。这里的门槛在于,市面上介绍国际化测试的书不多,很多东西需要在工作中去一个个知识点地学习,需要老员工来带。不像对java、数据库开发进行系统介绍的书那样满大街都是。

)IW kYP051Testing软件测试网W _;p {I"E{9S

   兼容性测试是典型的没什么技术含量的人力密集型工作。本人曾经做过一个月的打印机兼容性测试,上百台打印机,一个接一个放入打印纸打印,看看对被测试的 国产Linux的支持程度。或者一个产品,测试对不同数据库的支持。让我想起在上大学的假期里给人发传单时,发一次挣30元钱,谁干都可以,卖卖苦力。后 来改行写游戏外挂,一个月轻松挣3000多块,让室友们羡慕得不得了。

d3p/s5J$UN051Testing软件测试网TW?q zb
51Testing软件测试网{9m(M(Io

  于是乎,为了各自的饭碗和声誉,悲剧开始了。

^4lV4Z\ _H0

(m l!Ij|i(w0  测试组会竭尽全力提高测试覆盖率,报bug,宁可有少量误报,也不敢遗漏;而要提高测试覆盖率,测试组需要开发组的大力支持和配合。实践证明,没有开发人员的帮助,比如介绍哪个模块有潜在问题和复杂的逻辑分支,测试组无法独自发现很多重要的bug。51Testing软件测试网4Q-h:^ I/F/TK

51Testing软件测试网7O6o'Y$n0R'` NljG2l

  而开发组在项目后期压力会比较大,一边拼命修复bug,一边看着新bug一个个先仆后继地冒出来,感觉bug就如同苍蝇般轰都轰不走。遇到比较 严重又不好修复的bug,更是倍感压力,茶不思饭不香。突然间,开发人员自己发现了一个比较严重又不好修复的bug,第二天就要交付产品,时间来不及了, 而测试组还没有发现。该如何抉择呢?51Testing软件测试网.H0HfSJ6F*h7x&R

LZ?:x6R'm2V$^%A0  a、主动报告bug,自己承担全部责任;为了这个bug,可能需要专门给产品开发一个patch,在公司上下都造成了负面影响

;{f[4m%n5R+I0

hm;s h6x2qcn%D0  b、隐瞒bug,测试组最终也没有发现,产品交付使用后被客户发现了,测试组承担全部责任51Testing软件测试网.~V)?C|p q

5q0e-y uh {G'm(k3y0  c、隐瞒bug,测试组最终也没有发现,产品交付使用后客户也没有发现,皆大欢喜,在下一个版本里自己悄悄修复51Testing软件测试网E-i.d(CuehI

51Testing软件测试网A)d"L? J:e lN?[

  公司不同,企业文化不同,奖惩激励制度评价体系不同,最终会使开发人员在一番权衡之后做出截然不同的决定,进而影响这个产品甚至整个公司。51Testing软件测试网7r{mr0h4e4M6SO6c

}|zr%P2H@0  2)组织架构51Testing软件测试网@W3`"w'O1iG q

51Testing软件测试网(Hd"|Tz

  在很多大公司里,部门会按照职能来划分。测试部下辖若干测试小组,每个小组负责测试一个或者一类产品;开发部下辖若干开发小组,每个小组负责开 发一个或者一类产品。测试部经理和开发部经理都直接向研发中心的经理汇报。当测试部经理和开发部经理在一些工作上意见不一致时,没有人来直接做裁决,导致 互相扯皮。一个中大型研发中心同时会有至少几十个项目在运作,研发中心的经理在宏观层面上掌控全局,根本无暇顾及每个项目的细节,很多时候就任由测试组和 开发组的人来互相角力了。项目经理和产品经理在不同的公司里话语权差异很大,经常无法有效调和这些矛盾。51Testing软件测试网!i4w2e,{uf/T P6CQ

51Testing软件测试网 c^;~|%s,_Cw

  在有些公司里,部门会根据事业部/产品线来划分。部门甲负责一个或者一类产品,下辖开发组,测试组,项目经理,产品经理,UI设计人员等。当开发组和测试组意见不一致时,由部门经理最终拿主意,对项目的成败负全部责任。这种架构下情况会好很多。

7O$d8|p6@Jv0

D#HRg@0  Q:如何评价测试人员的工作?

x2I\0p6t%}Z0

5tW8S:Ytd)H n0  A:需要bug数量和经理的主观感受相结合。单纯依赖bug数量,就如同单纯依赖代码行数来评价开发人员一样片面。其一,Bug的数量可以掺水;其二,做性能测试的人员所报bug数要远远小于做功能测试的人员,做测试开发的人员就根本没有bug可报。51Testing软件测试网M{6a/~%sxM`:X

0timwMpRk6i9w0  Q:在从事若干年测试工作后,大家都向哪些方向发展了?51Testing软件测试网m&jy4N#J5v*v,mP

]o%A;I2z eG!J+{ a0  A:根据我和身边同事们所经历过的各类公司的经验,大致有如下几种出路。51Testing软件测试网CnX%c7{.?]soM

51Testing软件测试网%q YbW }\ p6A

  1)测试管理。管理职位是稀缺的,不是想做管理的人都能有机会去做,即使各方面能力都具备了。

7|#P^|R7|w N0

~ftxb,[RMR0  2)转开发。测试转开发 比 开发转测试 的难度要大得多,越早越好,转失败的不在少数。

o:q8ei*V0Z051Testing软件测试网"mou.{b?Nw

  3)转售前售后技术支持、顾问、培训。测试的好处在于对产品的整理理解和把握,同时研发的背景对于这几个工种非常有益。51Testing软件测试网A qo.dK%s#v8d

1B+]g5K;XN"x5{0  4)在测试的道路上长期走下去,做技术专家。这是大部分人的选择,不管是主动的还是无奈被动的。51Testing软件测试网&n&Q3]D \


TAG:

 

评分:0

我来说两句

Open Toolbar