一名测试工程师的工作经历

我的测试经历（一）

从事软件测试行业至今已经有四年半的时间了，在这四年半的时间里，我已经从助理测试员成长为一名专业的软件测试设计师，在这里我只想通过自己的工作经历为刚刚从事这个行业或者想从事这个行业的新人提供一些制定未来发展目标的参考。

我的第一家公司是个只有几十号人的私企，专门成立了软件测试部，这非常难得。作为一名应届生，我能够从事自己喜欢的专业工作也很幸运，我的工作是在对软件测试“零”了解的基础上，从摸索学习中开始的。

刚开始工作的时候，没有人给予专业方面的指导，因为每个人都有自己所负责的工作，抽出时间来指导你就会耽误别人的时间，所以，学会“怎样自学”才是最基本的生存之道，这种能力是在大学的课堂上学不到的，也正是因为这样，有很多人以坐以待毙的方式等待成手的指导放弃了自己学习的机会，最终导致被淘汰出局。几年前关于软件测试方面的书籍寥寥无几1，网络上可参考的资源也少得可怜，经验几乎都是从动手实践中得来的。最初接触软件的时候什么都是新奇的，熟练的掌握该软件的所有操作步骤是首要任务，放下身段把自己当成什么都不懂的普通用户，仔细的操作它把不太了解的细节或是操作不通的地方记录下来。那么，下一步就是跟熟悉这个软件的所有人去了解之前的操作应得出的正确结果，重点了解那些被记录下来的问题，明白什么样的结果才是这个软件所需要的。后来我才明白做到这两项，其实就已经朝着软件测试的专业领域迈进了一步。我从工作的第一天起就养成了记笔记的习惯（手写的那种），后来证明这种习惯对我的专业技术成长起到了非常重要的作用。

我的工作任务就是：操作软件à从操作中找出BUG（错误）à告诉开发人员修改à重现BUGà告诉开发人员修改à验证修改好的BUG，在这种工作方式中我不会去关心BUG发生的原因，修正这种BUG为什么会带来更多的问题及什么是测试用例。当时我所负责的工作其实更应该称为“软件测试执行”，因为执行测试的人员不会去考虑软件操作以外的事情。后来单独负责起一个小软件的测试时，在非常紧急的情况下，要求按照测试用例执行（我们以前都是手工执行测试，没有测试用例可参照），写用例的时间只有两个小时，写好后马上开始测试，没有办法我硬着头皮第一次写了测试用例（虽然现在想起来只能称之为测试大纲的东西），但仅仅是简单的用例，却对我的测试工作起到了非常重要的作用。它使我的测试方向更清楚，发现BUG以后能够更好的协助开发人员定位问题，当然修改重现BUG的时间、修改BUG的时间也大大缩短了。这一次的甜头使我认识到了“测试用例”的重要性，所以每当负责某一软件产品测试之前，我都会自己列出相关的测试大纲，在测试的过程中逐渐去完善并且执行，在最后的两个版本中完全执行一次，经过时间的累积，选择了合适的模板后，成熟的测试用例出炉了。在执行的过程中，我考虑一些测试执行速度与代码开发速度等软件产品相关因素的协调结果，这个时期我才进入了初级“黑盒测试阶段”，上述考虑到的那些问题就是最基本的“测试流程”，在技术角度讲我又向前迈进了一步。

打这以后，网络成为了我重要的信息来源，一有时间我就会从网上寻找一些软件测试的相关资料来充实自己，从中我了解到了“软件需求”、“测试管理”和“自动化测试”的概念，我们已经采用了TestDirect来进行测试管理，所以我只尝试了使用WinRunner来执行测试，至于“软件需求”是我后来才领悟到的。对某个软件操作的熟练了，并不能证明了解该软件的需求，只能说明工作的时间长了对这个软件的特性有了一定的了解。在很多情况下，没有明确的文档来定义某个软件产品的需求，积累了一定经验的测试人员会根据自己的工作心得来判断软件是否符合客户群体的需要。这种工作经验的积累不仅体现在软件测试技术方面，更多的将会体现在软件专业领域上，比如说从事网络相关软件的测试工作就得了解相关网络知识、网络技术动态等等。扩展了行业知识，才会对该行业的软件功能特性的制定具有一定的发言权。在这里我还要啰嗦几句，英语真的非常重要，因为很多技术资料都是英文的，毕竟软件测试是国外兴起的行业，及时的信息一般都不会被翻译成汉语，学好英语很有助于专业水平的提高，同时再奉劝几句，对于工具大家最好还是用英文版的好。我的测试经历（二）

