最近公司组织架构调整，我从服务组的测试人员，调到了质量管理部做客户端的质量管理。想着自己工作经验善浅而且实际工作项目能力并不优秀的情况下，我跟上级领导提出了换岗位的要求，我希望自己还能做一个一线的测试人员，能深入的了解自己经手的每个项目，但是也提出了自己的要求，希望能转做灰盒接口测试，能看懂代码的业务逻辑，能找一个合适的工具辅助自己做接口测试，然后跟进代码的业务逻辑，测试需求让自己更深入的进行测试。然后能根本上保证服务器的测试工作的有效性，高质量性，有针对性。
换了老大后，新的老大给予了大量充分的时间让我去研究接口自动化测试。公司的客户端和服务器的协议是私有的。协议私有的意思是：在原有的tcp协议上，在会话层加了一层自己的东西，而且在传输数据包的时候做了加密操作。那么现在常用的自动化工具哪些适合呢？下面是我做的最基础的自动化方面的调研。
自动化测试框架简介
自动化测试框架：能被重用的基础测试平台的应用骨架。测试框架可以分成2类：一类基础功能测试框架：提供可重用的基础自动化测试模块，如：selenium 、watir等；它们主要提供最基础的自动化测试功能，比如打开一个程序，模拟鼠标和键盘来点击或操作被测试对象，最后验证被测对象的属性以判断程序的正确性；一类是管理执行框架：提供自动化测试执行和管理功能的架构模块，如：Phoenix Framework，robot ，STAF 等；它们本身不提供基础的自动化测试支持，只是用于组织、管理和执行那些独立的自动化测试用例，测试完成后统计测试结果。通常情况都是把第二类测试框架集成在第一类测试框架中。如：robot框架就可以集成selenium 框架，Phoenix Framework集成的也是selenium框架。
分层的自动化测试
这个概念最近曝光度比较高，传统的自动化测试更关注的产品UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试。
UI测试：对用户界面中各个类别的控件的测试，即编写测试用例或者点检表，对每个按钮的响应情况进行测试，是否符合概要设计所规定的条件等。例如：我们不断重复的对一个表单提交，结果查询等功能进行测试，我们可以通过相应的自动化测试工具来模拟这些操作，从而解放重复的劳动。UI层的自动化测试工具非常多，比较主流的是QTP，Robot Framework、watir、selenium 等。
接口测试: 接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。比较主流的有：SoapUI, LoadRunner。
单元测试：关注代码的实现逻辑，例如一个if 分支或一个for循环的实现；集成、接口测试关注的一是个函数、类（方法）所提供的接口是否可靠。比较主流的有：XUnit系列，TestNG, GTest
为什么是一个金字塔形呢？ 因为不同阶段所投入自动化测试的比例不同。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，从而很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，那更是一个劳民伤财的举动，投入了大量人力时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高。尤其是UI层的元素会时常的发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。至于在金字塔中三种测试的比例要根据实际的项目需求来划分。在《google 测试之道》一书，对于google产品，70%的投入为单元测试，20%为集成、接口测试，10% 为UI层的自动化测试。
常用的四种自动化测试框架模式
第一类：数据驱动测试框架
概念：将测试数据从测试脚本中分离出来，测试框架中较简单的一类。
优点：测试数据可以单独维护；测试人员维护测试数据；测试开发人员维护测试脚本（必须懂自动化编程和业务逻辑）。
缺点：测试程序更改导致需要修改测试脚本代码。维护成本很高。
典型示例： web端接口测试：webService（XFire）+ TestNG
第二类： 测试脚本模块化框架
概念：一个测试脚本包含模块中涉及到的控件识别和业务逻辑，外部测试数据的调用。
优点：能针对模块进行测试和维护；测试人员维护测试数据；测试开发人员维护测试脚本（必须懂自动化编程和业务逻辑）。
缺点： 控件识别和业务逻辑本身属于不同的领域，没有很好进行抽象封装；控件和业务逻辑一旦发生变化，要进行修改和维护的是底层的测试脚本。
典型示例：selemium自动化测试模块的简单使用。
第三类： 测试库构架框架
概念：将所有的针对测试系统本身的控件识别和控件支持的操作封装在测试库中， 测试脚本调用测试库的同时传递外部的测试数据
优点：被测试系统无论是哪层发生变化，只需要相应的人员进行变更维护即可，完成了控件识别操作和业务逻辑的抽象分离；（测试库：掌握的自动化测试开发工程编写；测试脚本：对也业务较熟悉的测试开发）
缺点：变更引起的工作量还是附加在自动化测试开发工程师身上
典型示例：自动化测试模块的高级使用，懂得业务分层处理。
第四类： 关键字驱动框架
概念：当对象库添加完成后，测试case步骤的组织就相当于是在关键字试图中选择控件 Control），动作（Action），参数（Parameters）。
优点：极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少；普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据（脚本可由有一定经验的测试开发维护即可）
缺点：框架的抽象程度比较高，对自动化测试工程师的开发能力比较高
典型示例：QTP
常用测试工具
第一类：QTP。
用途：使用QTP的目的是想用它来执行重复的自动化测试，主要是用于回归测试和测试同一软件的新版本.采用关键字驱动的理念以简化测试用例的创建和维护。它让用户可以直接录制屏幕上的操作流程，自动生成功能测试或者回归测试用例。
优点：更适合做UI测试，属于基础功能测试框架。属于对测试人员编程能力要求不高。
缺点：关键字的框架，灵活度差。对flex等的支持差。一旦应用于企业自动化测试框架，必然需要购买正版，价格的问题比较贵。适合测试人员做自动化测试学习，一般很少能真正推广应用到实际项目。
类似产品： RFT（Rational Functional Tester，IBM），ranorex，WinRunner，SilkTest
第二类：Ant+Selenium+Testng+Jenkins。
用途：是一套基于WEB应用的验收测试工具，直接运行在浏览器中，模拟客户操作。它抽象出一系列命令来模块用户操作，比如open命令表示打开一个URL,click命令表示点击某个按钮。Selenium实际上将这些命令转化成实际的HTTP请求在浏览器中运行
优点：更适合做UI测试，属于基础功能测试框架。适合做java web 测试。一般公司的java web测试都会选择考虑使用该框架，灵活性强，开源，学习资料很多。
缺点：对测试的开发能力有较高的要求，需要会J2EE开发。最好能做到控件识别和业务逻辑的分层，整个项目会存在大量的代码重用现象，需要高度进行抽离。
类似产品：AdventNet ，TestPartner
第三类：SoapUI
用途：soapUI是一个开源测试工具，通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试，能够模仿Web Services，并创建/运行对他们的功能和负载测试，即使在系统部署前，这些也能够开展。
优点：可以完成多种web Service的测试场景，也可以做压力测试，能集成多种工具（ant），使用广泛，且对测试人员的开发要求不高，常用于接口测试。
缺点：不支持外部新增新的协议机制，不支持JMS协议或私有协议。
类似产品：LoadRunner接口测试
第四类：Mcafe。
用途：百度内部使用的一套自动化测试框架。包含了虚拟机的集成分配，自动化测试执行，测试用例管理。