从事软件测试以来

大三暑期就出来混了，待过两家实习公司。第一家实习公司算是强制性要去的，做了四个月开发。第二家公司是自个应聘的，面试的时候是做开发，后来转做测试。

去第一家公司实习的时候还好，有师兄师姐还有同学在一起，第二家公司情况就不一样了。虽然是实习生但是也没有人带，所有软件测试知识都要自学。好在有开发基础，所以虽然软件测试不是本专业（以软件测试作为一个专业的学校估计也很少吧），但是对于软件方面的知识还是了解得比较多的，而且在校时是专门学习java和C#，经常会模仿做一些小项目，所以编程能力也还可以。因为有了这些基础，所以在决定做软件测试之后，我就开始对自动化测试蠢蠢欲动，一直想搞点成绩出来。

因为在学校辅修的软件测试课程里认识了两款测试工具，一个是性能测试工具LR，一个是功能测试工具QTP。我首先学习的是LR，学了差不多一个月，基本上是可以录制脚本、手动关联、参数化、IP诈骗、添加常用的监控器等等，也会一些测试报告的分析，但是都只停留在学习的层面上，没有实战的环境和条件，所以感觉很难再深入学习下去。

后来又学习了QTP。刚开始学习QTP的时候，才学习了一周，就很自以为是的觉得自己已经掌握了。因为那时候的学习就是按书上的步骤首先录制了脚本，然后参数化一下，再加一些检查点之类的，然后回放无报错。所以那时候觉得QTP超级容易，一下子就能学会。

再后来，因为对这家公司不是很满意（因为实习公司只有我一个实习生在搞测试，对我基本是放养状态，无人问津，连BUG系统都没有，提交BUG都是每次我测完之后才以word形式发给研发人员修改），所以，经过思考，毕业后我还是提交了离职申请。

后来就来了现在的公司，来公司的时候也只有我搞测试，但是他们强调会招一个资历比较老的人来带我，所以我也就很淡定地来上班了。一个月后，招了一个跟我一样的应届生，觉得比较无耐。

所以后来测试方面的知识还是自学，不过新的项目经理经验也算比较丰富，会告诉我要学习什么东西。比如，我刚来的时候公司里也没有BUG管理系统，连SVN也没有（因为是新成立的部门），项目经理会让我对现在比较流行的几个BUG管理系统进行选型。我首先搭建了BUBZILLA（因为以前也稍为看了一个这个系统，算是我接触的第一个BUG管理系统），几个老大看了一下界面之后都觉得不好用，弃之。再后来搭建了JIRA，大家就都决定用JIRA。然后我就自己学习一些JIRA配置方面的知识，让JIRA投入使用。这时候的JIRA配置到的都是一些必要的配置，后来又招了一个测试主管（只上了一个月班就走了，林子小留不了大鸟呀），这一个月时间里他不但给我们出了很多规范文档，还配置了并共享了JIRA桌面，那时候我才发现JIRA的桌面是可以这么定制的。后来他又重新配置了BUG流程，我更加感叹原来JIRA里面好多东西都是可以定制的。

之后项目经理还让我配置了部门的SVN。以前在学校也做过项目，但是都是单打独斗式的一个人完成项目中所有设计，对版本管理一点概念都没有。所以我又学习了版本管理的知识，安装了SVN，给所有项目分配了目录，并要根据不同的人员角色设置了不同的权限。

后来我还配置了TestLink，但是他们都觉得不好用（可能是因为还不会用），所以TestLink没有投入使用。再后来项目进入开发阶段，我又重抬QTP的学习热情，但是因为项目界面非常不稳定（是政府项目，每给一个领导审批，界面都会大修改，设计师都换了三批，界面版本是无数个），只能取消进行QTP自动化测试的想法，老老实实地进行手工测试。也就是那时我才知道QTP只适用于界面变动不大的项目，或者是版本已经相当稳定的项目，否则自动化测试反而会降低测试的效率（因为改脚本就占去了相当多的时间）。

  那个政府项目结束后，我还进入了另一个项目组，这个项目是公司的运营管理项目，界面都比较稳定，功能模块非常多。这个项目在我之前，都只是叫两个文员简单随便点点地测一下，并未经过完整专业的测试。所以进入项目组后，在经理的要求下，我马上补充了项目的测试方案、测试计划、测试用例等测试文档，并对项目进行了一次比较完整的手工测试，其间发现了差不多两百个BUG。我提交测试报告给经理看后，经理说看来还是需要专业点的人来测一下呀，让我小小的得瑟了一下。一个月后，项目在公司中投入使用，受到了领导的嘉奖，但是也提出了不少修改意见，并新增了好几个大模块。所以这个项目直到现在还是边开发边使用的状态。

  项目上线后，也从未停止过测试，但是相对的没有那么忙了。所以我决定对项目中已经比较稳定的模块进行自动化测试。