我的第二个工作单位，是规模较大的软件公司。与以前不同的是，新的工作单位是做某一类产品的研发而不是单指某一个产品，在产品立项之前，会经过严密的市场考核，N多次需求讨论才会确定最终的开发方案，这两个任务做完以后PRD文档、需求文档才会陆续出台。这个过程在下面的叙述中会更加详细的。

相信很多在小企业工作过，后来又跳到大型企业的人都会遇到这种尴尬的局面 “小企业来的，没见过世面，什么技术啊、流程啊都不懂”。在这种时候大多数人都会热切的去表现自己，很少会冷静下来做这样的事情：一、分列出自己以往所担任的工作、自己的角色；二、自己在项目经验和技术能力方面的优、缺点；三、目前的项目组的工作性质、需要的人员角色；四、目前所需要的项目经验和技术能力。当然上述四个方面也可以加以细化，列出这些以后，自己的优势与劣势就显而易见了。还有一种方法，就是查相关的岗位能力字典，大多数的大型企业都会制定比较完善的岗位能力手册，不妨查查看，自己的实际情况符合哪些条款，哪些是有待加强和学习的，了解自身的缺点进步才能更快一些！

我最初的工作任务是了解产品的用户手册（因为涉及保密的问题概要设计文档和需求设计文档必须在转正后才能看到），阅读产品手册是一项非常枯燥乏味的工作，它的描述并不能帮助我理解产品的功能特性，但是却帮助我了解了产品的操作方法，对以后的测试很有帮助。很幸运的是在入职半个月以后，正赶上个人工作季度总结的评估，每个人都会根据一本“个人行为能力手册”来评估自己在业务、技术等方面的分数，也就是从这个时候起，我认真的看了他们对“软件测试工程师”这一职位的要求。的确，自己还有很多不足之处，比如说我欠缺相关的行业知识，以往没有考虑过行业知识会对测试有什么影响，在这方面并没有下功夫去学习，既然现在的工作对行业知识有所要求，那就必须去了解它了。接下来的一个半月的时间，我是在学习行业知识中度过的，每天都是自己在看书几乎不同其他人交流，当知识积累到一定程度的时候，我才体会到行业知识的积累对于测试来说真是如虎添冀，它能够更加明确测试的目的，减少测试中的盲区，这就好比一个人在黑夜中行走，没有灯光的指引全凭着感觉，那么碰壁就在所难免了，行业知识就好比是黑夜中的灯火，指引前进的方向。在这期间我经历了两次业务考核答辩，有点像大学毕业时的那种，答辩内容是根据每个月的学习内容来确定的，我从第一次的自信满满到第二次的尴尬落逃，心理上承受了相当大的落差，反思这两个月的学习情况，最大的失败就是从不主动与他人交流，其中也包括我自己的导师（新员工都有一名老员工带领，这就是导师制度），对自己的学习能力过度的自信，不去了解学习的重点，自己对某一知识点理解有偏差的地方，甚至是不明白的问题就那么一带而过不去深究。我犯的这个错误是十分不可取的，过度的自信就是自负，一个人的能力是有限的，特别是在学习新知识的时候，虚心请教有经验的老员工会得到事半功倍的效果。在第三个月中我与导师一起补充由于第二个月学习效果不佳而欠缺的行业知识，同时也开始了测试执行的工作。经过我们一个月的共同努力，终于在第三次转正答辩的时候获得了领导的好评，记得当时我的导师比我还要紧张，答辩完毕看到领导的笑脸时我们俩都松了一口气，从此，我开始了新的工作旅程。

我的测试经历（二）

刚开始的一个月就是按照现成的测试用例去执行，但是慢慢的我发现，原有的测试用例不太适用于当前的测试任务，一是测试用例覆盖率1较低，如果完全按照测试用例来执行，会有很多遗漏的功能点走不到；二是执行流程不好，比如功能点1执行完毕以后，执行功能点2会节省测试时间，而且从功能特性的角度来讲流程更顺畅，但是原有的用例却没有按照这个顺序来编写；三是用例中关于操作步骤和期望结果的描述不明确，不易于理解或是容易产生误解。根据上述三个问题，我决定从一个较小的功能模块着手重新设计测试用例2。我先是整理出了该模块的功能特性，然后做了一个类似连线的表格，这样就明确了各功能点之间的关联，对于确定功能点测试顺序有很大帮助，接下来就是确认测试用例的分类了，我将测试用例大概分成如下四类：基本功能测试用例，异常情况测试用例，关联性测试用例和压力测试用例。基本功能测试用例，顾名思义，就是指测试某一具体模块的常用功能，用以验证功能的完整性、可用性、可执行性；异常情况测试用例，是指在网络、数据库连接异常等突发状态下软件的稳定性；关联性测试用例，是验证有功能关联关系的各个模块之间，执行测试后的运行结果；压力测试，用于验证大数据量的情况下软件的稳定性。

