技术开发 频道

初出茅庐我的测试工程师之路



    【IT168 专稿】随着中国软件的不断发展,几年前软件程序员还是作为一项新兴的职业,但今天已经不断慢慢变成了所谓的"IT民工"。正好笔者这是其中的一员,经历了从测试工程师, 开发工程师到项目主管、再到项目经理的角色转变。有高兴,有失落,也有郁闷。“酸甜苦辣”这四种味道几乎涵盖了人生应有的全部体会。这里与大家分享从事测试工程师的几个印象深刻的瞬间以及感受,同时借此机会总结一下自已的得失。

    一.初体验测试的苦与闷
    毕业同年7月,我进入公司软件开发部工作。作为新员工参与的是测试工作。主要是进行手工执行功能测试。天天进行的是基础和简单的测试,不仅是工作量大的体力辛苦活,天天超时加班,而更大的挑战在于重复工作的闷。而且做测试比做开发工资和待遇相对差一些,这与我原来想成为程序员的目标有巨大的落差。

    应当承认,目前国内的软件测试工程师的地位和待遇相对较低,而且不少测试人员象我一样存在浮躁的心态。由于软件测试的根本是功能,所以测试人员需要非常多的精力投入到功能中,我刚开始时认为软件测试就是拿着鼠标乱点,很看不起测试的工作。其实每个人对于自己一些不太了解的事情总会有一些比较片面的看法。软件测试远远不是乱点能解决。乱点的确也算是一种测试,名词叫随机,但是如何从随机中找到规律,如何能遍历所有的功能,这都需要一些前人或自己总结出来的方法来指导测试,以后的痛苦经历使我认识到测试真不简单。

    这个时候,非常幸运的是我遇到了我的主管吴生,后来成为了我的良师益友。在我的经历中,让我感受最深的是每个人在成长的过程中,每个不同的阶段必须要有最少一个良师益友,这样你在生活中或者说工作才会有快速的成长。我现在也非常清楚记得吴生当时对我说的话:好好规划自己的路,不要跟着感觉走。你虽然想从事开发,但公司安排了你做测试,那么,就需要慎重考虑自己的轨迹。既然你入了测试这行业,就需要对该行业深入了解,不要感到失落和频繁跳槽,特别是不要为了苦闷和一点工资而转移阵地,从长远看,这点苦闷和钱根本不算什么,当你对一个行业有了体会和感觉,以后钱根本不是问题。频繁地动荡不是上策,如果只是浮躁而没有能够静下心来做事情和摸透这个行业,你就永远是新手。

    吴生的建议认为虽然软件测试是个可以很快入门的辛苦体力活,门槛不高,在公司待遇和地位相对差一点。但是,不要认为什么人都可以做好软件测试,因为会做和做好是两个概念。对于刚刚毕业的学生,如果希望今后从事软件开发,那么,先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员,如果改行做测试,更容易提高技术。

    正是吴生的谆谆教诲使我静下心来,对软件测试有了新的认识。平时在和朋友沟通中我也了解到有很多测试工程师是由于不能从事其它工作才从事测试的,因而工作中也是不断抱怨待遇、团队环境等不能满足自己的要求。我也曾经对软件测试很轻视,这也是大多数程序员的心态,程序员最讲究“编程才是硬道理”。我在测试工作中应用软件测试工具,方法,理论,技术等,使我深刻体会到软件测试的重要性和趣味性。此时,我才跳出了“小程序员”的圈子,以软件系统工程的更大视角审视软件测试这项工作。在此建议测试工程师,如果选择了这个行业,就应该认真地对待工作,抱怨永远解决不了问题。

    二.掌握测试体系,感受登堂入室之甜
    我在与测试同行朋友接触中了解到现在许多公司软件测试还不完善,往往测试人员还是依据本能、靠感觉、和简单的测试文档来做软件测试。如果像用户那样只是通过使用来发现Bug,这不是真正的测试,这只是一种最基本的测试,只能发现一般用户的问题。单调和重复的工作,再加上测试的压力容易形成对测试的失落和郁闷。

    对软件测试而言,我认为国内的软件企业对测试的重视程度还不够,但毋庸置疑,测试是软件产品线上和开发同等重要的。我的观点是:把软件做出来不难,但是要把它做好,必须建立系统化,流程化的测试体系。只有掌握了系统的测试观念,才会领悟到测试的渗入心田的甜。

    软件项目是一个系统工程,软件质量牵扯到多个部门和人员,需求分析,设计,编码等各个环节和过程。软件测试是项目开发中不可缺少的环节,软件测试不是功能较多的,因为不可能发现全部的软件缺陷。但测试应该是贯穿于软件开发的整个周期,编程只是软件开发的一个环节。但往往大家非常重视软件编程,把测试作为编程后的一个辅助环节,这是典型的本末倒置。

    我在测试过程中明白到与具体测试技术相比,掌握测试的核心思想比具体技术更重要。软件测试不是孤立的简单活动和过程,测试的最高境界在于建立体系的测试流程,运用最简单有效的测试技术,最大限度的发现软件缺陷。一个完善的测试流程应该是从测试计划--测试用例的编写--执行测试--测试报告编写等。

    建立体系的测试流程和缺陷管理是重中之重,我的测试经历认为可以从以下这几方面来掌握测试体系之甜和美:

    1.制定符合软件开发计划的测试计划
    软件测试计划是一个老生常谈的问题,一般来说计划的目的是用来识别任务,分析风险,规划资源和确定进度。拟定软件测试计划需要测试人员的积极参与,这是因为主项目计划已经确定了整体项目的一个时间框架,软件测试作为阶段工作必须服从时间和资源上的约定。

    在实际的工作中,我们总是不自觉的在调整软件测试的计划,比如在时间紧张的情况下,通常优先完成重要功能的测试。所以在接收到一项测试任务的时候,需要根据主项目计划的时间来确定测试计划。确定计划并进行任务的划分,简单的说就是分解测试任务。分解任务有两个方面的目的,一个是识别子任务,二是方便估算资源的需求。

    2. 准确理解需求
    我认为测试首先要准确的了解系统是干什么的,要达到一个什么样的效果。测试不单是各个功能单独的测试,最好能够从整体上了解整个系统的结构,流程等等。理解需求包括两方面:一个是从我们程序的角度,即我们的详细设计文档所描述的具体什么表,什么字段等来了解。了解什么功能的实现跟那些表,那些字段有关,做了某些操作后,这些表的字段应该发生什么样的变化。这些都是建立在对系统的深刻理解的基础上面的。另一方面,从客户哪个角度去理解需求。

    3.测试重点要分明
    测试整个系统的过程中,对一些关键的重要功能测试,必须重视它,反复进行测试。根据可能出现的种种情况进行测试。因为这些关键的部分有问题会引起其他相关的一连串错误。测试的可以通过单元测试,集成测试和压力测试等,还有白盒测试,黑盒测试等。对整个系统的全局的了解,整个测试流程怎么走必须心中有数。通过测试驱动开发,从而提高软件的质量。

    4、测试案例的准备和保留
    对于系统整个流程的各个功能,每个功能的各种应用的情形,准备好相应的情形的数据(做好备份),以备修改好后可以重现或检查。理想状态下应有完整的记录说明,什么样的数据是做什么测试用的。有些经常要用到的测试,最好能够另外编写很简单的测试驱动程序。可以写些专门用于校对数据准确性的小程序。案例的准备数据和应用正确结果对于回归测试特别有意义。

    5.版本控制
    对于版本控制这个概念大家都不陌生,它是软件配置管理的初期表现形式。测试版本控制简单的说就是测试版本明确的标识说明。我在测试中认为版本号码的用处很重要,例如在填写错误报告的时候往往需要提供发现错误的那个版本。在做缺陷分析时,我们可以利用版本号来区别缺陷和判断缺陷的发展趋势。测试版本是开发人员和测试人员之间交流的有效形式。测试人员可以通过这份文档了解到当前的测试版本中就上一版本而言有那些显著的变化。


    三.测试生涯的几个片段
    有人说,开发人员找自己作品的错误象杀自己的孩子,而我们测试就要扮演杀他们孩子的人,因此沟通能力是很重要的。这里说说我在测试生涯的几个值得注意的小片段。希望对大家有启发。

    在我的测试经历中,细心是测试工程师的第一个基本素质,细心对待每一个可能的BUG、细心对待每一段被检查的代码,细心对待每一个撰写的BUG报告。很多测试工作有时候显得非常枯燥,需要很大的细心才可以做好。如果比较浮躁,这将让很多软件缺陷从眼前逃过。

    另一个让我深有感触的是耐心,我常常需要不厌其烦地向开发人员解释一个BUG,让他认识到BUG的重要性。其实想想也很正常,对任何人来说,被人指出自己的缺点和不足都不是让人舒服的事情。因此,一点不耐烦的情绪就可能引起对方很大的反感,给自己的工作带来不必要的麻烦。开发工程师一般都处在较大的工作压力下,他们的考核指标很大程度上是已完成的代码,所以在工作任务紧张的时候,对于测试工程师报上来的BUG会拖延解决甚至是推脱,给测试工程师的感觉就是很不合作。那么在这个时候,我们就需要设身处地的为对方着想了,每个人都会为自己的工作在内心排定优先级,如果他认为解决你发现的BUG不是重要的事情,那么有可能是我们并没有向他解释清楚这个BUG的严重程度。发现BUG是我们的责任,敦促BUG得到解决是我们更重要的责任,因此,我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度,和他一起排定BUG的优先级别并确定解决的时间。

    在与开发人员沟通相处中,另一个给我的教训是不要嘲笑你所发现的BUG,即使是非常愚蠢的错误也绝对不要嘲笑,对别人的工作始终应该尊重。如果觉得有必要提醒他不再犯一些经常犯的错误,可以采用这样的方式:编写一份测试过程中发现的开发人员常犯错误的文档(记住,千万不要写上谁犯了这些错误),用轻松的口气调侃一下,发送给开发人员。这种方法我采用过,开发人员都能很快接受。

    同时,特别提醒注意的是不要在背后评论开发工程师的技术能力,这个绝对是非常忌讳的事情,一时的口舌之快或许会使我们永远不再能同他良好地合作,要知道,开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则,也应该是做人的准则。

    写了这么多,其实关键的就是两点:多从别人的角度去想想,所谓"换位思考",多尊重对方就一定能得到对方的尊重与配合。其次是加强和开发工程师的沟通,让他清楚地认识到我们的工作对他的价值,我们发现的每一个BUG的重要性。我一直认为,一个好的测试工程师一定是在公司里被所有人尊重的快乐分子,我经常都记得提醒自己:尊重对方。开发和测试是同一条战线的人,共同的目标是软件质量。


    四.测试的几点经验总结
    古人云:抱一守终,必有所得。这里与大家分享一些测试的总结心得。
    1) 80/20原则应用于软件测试。
    柏拉图原则暗示着测试发现的错误中的80%很可能起源于程序模块中的 20 %。这个原则告诉我们,如果想使软件测试有效地话,记住要常常光临其高危多发“地段”。在那里发现软件缺陷的可能性会大很多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷,而愚蠢的测试人员却仍在漫无目的地到处搜寻。

    2)在进行测试前,我们需要先将所要测试的功能细分,填写《测试功能细分表》,有针对性的运行功能测试案例,逐个对每个功能细分点进行测试。在每次运行测试案例之前,明确此次运行的目的和预期的输出结果,并要做好记录。测试应从“小规模”开始,逐步转向“大规模”。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。

    3)要善于总结,在测试过程中发现的所有问题,异常情况,发现程序开发人员易犯,常犯的错误,各种有价值的经验教训,使用测试工具时的心得等等,我们都需要记录在笔记本或者电脑上。这些都将是今后工作中可以参照的珍贵资料,同时也会成为自己的宝贵经验,妥善保存一切测试过程文档,便于测试的重现,事后的跟踪,工作的回溯,总结和报告。

    4)对于测试工程师而言还有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以测试工程师按轻重缓急分类“ 测什么和何时测 ”是个重要职责。

    软件测试是软件开发中的重中之重,软件测试是一件很辛苦的事,只有在工作中多总结,才能找到符合自己的方式方法,才能在工作中事半功倍。同时,测试也很枯燥,而且有许多人认为“一点技术含量都没有”。我认为现在中国缺乏的不只是软件编程大师,而是软件测试大师。
0
相关文章