自动化测试的发展思考

最近换工作，朋友介绍去了一家公司面试，最终有幸能够被认可，加入了新的工作。
在绿盟眨眼三年，很多思考在此工作交接完成之后，想总结下。

还是由本次面试开始说吧。


1.面试的过程：
    姑且叫这家公司为X公司，我所面试的职位是测试开发。话说在过去的四年，我基本上算是一直兢兢业业，平时也经常在网络上和大家交流，自认为技术不错。而且在面试之前，推荐人和朋友也给我打气：你的技术不会有问题，最终决定的是你是否想去。
    信心慢慢的来到X公司，参加一轮面试。甫一见笔试卷，便很慌乱，全C，主要考量技术，int,float,str等数据类型分别占几字节，内存泄漏的预防，数据结构，算法等内容。
    我的基础比较差，虽然已经在着力弥补，还是难以答得比较吃力。幸而推荐的朋友比较强力，得到面谈的机会。面试官前后问了四个问题：
    1. TCP协议建立连接和销毁连接的过程，画图演示并说明，尽量能够说出具体的数据包；
    2. 列举几种有可能引起进程死锁的情况，给予一种情况，分析是否会出现进程死锁；
    3. Python的多线程特点；（主要指和C，C++,Java等语言对比）；
    4. socket编程写一个简单的监听本地的server；
这些问题大多有涉猎，但对于细节的把握不好，往往一知半解，惭愧。

    惶恐自己是否有二面的机会，幸好得到。二面的技术问题比较简单：
    1. 设计一个系统，可以测试多操作系统（仅指windows下的xp,vista,win7等，不牵扯*nix）的某产品功能；
    对于这个话题倒是有所涉猎，洋洋洒洒的设计了个多线程+虚拟机控制的系统，可以并发测试多种操作系统的功能，当然，也强调了工作重点主要在环境的搭建等等。
    可能未来的技术应用中，虚拟机会占有重要的地位。二面的考官对这个系统设计还是比较满意。
    其实也凸显了自己的知识主要集中在应用层面，在理论基础层面欠缺很多，而自己的兴趣偏偏就在理论基础层面，需要更多的努力去弥补。

2. 与二轮面试官的交流：
    技术面试作罢，探讨了下关于自动化测试的思考。二轮面试官在业界可能没有名气，但他的确主导了某一家大型公司的自动化测试工作，并且有不错的成果。说到自动化测试，往往会立刻联想到它的意义在于回归测试阶段，在功能稳定的阶段，可以进行回归测试，节约人的重复工作，进而可以解放出人力去拓展测试领域，深化测试。
    这中说法几乎成为了业界的标准答案，貌似专业。然后对此我却有所不认同：
    从我刚开始自动化测试是在2007年7月吧，那时到现在已经三年有余，当时就已经有了这样的理论说法。那个时候，QTP在国内应用还比较少，我当时还欣欣然认为自己习得了一门安身立命的好本事。到现在我都不用QTP一年多了，这样的理论也的确应该得到一些修正。

3. 自动化测试辨析：
    提及自动化测试，如果单纯这么说，那么范围非常广泛。单元测试的自动化，功能测试自动化，性能测试自动化都属于自动化测试的范畴。而我们常说的自动化测试往往指的是UI功能自动化测试。
    其实，在自动化测试领域，较为成熟的应用集中在单元功能自动化测试和性能自动化测试。在单元自动化测试阶段，现在产生了很多成熟的理论和方法，指导着工作的开展与展开。
    在我个人的编码过程中，也尝试过测试驱动开发，在功能编写之前先进行测试代码的编写，当然，我使用的语言往往是Python，用的是Python的白盒自动化测试框架：unittest。然后，这种模式是和语言无关的，包括各种*unit。
    在后续的代码开发和重构中，之前构建的白盒测试用例也都有效的节约了测试的劳动力，大大提高了测试的覆盖度。
   
    性能自动化测试工具的应用比较多。像我的工作中往往关注进程本身的CUP,内存，发展到后续的I/O，子进程数量，线程数等等。这些也都有成熟的工具可以应用。对于典型的协议层面的性能自动化测试，LR是比较成熟的工具。
    曾经和一个自认为测试技术不错的人探讨过，他尊称LR为性能测试之王，对此我深表遗憾。还有很多非常好的性能自动化测试工具。我们的产品特性让我有机会接触到业界的思博伦，BPS等等厂商的性能测试设备，进行二三层的测试工作。
    在这些测试工具中，开放了良好的二次开发接口，可以进行自动化测试工具。

    当然，包括LR，包括思博伦或者BPS等厂商的测试设备，价值不菲。还有一种比较极端的请款就是自我开发。自我开发的工作难度比较过，因为要模拟并发很难，不过在一些要求并非十分严格的情况下，也是一种实现方式。
  
    说了这么多，只是想说明，当我们在探讨自动化测试这个话题时，要明确其范围，这个领域非常的广，如果范围不清，探讨就不再有其意义。