测试用例刚刚完成，我们就进行了交差测试，新接手的测试人员说新用例比以前的老用例易于理解操作起来很方便，而且功能点含盖得很全面，在周例会上他讲了自己的看法，并且把新的测试用例拿给大家评审，最后得到了大家的首肯“可以应用到系统测试执行当中”。这次的成功，为我以后的工作得到认可奠定了坚实的基础。接下来我对核心模块的测试用例进行了修改，仍沿续以往的风格，但采用了不同的思路，因为第一次的成功，测试负责人对修改测试用例的工作很重视，每完成一个模块都会召集大家进行评审，经过三次评审以后，大家对我的用例编写水平给予了充分的肯定，在测试管理工具上给我分配了修改测试用例的权限。我，在软件测试工作师的道路上又前进了一步。

说一下当时我们的工作情况，我们项目组做的产品处于研发阶段，一直没有面向市场营销，虽然部门内部制定了相关的时间表，但时间点执行并不是十分严格，工作用时相对比较宽欲。就测试这方面来讲，我们黑盒测试人员只负责系统测试，每一版本的测试分为接收测试（0.5-1工作日）、系统测试（12工作日）、发散测试（3工作日）三个阶段。接收测试阶段，验证产品功能的完整性，评估产品质量是否达到系统测试标准，如果已达标则进入系统测试阶段，否则返回给开发人员修改；系统测试阶段，全面的执行各个子模块的测试用例，检查各个功能点；发散测试阶段（我们也戏称为发疯测试），不考虑测试用例，进行测试用例外的各种尝试。我有很多灵感都是来自于发散测试阶段，因为没有了测试用例的约束，想象的空间得到充分发挥，很多意想不到的思路就产生了。持续一段时间只执行某项固定的工作，很容易使人产生倦怠的情绪让工作失去原有的生气，测试工作尤其如此，所以我觉得测试人员应该随时抱着一颗好奇心，发掘新奇的东西，这样才会找出更多的问题。

在工作的同时，我也跟开发人员学到了不少的东西，他们教我一些浏览代码的技巧，当然也要求测试人员有一定的编程功底。在我对代码就比较熟悉以后，偶尔会帮助开发人员定位BUG或是提供一些修改意见。记得有一次，我发现了一个能够导致整个软件系统死锁无法操作的BUG，开发人员用了两个多小时修改了很多次，问题还是没有解决，情绪有些急躁，后来我跟他一起看了那段代码，我发现是一个变量的返回值写错了，纠正了这个小小的错误，上述看似很严重的问题就解决了。

部门领导为了提高大家的测试技术，特别组织了一次为期一个月的培训，包括沟通技巧、黑盒测试技术3、性能测试、自动化测试工具四门课程。

其中沟通技巧这门课是同时面向测试人员与开发人员的，讲述了互相矛盾、互相对立的两个不同职位的人员应该采用什么样的沟通手段，很高兴的是讲师非常同意我“测试人员与开发人员是朋友”的观点，向他人微笑得到的回报同样也是微笑，与“予人玫瑰手有余香”是同样的道理，因为不论是开发还是测试，都是团队的成员，那么只有朋友才会一心一意为着共同的利益和目标努力。这次培训也让我第一次明白团队的确切含义，一个团队小到可以说具有相同工作性质的团体，比如一个项目组中的测试组可以叫一个团队；有共同前进目标的团体，比如一个部门也可以称为团队；再或者有共同经济利益的团体，比如一个公司。不同规模的团体有着不同的利益，小利益服从大利益才会获得更多的经济效益，所以那些一味把小团队的地位放在首位，不去考虑大团队的利益的人，最终会被团队所淘汰。

另外两门课程都是面向测试的专业技术培训，不是很系统，但知识面却很广。我比较感兴趣的是黑盒测试技术和自动化测试工具这两门课。关于黑盒测试技术，因为讲师并不善长此项，所以培训的内容基本都是照本宣科，理论与实践完全脱轨，并且远不及网络上的资料来得全面，对于工作没有什么实质性的帮助。自动化测试技术的课讲得很生动，主要介绍QTP（QuickTest Professional）4和LR（LoadRunner）的使用，只可惜，因为我们的产品性质和质量的原因，一直没有机会在实践中系统的应用。