从事软件测试行业至今已经有四年半的时间了，在这四年半的时间里，我已经从助理测试员成长为一名专业的软件测试设计师，在这里我只想通过自己的工作经历为刚刚从事这个行业或者想从事这个行业的新人提供一些制定未来发展目标的参考。
我的第一家公司是个只有几十号人的私企，专门成立了软件测试部，这非常难得。作为一名应届生，我能够从事自己喜欢的专业工作也很幸运，我的工作是在对软件测试“零”了解的基础上，从摸索学习中开始的。
刚开始工作的时候，没有人给予专业方面的指导，因为每个人都有自己所负责的工作，抽出时间来指导你就会耽误别人的时间，所以，学会“怎样自学”才是最基本的生存之道，这种能力是在大学的课堂上学不到的，也正是因为这样，有很多人以坐以待毙的方式等待成手的指导放弃了自己学习的机会，最终导致被淘汰出局。几年前关于软件测试方面的书籍寥寥无几，网络上可参考的资源也少得可怜，经验几乎都是从动手实践中得来的。最初接触软件的时候什么都是新奇的，熟练的掌握该软件的所有操作步骤是首要任务，放下身段把自己当成什么都不懂的普通用户，仔细的操作它把不太了解的细节或是操作不通的地方记录下来。那么，下一步就是跟熟悉这个软件的所有人去了解之前的操作应得出的正确结果，重点了解那些被记录下来的问题，明白什么样的结果才是这个软件所需要的。后来我才明白做到这两项，其实就已经朝着软件测试的专业领域迈进了一步。我从工作的第一天起就养成了记笔记的习惯（手写的那种），后来证明这种习惯对我的专业技术成长起到了非常重要的作用。
我的工作任务就是：操作软件à从操作中找出BUG（错误）告诉开发人员修改à重现BUGà告诉开发人员修改à验证修改好的BUG，在这种工作方式中我不会去关心BUG发生的原因，修正这种BUG为什么会带来更多的问题及什么是测试用例。当时我所负责的工作其实更应该称为“软件测试执行”，因为执行测试的人员不会去考虑软件操作以外的事情。后来单独负责起一个小软件的测试时，在非常紧急的情况下，要求按照测试用例执行（我们以前都是手工执行测试，没有测试用例可参照），写用例的时间只有两个小时，写好后马上开始测试，没有办法我硬着头皮第一次写了测试用例（虽然现在想起来只能称之为测试大纲的东西），但仅仅是简单的用例，却对我的测试工作起到了非常重要的作用。它使我的测试方向更清楚，发现BUG以后能够更好的协助开发人员定位问题，当然修改重现BUG的时间、修改BUG的时间也大大缩短了。这一次的甜头使我认识到了“测试用例”的重要性，所以每当负责某一软件产品测试之前，我都会自己列出相关的测试大纲，在测试的过程中逐渐去完善并且执行，在最后的两个版本中完全执行一次，经过时间的累积，选择了合适的模板后，成熟的测试用例出炉了。在执行的过程中，我考虑一些测试执行速度与代码开发速度等软件产品相关因素的协调结果，这个时期我才进入了初级“黑盒测试阶段”，上述考虑到的那些问题就是最基本的“测试流程”，在技术角度讲我又向前迈进了一步。
打这以后，网络成为了我重要的信息来源，一有时间我就会从网上寻找一些软件测试的相关资料来充实自己，从中我了解到了“软件需求”、“测试管理”和“自动化测试”的概念，我们已经采用了TestDirect来进行测试管理，所以我只尝试了使用WinRunner来执行测试，至于“软件需求”是我后来才领悟到的。对某个软件操作的熟练了，并不能证明了解该软件的需求，只能说明工作的时间长了对这个软件的特性有了一定的了解。在很多情况下，没有明确的文档来定义某个软件产品的需求，积累了一定经验的测试人员会根据自己的工作心得来判断软件是否符合客户群体的需要。这种工作经验的积累不仅体现在软件测试技术方面，更多的将会体现在软件专业领域上，比如说从事网络相关软件的测试工作就得了解相关网络知识、网络技术动态等等。扩展了行业知识，才会对该行业的软件功能特性的制定具有一定的发言权。在这里我还要啰嗦几句，英语真的非常重要，因为很多技术资料都是英文的，毕竟软件测试是国外兴起的行业，及时的信息一般都不会被翻译成汉语，学好英语很有助于专业水平的提高，同时再奉劝几句，对于工具大家最好还是用英文版的好。
①在这里推荐两本适合新手阅读的书籍：
《软件测试》
作者：（美）Ron Patton
译者：周予滨姚静
出版社：机械工业出版社
原出版社： SAMS
《软件测试》
作者：[美]Paul C.Jorgensen
译者：韩柯杜旭涛
出版社：机械工业出版社
原出版社： CRC
我的测试经历（二）
我的第二个工作单位，是规模较大的软件公司。与以前不同的是，新的工作单位是做某一类产品的研发而不是单指某一个产品，在产品立项之前，会经过严密的市场考核，N多次需求讨论才会确定最终的开发方案，这两个任务做完以后PRD文档、需求文档才会陆续出台。这个过程在下面的叙述中会更加详细的。
相信很多在小企业工作过，后来又跳到大型企业的人都会遇到这种尴尬的局面 “小企业来的，没见过世面，什么技术啊、流程啊都不懂”。在这种时候大多数人都会热切的去表现自己，很少会冷静下来做这样的事情：一、分列出自己以往所担任的工作、自己的角色；二、自己在项目经验和技术能力方面的优、缺点；三、目前的项目组的工作性质、需要的人员角色；四、目前所需要的项目经验和技术能力。当然上述四个方面也可以加以细化，列出这些以后，自己的优势与劣势就显而易见了。还有一种方法，就是查相关的岗位能力字典，大多数的大型企业都会制定比较完善的岗位能力手册，不妨查查看，自己的实际情况符合哪些条款，哪些是有待加强和学习的，了解自身的缺点进步才能更快一些！
我最初的工作任务是了解产品的用户手册（因为涉及保密的问题概要设计文档和需求设计文档必须在转正后才能看到），阅读产品手册是一项非常枯燥乏味的工作，它的描述并不能帮助我理解产品的功能特性，但是却帮助我了解了产品的操作方法，对以后的测试很有帮助。很幸运的是在入职半个月以后，正赶上个人工作季度总结的评估，每个人都会根据一本“个人行为能力手册”来评估自己在业务、技术等方面的分数，也就是从这个时候起，我认真的看了他们对“软件测试工程师”这一职位的要求。的确，自己还有很多不足之处，比如说我欠缺相关的行业知识，以往没有考虑过行业知识会对测试有什么影响，在这方面并没有下功夫去学习，既然现在的工作对行业知识有所要求，那就必须去了解它了。接下来的一个半月的时间，我是在学习行业知识中度过的，每天都是自己在看书几乎不同其他人交流，当知识积累到一定程度的时候，我才体会到行业知识的积累对于测试来说真是如虎添冀，它能够更加明确测试的目的，减少测试中的盲区，这就好比一个人在黑夜中行走，没有灯光的指引全凭着感觉，那么碰壁就在所难免了，行业知识就好比是黑夜中的灯火，指引前进的方向。在这期间我经历了两次业务考核答辩，有点像大学毕业时的那种，答辩内容是根据每个月的学习内容来确定的，我从第一次的自信满满到第二次的尴尬落逃，心理上承受了相当大的落差，反思这两个月的学习情况，最大的失败就是从不主动与他人交流，其中也包括我自己的导师（新员工都有一名老员工带领，这就是导师制度），对自己的学习能力过度的自信，不去了解学习的重点，自己对某一知识点理解有偏差的地方，甚至是不明白的问题就那么一带而过不去深究。我犯的这个错误是十分不可取的，过度的自信就是自负，一个人的能力是有限的，特别是在学习新知识的时候，虚心请教有经验的老员工会得到事半功倍的效果。在第三个月中我与导师一起补充由于第二个月学习效果不佳而欠缺的行业知识，同时也开始了测试执行的工作。经过我们一个月的共同努力，终于在第三次转正答辩的时候获得了领导的好评，记得当时我的导师比我还要紧张，答辩完毕看到领导的笑脸时我们俩都松了一口气，从此，我开始了新的工作旅程。
