生命就像一场云游 坎坷也是一种收获

一个软件测试工程师的工作心得(转)

上一篇 / 下一篇  2008-04-01 10:50:46 / 个人分类:测试感悟

写这篇文章主要有两个目的。
  1、 对自己这一年零八个月的工作进行回顾和总结,把第一份工作的记忆都写下来;
  2、 自己做了一年多的软件测试工程师,对软件测试工作算是有一定程度的了解,希望与大家分享我的感受和经历。
  
  先介绍一下我的背景:通信类院校05年毕业、本科、计算机专业,毕业后进入一家大型通信设备商工作,任职软件测试工程师
  
  一、T项目执行
  
  05年7月13日入部门,此时才知道自己被分配到了测试部。部门主管把我领走后,就把我交给了导师。
  
  入部门的头几天,主要熟悉公司的工作环境,认识部门同事,了解产品知识。由于我们是做传输设备的,所以当时学习的产品知识主要以SDH原理为主,包括SDH的帧结构、网络的保护和倒换等。
  
  下面介绍一下我所做的项目。
  项目名称:T软件
  
  项目概况:该项目是在PC和Sun工作站上开发的软件,属于CS结构。Client端用Java开发(开始使用JDK1.3,后来改用JDK1.4),实现跨平台;Server端用C++开发,使用ACE实现跨平台(WindowsUnix)。
  人力投入:开发好像是9人,测试3人。(我来的时候是产品的第2个版本,人力投入大概如此)
  
  我入部门几天后,T项目就进入了测试阶段。我的任务就是执行分配给我的测试用例。当时我只知道根据测试用例描述的内容,去点鼠标,如果发现程序出现错误或异常,就填写问题单。我就这样没有任何思考的按着测试用例点了3个月的鼠标 : )
  
  现在想起当初的测试工作,实在有太多的不足,和待改进点。
  
  1、 测试用例。对于一个软件的测试来讲,测试用例是至关重要的。测试用例要覆盖所有测试规格,而且测试用例要易于理解、易于执行,简单的讲就是要描述的规范。而当时我们的测试用例却是一团糟,最糟糕的是用例的质量很差,使用这些测试用例,根本无法保证产品质量。测试用例的预置条件、操作步骤、预期结果的描述也是乱糟糟的,而且用于存储测试用例的Excel表格设计的很差,界面很不友好,从一定程度上降低了测试效率。
  
  2、 产品知识。T软件虽然是在PC和工作站上运行的,但是开发T软件的目的是为产品服务的,所以我们必须具备产品知识,才能更好的对T软件进行测试。恰巧当时包括我导师在内的3个人,都不太了解产品,所以就造成我们无法判断某些测试用例是否验证通过。从而导致了与开发人员的多次争吵。

 3、 软件测试的重点不明确。软件测试是软件工程中的一项重要活动,它尽可能发现程序中存在的缺陷,保证程序的质量。但软件作为一种商业品,有它的发布时限,老板说这个软件要1月份发布,你总不能测到12月份再给他发布吧。当时我们在一些小问题上与开发人员纠缠过多,而很多重点却没有得到重视,一些严重问题暴露的比较晚,导致测试时间延了又延,版本测了一个又一个,想起那些日子,只能如此描述:“累并痛苦着”。 : (

4、 测试流程的把握。7月份中旬,T项目从开发部转到测试部,进入了测试阶段,实际当时的产品质量并不能达到转测试的标准,而我们却让他们通过了转测试,结果就给我们自己带来了巨大的痛苦。而且后续的几个版本也如此,我们是测了一轮又一轮,测的我们都要绝望了。回头想一想,T软件还真的是我们测出来的,而不是开发写出来的 : )

5、 缺少针对性测试。软件也可以分很多种,不同的软件有不同的特点,自然就需要针对性的测试了,譬如GUI的软件与嵌入式软件的测试方法肯定有很大不同。最初我们在做T项目测试时,就缺少针对性方法。有两个教训让我们刻骨铭心:1、界面测试,T软件发布后没多久,其他组同事就发现某界面一个按钮的单词拼写错误——“rollback”被写成“roolback”;2、效率测试,软件测试到后期才发现T软件在实际环境中运行效率很低,根本无法满足达实际应用的需要。从那以后我们就准备了专门针对T软件的测试项目,包括:界面测试、效率测试、资料测试、稳定性测试等。