虽然说QTP比其他工具容易学点，但是真正投入使用的时候还是走了不少弯路。刚开始写脚本的时候我就按以前学的那样子，通过录制回放等完成，这些基本上不花什么时间（只录制项目业务的正常操作流程），看着脚本在自动的运行的时候，心里不知多美！不久后项目又发布了新版本，运行脚本发现老报错，老找不到对象，但是那个元素明明是在原来的位置，这让我郁闷了。在网上搜索了一翻后，我才知道是界面元素的一些参数变了，需要进行描述性编程，也就是那时开始我开始了描述性编程的学习。

（补充一句：描述性编程就是改变对象的属性，格式基本是：属性名称:=属性。并不会像某些人说的那么难学）

只根据正常流程编的测试脚本只能当做冒烟测试。想要对一个模块进行完整的测试那是很不够的。要完整地测试一个功能，总不能靠一遍一遍地录制吧，工作量先不说，那代码就不是一般地糟糕呀，特别是对于一个有开发经验且讲究条理性的人来说，那里容忍得了那些page("XXX..._2")、page("XXX..._3")乱七八遭的，这些明明就只是一个东西却出来了那么多_2、_3之类的；还有那些代码整得都是一样地排，啥规矩都没，实在是忍无可忍。所以我又上网搜了一大把关于自动化测试框架的内容，但是很可惜，网上的东西基本都没有说到具体的内容，几乎每一个文章都是说要根据不同的项目搭建不同的框架。那时就想咋这么复杂呀，像开发项目咱也就MVC、三层架构之类的，那整得这么特殊。自动化编码架构应该也逃不出三层，我首先通过QTP中的table及参数化，对脚本进行了简单的处理，使得脚本可以循环调用，缩减了代码量，并增加了很多逻辑判断检查。这时项目结构分两部分，一个是功能块脚本，一个是webTable，勉强能正常使用。

再后来我在网上认识了个朋友，QTP玩得很好，也比较热心，他告诉我对象不要通过录制获取，要一个一地抓取，这样可以避免出那N多个page(".._N")之类的对象命名；也不需要用QTP中的table，直接在Excel中设置测试数据，再通过函数读取excel中的数据即可；对于一些比较常用的操作要以公共函数的方式保存起来，当出现相同的操作就直接调用即可；代码不要都写在Action里面，要存在函数库里面等等。在他的帮助下我才发现，其实自动化测试脚本与咱项目开发是一样的，只是多了些要造的测试数据，还需要预先弄好对象库,逻辑设置、数据库操作什么，基本一样。所以后来我决定把以前做的QTP脚本全部丢弃，重新建一个项目，一步步地先抓取对象，整理对象库，在Excel中整理造出所有的测试数据，然后再动手写脚本，并把一些公共方法提取出来以方便调用，形成了一个算是比较正规的自动化项目。

QTP收费很贵，虽然招聘时很多公司跟风似的，要求应聘的要会QTP、LR等等，但是在公司里面实际上用起来的少之又少，一些小公司可能会偷偷在使用，但是在一些大型的软件公司是不可能会让你使用QTP这么昂贵的工具的（因为这些公司最受人注意，容易被查），一般都是使用开源工具或公司自己开发工具。所以要想在自动化测试里发展，首先要懂一两门语言，其次还要了解一些开源的测试工具。Java是我大学时的主修课，是我撑握得比较好的一门开发语言。而对于脚本语言，以前没学过，撑握一门脚本语言，对自动化测试是相当有好处的，现在很多公司都使用python这个比较简单易学的脚本语言做自动化测试工作，所以我现在抬起java的同时也在学习python。

没做软件测试之前，一直认为软件测试很容易就可以撑握，进入这行之后才发现，原来软件测试涉及的知识面非常广，操作系统、计算机网络、数据库、开发语言、测试方法理论、测试工具等等，要学的东西非常多。毕业两年，加上实习的一年，差不多入行已经三年，纵观过去，先后学习了BUG管理系统jira、版本管理系统SVN、性能测试工具loadruner、自动化测试工具QTP、linux操作系统、安全扫描工具APPScan、链接测试工具xenu，还有很多的软件测试理论、开发语言、数据库等等。

有人说，怎么学习，要学到什么程度才够？我只想说，所有学到的东西都要应用到实际工作当中，否则无论你怎么学习，都会觉得不够，无法真正撑握。所以，一定要争取并把握一切能将所学赋之实践的机会！

（篇幅比较长，算是职业生涯中一个小小的总结吧(*^__^*)嘻嘻……）