4. 关于自动化测试发展的思考：
    上面谈及了自动化测试的诸多领域。而我也一直在思考如果在我们实际的工作中应用自动化测试辅助我们的功能进行。
    当前的UI功能自动化层面从业人员比较多，多也有回归测试阶段节约资源的观点。但我想，现在我们是否可以打破自己的视野，将自动化测试提前到前端去，而不是简单的后端被动应用。
    首先说说UI的功能测试自动化。现在的技术发展据说有：应用为王的口号，在产品开发技术的逐渐成熟下，技术壁垒越来越低，而客户的感知往往决定着产品的成败。所以对于UI方面的测试重视逐步提高。
    由此衍生了诸多的UI自动化测试方法的工具，QTP，Selenium，TC等等，太多了。

    然后，抛开这些工具，让我们来思考UI功能自动化测试本身，它自身的投入产出比，我们当前是否做的足够好？

    先说听到的两个案例吧：
    1. 看到微软的测试人员写的一篇论文，在浏览器兼容性测试之前，通过编码实现HTTP协议的GET，POST等函数，进行与后端web服务器的功能交互，验证功能的有效性。
    从这个测试模式可以看出，至少在此测试阶段，弱化了UI的测试，而主要进行接口层面的功能验证。这也体现了模块化，解耦合的思想。后续当然也会进行UI的测试工作，但也许后续的会种感受，轻功能，当然是有相应的策略了，在此不作揣测。

    2. Baidu的技术交流会，陈景卫（如果名字打错请见谅）先生介绍百度当前的自动化测试分工，有7-2-1的划分，貌似的意义在于七成在后台，二成在功能，一成谈UI，也不约而同的对UI的功能自动化进行了一定程度的弱化。

    其实在我们绿盟，虽然我们的自动化测试投入人力有限，也一直在进行领域的探索。跟随他们的脚步吧或者说也有同样的认知，我们在推广UI功能自动化的同时就进行了后台功能测试重点推广。争取将自动化测试逐步推向前，而不是只在简单的最终段。

   
    所以，我在此想强调的是，随着自动化测试从业人员的技术积累，所谓的在回归测试应用自动化测试等等的观念可以做写改进了，我们理论上已经有能力将自动化测试应用到产品开发流程的前端。

5. 我们该如何做：
    既然有这样的想法，具体如何实现才是关键。
    回归到底一段描述的内容，我的面试题，我们是否可以直观的看出，这样的测试题和所谓研发的测试题目是否还有本质的质的区别？包括我们公司现在的招聘工作，研发测试都是同样的笔试题，也在深刻的体现一个问题：
   研发测试工作界线的弱化。
    首先，现在的要求是研发、测试都要有强烈的质量意识。这点其实很多研发职位的人员是有非常强烈的质量意识的。他们对于产品质量的要求甚至要比所谓的测试工作者更强。二者本应是相辅相成的互助模式，而非所谓的敌对。
    便如三权分立的思想，在合作的同时，彼此制衡，来保证产品的质量。
    随着这个行业的发展，竞争逐渐激烈，门槛也会逐步提高。
    在这种情况下，我们的测试人员还有理由没有编码能力吗？所以，编码能力必将成为测试从业者的基础技能之一。

    另外就是，要坚定的认识到，自动化测试的推进不再是产品测试人员的工作，需要研发测试的合力。
    在产品的设计阶段，留出良好的测试接口，当然，可以包含在发布代码中，也可以调试模式或者其他方式，现在也有成熟的理论支撑，在后续的发布版本中去掉。有了良好的测试代码接口，我们的自动化测试人员可以大幅提高开发效率，进而提高投入产品比，让自动化测试不只停留在一个理论的阶段。
   
    同时，也要推进研发人员的白盒测试工作，当然，具体谁来执行白盒测试各公司分工不同。至少要有认识，如果他们不愿意或者排斥白盒测试的工作，你是否有能力承担起白盒测试的工作？

    相比UI的功能自动化测试工作，我一直认为白盒测试自动化和性能测试自动化相对要容易些。

    对于想实现最终的自动化测试，可以逐步推进，从白盒测试自动化，到功能测试自动化，UI功能自动化到性能测试自动化。在设计层面加入一些思考，让彼此解耦合，能够独立推进却又可以持续集成。

6. 人的力量：
    工作也有4年了，经历了三家公司，现在马上要进入第四家公司了。深刻得认识到，团队的力量固然强大，然后个人的单兵作战能力往往更直接决定着最终的产出。

    想在这个领域持续的发展，需要持之以恒的不断努力，自勉吧。