一转眼，进入测试已经四个年头。这四年里我从一个对测试一无所知的新人，成长为一名软件测试工程师。这一路走来，有过奋斗，有过梦想，有过激情，但遗憾的是还没有成就。偶然听到《老男孩》这首歌的时候，我不得不感慨万千，“当初的愿望都实现了吗，事到如今只好祭奠吗”，入职时“曾经志在四方少年”如今也只能“羡慕南飞的燕”啦。有些悲凉了，幸好还没那么严重。现在，把我的一些成长经历分享给新入测试的同行，希望他们成为我所羡慕的“南飞的燕”，同时借此机会总结一下四年的测试生活，提升一下文字水平。
08年因为招聘会上的与北大青鸟的一位主考的交谈，开启了我对测试的兴趣。我可能永远都不会忘记那位同行的那些问题：“水杯的质量怎么测？”。在现在看来，这个问题如同问“你知道饭有几种吃法？”这样简单，可对于当时的我而言，却有点“丈二金刚摸不着头脑”，我只能把我所想的简单说了一下，比如往地上砸一下，往桌子上碰一下之类。我当时确实没有想到后来所知道的“验收标准测试”，“装其他液体测试”等等答案。后来他又问我，“你知道哪些测试工具？”。这下我彻底懵了，虽然是软件专业出身，但对于测试还真是没有太多概念，更不用提测试工具了。当这位主考发现我对于测试一无所知的时候，他很高兴并有些得意的告诉我“同学，你该来北大青鸟培训了。相信我们，没错的！”好了，这一篇可以翻过了。因为在这之后所发生的，我相信“你懂的”。其实这一段文字，我想说的是刚毕业那会儿，我真的很单纯，准确的说是测试的新人都是很单纯的，对于职业是需要一种引导的。
当毕业后，我拿着研究了小半年的关于性能测试和LoadRunner的毕业论文来到了XX。二面的时候，同样是一些问题，让我时至今日也感觉十分汗颜。当时测试主管问的是“你知道什么是QC吗？”。我很直接的回答“ QC是一种测试工具”。然后又问“那什么是QA呢？”，“还是工具！”。后来，我才知道原来QC指的是测试执行，而QA是质量保证。有时候我不得不把这次让我羞赧的问答同那个北大青鸟的主考官联系起来，因为是他引导了我去学习测试工具，花了半年的时间研究了LoadRunner和QC，导致我满脑子里想的都是工具。好了，这一篇也可以翻过了。这一段文字，我想说的是测试新人其实就是一张白纸，需要良好并且正确的引导，而我无疑最终成了涂鸦板。
入职后的一年里，和很多新入职的朋友一样，我对于测试技术和测试工具非常的迷恋，尤其迷恋上了自动化测试。那个时候烦是一有执行测试的机会，我就想把我所学到的工具用上。09年的时候为了测试一个项目的Webservice组件，我花了一个月的时间学习了QTP，然后用QTP录制Webservciestudio，达到了可以实现测试的效果。但最终因为测试时间有限以及测试部在其他测试组已经有了更成熟的Webservice测试框架，导致我的自动化测试方案没有能用起来。虽然当时我的这套测试方案并没有得到认同，而且被指出了很多不合适的地方，比如QTP是商业化工具不太提倡，QTP录制WebserviceStudio产生的这套脚本自身也不太稳定，要做参数化也需要测试人员具备一定的VBS使用基础，对于后期维护不利。但值得庆幸的是，当时我并没有放弃这套方案，而是把同事们给我提出的这些建议收集起来，改进到我的这套方案，并且最终在09年下半年完成了我的第一个完整的Webservice测试套件（基于VBS的Webservice自动化测试脚本）。到这里还没有结束，我并没有把这套方案应用到项目上来，因为当时大家还是迷恋于SOAPTest的那种强大功能。我悄悄的把这套方案写到了我在51testing上的博客上，并且定期的去修改它维护它，直到2010年，这套方案才最终顺利的应用到了一些项目的测试过程中，因为这个时候一些同事开始发现SOAPTest太强大了，以至于它的学习成本，使用难度，执行效率都不是很理想，对于大数据量的接口测试，他们需要一套简单而行之有效的测试方案。好了，这一篇可以翻过了。这一段文字，我想说的是在测试的路上可能会遇到各种各样的困难，但它们并不妨碍我们的成长，只要我们心中都有梦想，坚持住，总能雨后见晴天。
2010年的时候，我负责起一个测试小组的日常工作并且指导一名新同事的成长。这一年里，我几乎忘记了以前学习的所有工具的使用，因为我发现工具用的再好，始终离不开测试理论的支持。于是我在日常的工作中，投入了很多的时间去学习测试理论和测试管理知识，而忽视了技术方面的提高和巩固。以至于当我从测试小组管理回到测试执行的岗位上时，才猛然发现自己失去的太多。因为我们是技术性的岗位，技术和理论并不是两条平行线，而是纠缠在一起，相辅相成。回到测试执行岗位之后，想再做一些自动化测试相关的探索，已经是力不从心了。一切都得从头开始学，连自己写过的脚本都很难看懂。好了，这一篇可以艰难的翻过了。这一段文字，我想说的是如果你成为了测试组长，在繁忙的管理工作中，别忘了复习一下测试执行时期学习的那些知识，哪怕是一条用例设计的方法或者一段简单的测试脚本。
2011年，我了解到了很多的对于我来说相当“潮”的测试工作相关的名词：“Selenium”、“AIR”、“持续构建与持续集成”、“架构”（10年言必谈“框架”的时代已经过去了，现在是言必谈“架构”了。）、“渗透测试”、“缺陷分层”、“互联网云”、“Android”等等。这些词汇证明了一个伟大互联网测试时代的到来。而对于这个时代，我和除了我之外还有一些同行都已经是“奥特曼”了。当看到百度测试技术沙龙、淘宝测试技术嘉年华、互联网测试技术交会等一些国内有影响力的测试交流会上，来自各大企业的测试专家激情分享各自的测试经验的时候，我突然发现，在测试这份工作上，我是那么的短视。好了，这将是最后一篇了。我要分享我2011年的感悟了，感悟比我深刻的请直击点击文档右上方的叉按钮，感悟程度和我相同或者小于我的，那我们共勉吧。除了我以外还有很多的测试同行，可能都存在这样的一些问题。我们学习QTP、学习LoadRunner、学习SOAPUI，学习各种各样的先进的测试工具、先进的测试方法，但我们始终缺乏一种大局观，一种技术上的大局观。在移动互联网的时代，那就是一种移动互联网测试技术的大局观。举个例子来说：当听说苹果与adobe发生争执，而最终adobe决定弃移动Flash而去的时候，你是否想过苹果的手机里AIR应用将如何测试，移动浏览器的兼容性又如何进行测试，换句话说，你是否意识到这样的一个动态会造成怎么样的测试技术上的变更。那么如何去获取这种大局观呢，这就是我们部门的文化之一“改进”。那么又该从何处开始改进呢？我们需要打开我们的眼界，多去关注一些测试的动态，比如上面提到的百度测试技术沙龙、淘宝测试技术嘉年华、互联网测试技术交会等。从中了解那些测试大师们的思想，同时了解当前测试技术时代的变更。因为在这里，QTP、LoadRunner都不是测试技术，真正的测试技术是一种开放的、合适的、富于创造和激情的态度。