6、 沟通问题。自从工作开始,开发人员和测试人员的争吵从来就没有停止过。最初是什么问题都吵,很多没有意义的争吵甚至非理性的争吵,庆幸的是现在的争吵大多是有针对性的、理性的。个人觉得以前无为争吵过多的原因是:开发人员、测试人员的工作技能和职业素养都比较欠缺。吵了大半年后,人员提升了工作技能和职业素养后,吵架都吵的比较有默契了。当然最重要的是开发人员和测试人员的目标要一致:保证产品的质量,满足客户需求。

二、自动化测试
  06年过完年后,我被主管派到一个大组去学习自动化测试技术。这个测试组是个比较大的测试组,总共有几十号人,其中有很多牛人。他们的自动化测试框架就是由几个牛人耗时1年多开发出来的。到现在,他们的自动化用例覆盖率约50%,应用率好像有70%,总之这个自动化测试框架还是满牛X的,不过就是整个框架实现太复杂了,涉及的编程脚本就用了三种 : (
  
  下面简单介绍一下该GUI自动化测试框架。
  测试工具:IBM Rational Robot
  自动化测试技术:第三代自动化测试框架,叫什么DDE,具体什么意思已经记不住了 : )
  测试脚本:Robot中使用的是sqabasic脚本(基于basic的一种脚本),另外还使用了TCL、COM组建等,并自行开发了一个抓包工具用于自动化测试。还有我们测试的产品界面是使用Java开发的,如果要让Robot能够正常识别界面,还需涉及到Java编程。呵呵,实现上可是够复杂的 : (
  
  学习自动化的头一个星期,我只是学习该测试组的产品知识,学习如何使用自动化测试。后面的几个星期就开始承担自动化测试的建设任务了。想想当初自己还是满辛苦的,白天上班学习产品知识,晚上回家就对着电脑看basic脚本的语法,周末还去公司无偿加班看代码。

在技术文档的选择上,我基本只看英文的,单词不懂就拿金山词霸查,实在看不懂了才会去找些中文的资料看。为什么要选择英文的呢?因为很多中国写书的人很浮躁,只想着快点把书出版了好赚钱,所以很多中文的资料质量很差。首先要贬低的就是那本谭教授的《C语言程序设计》。记得读大学时,照着谭教授的书敲程序,没多少程序能编译通过的,真是误人子弟。
  当时带我学习自动化的导师姓L,他是个大忙人,有时一整天都在开会。L的师傅姓W,W是该自动化创始人之一。我呢,充其量算是徒孙一辈,呵呵。由于L太忙,而且不那么爱说话,于是乎我就只能自己对着文档看代码。
  当时对我比较有用的文档就只有两篇:一篇是汇集型的chm文档,是篇比较全面的介绍,其中包括自动化框架的介绍,原理的介绍,各模块介绍,自动化执行的流程等;另外一篇则是由W写的自动化建设指导书,写的还是满不错的,在我有一定基础后,照着指导书就能完成简单的自动化建设。

在我整个学习过程中,是按照以下的过程开展的:1、初步了解整个自动化和产品知识,尝试使用自动化进行测试;2、熟悉sqabasic语法;3、对着文档读代码,尝试调试脚本,跟踪到代码的最底层。
  其实最好的学习方式就是实践,去做自动化建设。当有一定基础后,去完成导师交给的自动化建设任务,就是最好的学习方式。后来,我教别人的时候,也是安排实际任务给他做,然后再进行相应的引导。
  在我的学习期间,有件事情让我满讨厌的。就是我必须给原部门的主管和测试组人员讲课,然后那些家伙会不停的提问,以检验我的学习效果。虽然这招很BT,但是对个人的成长还是满有利的。假设你学会了一项技能,此时你可能只在第一个层次上,如果你能够把这项技能教会别人,那么你的层次上升了一个档次。
  记得当时是06年2月初去参加学习的,4月初就应急被调回原测试组了。总共不到两个月的时间,我总共完成了3个模块的自动化建设,第1个模块搞了3个多星期,第2个模块不到2个星期,第3个模块一个星期就搞完了(第3个模块算是友情支援呢,哈哈)。
  4月初被调回原测试组后,就一直做救火的工作。差不多5月份的时候才正是开始做我们T项目的自动化。其实也就是把我学习的自动化框架移植过来,做T项目自动化测试。
  另我比较遗憾的是,T项目的测试一直都很紧,而自动化测试并没有被推广和充分利用。直到我离职前,测试组为应付测试部自动化考核指标,才得到重视。

这里我谈一下自己对自动化测试的理解。
  1、 自动化测试用于提高测试效率;
  2、 自动化测试可以完成一些无法手工完成的测试,例如长时间不间断的测试;
  3、 自动化虽然能够发现问题,但主要是对继承的功能进行测试,保证以前的老功能。(这个跟项目有关, GUI自动化测试比较复杂,如果是嵌入式设备或芯片的自动化测试,对自动化测试的理解可能会不一样)

三、开发小工具
  我在自动化学习期间,表现出来的专业技能和良好的学习能力,得到了同事和主管的认可。鉴于此,在4月中旬的时候,测试组的Leader给我安排一个任务,使用Excel表格开发一个工具,用于收集和统计记录的数据。要求该工具能够代替手工计算,提升测试效率。任务完成的截至日期是五一。给我安排的时间大概为一周。
  该工具的实现方式并不难,就是设计一个Excel表格,然后在里面嵌入VBA脚本,以宏的方式代替手工计算。对我来说最大的挑战就是:1、短时间内学会VBA编程;2、提取需求,设计Excel表格的格式,使该工具具有较好的易用性。
  当我接到任务后,下班回家就开始到网上搜集关于VBA资料。当时我找了一个星期,都没有让我满意的文档。最终只找到一篇国人写的PDF文档,但是那篇PDF文档只是让我初步了解了VBA是个什么东东,并不能满足我的实际需求。最终,在写VBA脚本期间,我还是参考微软自带的帮助文档搞定的。(搞忘球当初是否装了MSDN)

本来计划是在四月底的一个星期开展该项任务,但实际上直到4月的最后两天我才有时间。记得当时,我花了一天半的时间与我的客户——也就是我的同事,共同讨论需求,并设计Excel表格的格式,让其评审。最终写脚本花费了4月的最后一个下午,以及五一期间的三个下午的时间,总计4个下午的时间,完成该工具的开发。而且我五一期间的工作并没有申报加班,是无偿劳动啊 : (
  另外,令我欣喜的是,从此我成了我们组的“牛人”,哈哈哈哈。。。。。。
  其实工具开发完成后,还是有些问题,如:
  1、 程序崩溃(不小心除了0,呵呵,加入异常处理就OK了);
  2、 有1/3的功能基本没有被使用(郁闷,花那么大精力。。。我的五一啊);
  3、自动生成的表格,奇丑无比(直到现在,我都没改,哈哈)。
  
  记得当时有个做了5年以上C++的开发人员,看到我写的Excel表格,居然说“诶,这东西还满神奇的嘛”。我当时的一个感觉就是,晕,这个家伙工作效率肯定不高。
  Excel还真是好用,功能强大啊!

四、负责M项目测试
  06年10月份,我开始独立负责M项目的测试工作。M项目是个小项目,大体情况如下:
  代码量:大约10K行
  开发语言:C#
  软件环境:Windows PPC 2003
  硬件环境:hp的PDA(具体型号忘了,反正是便宜货,大概1000块)
  人力投入:开发3人,测试就我1人
  M项目的测试需求分析、测试设计、测试用例编写、测试执行到测试报告,全部由我一个人搞定。
  
  06年10月~12月中旬这段时间,主要是完成前期的测试分析与设计。12月中旬,就进入了实际的测试阶段,07年1月底,软件发布。回顾这4个月的工作,有做的好的,也有做的差的。下面对这些进行总结。
  做的比较好的:
  1、 测试进度把握比较好,在规定时间内,甚至提前完成了测试任务;
  2、 与开发人员的沟通较好,使问题能够较顺利的解决,基本没有内耗,双方合作愉快;
  3、 测试的重点把握较好,把很多严重问题,在测试前期就给暴露出来了;

做的不好的,待改进的:
  1、 前期的测试分析能力较弱,测试规格分析不全,测试用例编写质量不是高。到后期测试时,才发现很多规格没有覆盖到,需要补充测试用例。而且之前写的测试用例与实际测试情况,有些偏差,用例的可用性差,又花了很多时间去修改用例。
  2、 前期的测试计划制定比较差,实际工作较之计划偏差过大。反正10月、11月那段时间,M项目的工作是乱七八糟的,还好关键时间点的把握还算到位。
  3、 测试对象选择上疏忽,导致漏测。M程序是个工具软件,主要用于查询和设置设备的某些参数或配置。我当时只考虑到对所有支持的设备进行遍历,却未考虑到设备上所有单板的遍历。结果技术支持工程师到香港试用该工具时,发现某块叫PM1D的单板无法识别。后续,我们对大部分单板进行了遍历,还发现了很多隐藏的问题。这是一项较大的疏忽。
  4、 在做内部模拟试验局测试时,对测试环境的选择有较大疏忽,导致漏测。在做内部试验局的时候,我为了偷懒只选择了3个不同设备的组网测试,而没有考虑到大规模组网情况下的测试。后来,技术支持工程师拿M软件到广州试用时,程序的某项功能就不正常了,原因就是大规模组网时,通信数据的传输是多包的,而M程序的底层函数没有对多包的情况进行处理,导致该项功能不正常。当时,在其他实验室是有类似环境的,而我却为了偷懒 : (
  
  虽然M项目的测试有很多不足,但是总体情况良好,我对产品的质量有信心 : )

五、救火
  大概是06年7月份时,我们组组长跟我说,要派我到B组去学习3个星期。等我去了B组才发现自己是被派来救火的。来B组支援测试,主要是完成一项测试任务,说具体点,就是把一件事情干600多次,没任何技术含量。我当时真是郁闷坏了 : (
  
  虽然心底是比较郁闷,但毕竟也就3个星期,想着忍忍就过去了。
  具体的任务很简单:大概有80种板子,每种板子大概有8套软件,用T工具对80多块板子把8套软件都加一次,观察软件加载过程中,业务是否正常,板子加完软件后,运行是否正常。
  
  还有一个也是其他组借调过来的新员工,跟我一起干这件事情。我600多次,他也差不多600次。还好这个家伙,心态很好,做事情也很勤奋。
  
  最初B组给的方案是这样的:先用第1套软件把80多个板子加载一遍,再用第2套,第3套,直到第8套。
  
  开始工作几天,我们就按这种方案执行,但按这种方案执行的效率很差。主要因为实验室常用的板子差不多只有30块,其他的板子都藏在箱子里,而且有些板子B组根本没有,需要到其他项目组去借,这样针对软件版本,对80多块板子进行轮循加载,效率就很低,因为每加一套软件,就要去寻找80多块板子。
  
  当时,我和那个新员工都很愁,按照这种做法,这项任务3个星期根本就无法完成。B组负责带我们的两个员工,也表示比较无奈。
  
  郁闷过的第2天一早,我就直接找B组的老大谈话,“按照你们提供的这种方案,我们在三个星期内根本无法完成任务,而且还有诸多其他困难:1、部分板子是坏的;2、某些板子实验室里根本就没有;3、对设备不熟悉。”
  
  就这样,B组老大把组内相关骨干人员都叫过来开会,重新商讨了一套方案,并要求他们全力支持我们的工作。
  
  开了会后,B组的人就比较支持我们的工作了,启用新的方案后,还提前了1天时间把工作完成 : )
  
  这里我体会比较深的是:在做一份工作前,一定要弄清楚这项任务到底要做些什么、要怎么做、要做到什么程度,工作中还要定期汇报工作(基本上以日报、周报的形式,用邮件发送),如果出现了解决不了的困难,一定要向老大汇报,如果老大也解决不了,那他也不能责怪你无能 : )

六、工作中的陷阱
  在辞职前的几个月,有个师弟也是老乡X君,得知我做过自动化项目后,便来向我了解自动化测试相关的情况。
  
  从与X的聊天过程中了解到,他也正在做自动化,他们组测试的产品规模比较大,不过做自动化的只有两个新人,而且是使用一种新的GUI测试工具。他在给我讲他们具体工作时,了解到他们的自动化测试非常原始,就是针对一个用例录制一套脚本,几百个测试用例,大概录制几百个脚本,根本没有对公共进行提取,更别提有什么自动化测试框架了。X君与另外一个人,在自动化方面都是新手,没有相关经验,他们不知道这样做会给后期的维护带来多大的麻烦。而且他们主管也不太懂GUI测试的自动化,只是每天要他们汇报工作进度,期望在两个月内完成那几百个脚本。
  
  经过我细致询问后,我猜测他们做这项自动化工作,基本上是为了应付部门自动化考核而做的,而并非为了提高测试效率,保证产品质量。
  
  我也可以体谅X君主管的难处:测试组人力本来就紧张,而部门又要考核自动化指标,他只有弄两个人来应付一下部门的考核了。
  这样说来,X君和他另外一位同事就是受害者了,被安排做一件这么没意义的事情。对他们我只能表示同情了。
  
  对于这类BT主管吩咐的没啥意义的事情,我的体会就是能推掉不做就不做,如果实在推不掉,就完全按照他的意思做,他要怎么做就怎么做,要做成什么样就做成什么样。实在搞郁闷了就老板炒鱿鱼吧。
  
七、其他
  记得刚进公司那一阵,对我们新员工有这样那样的培训,估计转正前至少被培训了20门课吧。具体讲的都是产品知识、测试技能、编程方面的东东。那些讲课的老师水平也参差不齐,PPT写的水准也有好有坏。总体感觉就是那些培训是在浪费时间,如果自己看这些资料效果都要好很多。
  
  在转正前,作为新员工要给部门的“老”员工讲课,讲自己所学习过的知识,然后下面的“老”员工会发狂了似的问你问题。现在我感觉这种方式真的是一种非常好的检验方法,不但检验了你的学习情况还锻炼了你讲解PPT的能力。
  
  通过这种方式,我觉得自己在很多方面有提高:
  1、 写PPT的水平。后续工作中,写PPT汇报工作,做的是又快,又漂亮。
  2、 沟通能力。最初别人问我一个问题,我还没完全理解他的意图,就以自己的理解,淅沥哗啦的说了一堆别人不想知道的东东,搞得别人一头雾水。此后,别人每问我一个问题,我都会先把他的意图或意思搞搞清楚了,确认后,再以最精练的语言来回答他的问题。
  3、 懂就是懂,不懂就别乱说。记得最早“老”员工问我一个我自己不是很懂的问题,我通常是按自己的理解方式,跟他胡吹一通。结果他再一细问,我就傻了。知道就知道,不知道就别乱说,这点很重要,尤其是在参加面试的时候,如果自己不是很动,别人一问你就会露馅。
  
  写到这里,第一份工作的感受也写的差不多了。总的来说可以如此形容我这份工作:任务重、压力大、加班多,虽然公司也存在各种各样让人非常不爽的事情,但打心眼里我还是感谢它的——是它让我明白了什么是工作,锻炼了我的学习能力、抗压能力、沟通能力,培养了我的职业素养。虽然也有非常多的人在骂公司,但我希望它还是能越走越好!!!


 


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2011-06-13  
   1234
567891011
12131415161718
19202122232425
2627282930  

数据统计

  • 访问量: 7974
  • 日志数: 64
  • 建立时间: 2007-09-05
  • 更新时间: 2008-04-01

RSS订阅

Open Toolbar