只需当故事看就够了！


  最近总想写一些东西，关于自己的这个职业，关于这么些年的个人体会。

  本人从事测试的工作已经七年了，基本上这七年中都在做自动化测试开发，包含了测试、自动化框架的搭建和开发、测试平台的搭建和维护等。

  故事从毕业那一年开始说起，高中时代就接触代码、大学毕业后的梦想是当个程序员，当然之前还有很多梦想。然而最终做了测试，具体来说自动化测试。那个时候测试门槛很低，感觉是个人都可以做测试，那个时候不太愿意，感觉没技术含量，就点点点然后发现问题，找开发。但接触了自动化测试以后，就爱上了它，爱了这么多年还在坚持.......

  第一阶段，自动化给予的成就感。

  为啥做自动化测试：刚到上一家公司的时候，做的测试有很大一部分都是回归测试。每次需要回归的内容都是相同，而且测试的时间非常紧张。三个月试用期过后，我考虑通过代码的形式替代手工的回归测试，这只是个人的设想。然后我实施了，就这么简单，WEB页面的系统，刚开始考虑的是WR（winrunner工具，不知道现在还有没有人在用，因为之前我用的就是这个工具,C语言的哦，非常好用），然后很可惜，WR对WEB的支持并不是很好。后来选择QTP工具，当时QTP对测试来说还是非常的火的。然后当时一无所知，那就学吧，QTP用的语言是VBS，到现在很多人还是认为会自动化工具就会自动化测试了，这其实是个错误的认为。自动化工具只是个工具而已，就像开发工具ECLIPSE、NETBEANS一样，会工具不是说就会自动化测试、会开发，你会语言了才是真的会。回过头来，当时VBS是真不会，但还好的是之前自学过QB(quick basic,不知道有没有人还接触过，感觉我学的都是比较奇葩)，但两种都是由basic发展过来。语法上还是有相同的，学起来也快......

  怎么做自动化测试：和初学者一样，一开始用QTP工具录制脚本，然后修改脚本、对象。但是系统有变动，我的自动化脚本也必须得变，这个很痛苦，庆幸的事，回归那块内容基本上不会有太大的变化。针对回归测试用例写了大概十几个，发现另外一件痛苦的事情，十几个用例，十几个脚本，我要点击十几次执行（就像开发的调试一样），这样对我的工作量没有太大的帮助，或者说是加大了工作量。然后我得考虑怎么一下子将这十几个用例执行掉。OK，开始搭建框架的第一步，通过代码调用各个测试脚本。由于我的脚本都是录制并修改后得到的,全部存放在action中，故，我直接写一个runaction即可，就能将十几个脚本执行起来。在搭建框架的路程中，我走出了第一步小步。但这只是一小步，那么我是做测试的，不同的测试用例对于的数据不同，而测试步骤相同，得到不同结果。这里的关键是步骤相同，那么我就需要考虑通过对脚本进行参数化才能进行不同的用例调用相同的脚本来完成。我所有的测试用例。接下来需要考虑：

    1、数据存储在哪里？

    2、用例执行的顺序如何设计？（可以理解为测试场景）

    3、用例执行后结果如何处理？

我的选择是，数据存储在XLS表中，包含测试数据、测试用例名称、执行顺序设置和结果输出。具体不简述，之后对于搭建框架详细述说。在VBS中直接运用CreateObject创建XLS表的信息，并获取表中的数据，存储在二维数组中...........

  实现自动化测试的效果：直接给我的效果是我回归的工作量减轻了，可以全部经历投入到需求测试中去，当如针对当前需求的测试还是通过手工测试进行。当其他同事还在忙碌的进行需求测试和回归测试的时候，我轻松的在做需求测试，回归测试放入VM机中同时进行自动化测试。当需求测试完成以后，进入VM机查看自动化测试结果，对失败的测试用例进行分析一下即可。最大的成就感还在于这个过程。

 第二阶段，自动化测试运用的最大化

 当我的工作轻松后，旁边的同事开始关注我了。OK，要求请客吃饭后，我告诉他我所做的一些事情，然后将自动化框架以及测试脚本、测试用例共享给他。同样的他需要装一个VM机，然后我将系统给予他。然后再说一下如何通过VBS脚本进行开发测试用例。经过一个月的学习交流，终于将他的回归测试用例也实现了自动化测试。结果一样，工作轻松了。结果传来传去，整个小组都通过自动化测试来实现回归测试。但随着用的人多了，问题也出现了。

 首先，回归测试用例是相对固定的，但每人回归的内容却不固定，而自动化脚本又各自在自己的VM机上固定。

 其次，自动化测试的结果都分散在不同的VM机上，能否合并在一起。

 最后，回归的时间能否缩短，随着时间的推移，回归的内容越来越多。

这个时候，我开始想通过平台进行管理我的自动化测试用例，那么需要搭建一个自动化测试平台，首先考虑的是JAVA，然后考虑TOMCAT，OK，就这样，将每天VM机上都装上TOMCAT，设置IP地址和端口，再将JAVA的控制代码发布到一台机器上，通过IP地址访问各台VM机，调用自动化测试框架执行测试用例。就这样建立了一个简单平台控制页面。大家都可以在平台上选择自己的测试用例发起到各个的VM机上运行脚本。

  以上都是自己的个人经历，当然这只是其中的一些部分，之后也对平台进行了大的改造，这个不只是一个人去完成，而是通过团队慢慢完善，后来测试框架也进行了完善。再后来我们通过selenium+RUBY的方式搭建了另外的测试框架，原先执行的VM机也换成了云。现在已经是个非常强大的测试平台，包含了测试流程管理、自动化测试流程管理等等功能。但我想说的是经过这些后，我发现测试其实并不那么简单，或者说它的难度已经超越了开发。不是这样说吗，国外的测试都是先做开发，后来才做的测试吗。在测试开发的过程中，需要考虑代码、需要考虑数据、需要考虑流程、需要考虑各个层次（接口、UI等等），现在各个公司也对测试人员的要求越来越高，个人觉得这是好事。个人认为一个真正的测试人员必须得具备：开发的技术、测试的思路、管理的手段和玩的心态。

 每个职业都有其职业的修养，然而我们匆匆来匆匆去只是为了金钱，为了生活。却忘记了我们是否热爱自己的工作，如何热爱这份工作。测试不是一件简单工作，它所做之事，必须学会更多的东西。知己知彼，方能百战不殆！

 只需当一个故事看就够了.......