序言：上篇文章说的“自动化例行测试有效性策略”，在又一次进行例行测试的时候，安排了一个不懂脚本的测试人员进行了例行测试操作，结果这是最迅速的一次，而且还发现了一些产品问题，效果不错，验证发现，其有效性还是得到了一些提高。所以说，有时候，做自动化测试很害怕的是“完美主义”与“盲目主义”，局限于一些误区，所以一定要以“测试价值”为导向，不时的跳出来看一看其自动化测试的应用价值是不是进入了误区。这次，对一些不同的自动化测试方式的应用进行了策略分析，不同的自动化测试方式应用不同的场景，不管如何应用，提高效率则是最佳应用。
一、自动化几种测试方式
这次，自动化测试几种方式，我暂时按测试类型分成：
1、界面自动化测试
C/S架构（或者桌面类型）界面自动化测试：包括桌面界面测试类型，当然有windows方面的软件界面、跑在windows操作系统上的虚拟机方式的界面，例如java swing。前者采取的方式可以调用操作系统本身的API来构建自动化测试、后者可以采用虚拟机内的事件处理机制来完成了。
B/S架构（或者web类型）界面自动化测试：其实现原理之一可以依靠JS来进行客户端的操作，然后寻找对象是采用了DOM解析技术，将web方面的节点进行解析定位。
手机方面（嵌入式产品）界面自动化测试：其实现原理之一也是可以依靠其相关系统提供的API来完成。例如：安卓的monkey就是安卓提供的一个提供动作操作的一个工具。
2、命令行自动化测试
CLI自动化测试：即嵌入式的产品很都基于嵌入式操作系统完成，例如：电信产品中的ciso路由器就是最早的代表，而系统测试人员的测试大都应用命令行进行测试，所以，其自动化测试实现可以基于CLI的脚本控制实现。当然，对数据库SQL命令行的操作也可以归为此类。
3、API自动化测试
API（Application Programming Interface，应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节，其实就是软件中的封装性的思想。个人认为，API测试是用来验证组成软件的那些单个方法的正确性，其可以包括为单元测试、单个组件测试以及接口测试。一者是对单个模块功能测试、另外一者是对测试系统组件间接口的一种测试。但本质上都是调用其API来验证相应相应功能实现或者交互。
二、自动化测试不同方式策略分析
以前总在思考如何能够最大化的应用界面自动化测试与CLI自动化测试或者API自动化测试的不同特点去实现各自的自动化测试最大利用率：
1、界面自动化测试的特点在于：
1）操作方式复杂，需模拟出不同的手工操作。
2）其界面元素结构层次变动性较大。
3）其容错性查，如果某单个测试用例中途遇到问题，则造成其单个测试用例无法进行下去。且与软件性能关系较大，容易造成软件测试中断。
4）错误定位方面，需要靠直观的方式进行定位。
所以，综上，策略为：
1）界面自动化测试需要进行架构的分层，对于界面控件的查找需要基于一定的属性搜索定位，而常用的录制方式一般是依靠结构层次定位。
2）尽量将测试用例按测试模块细分，在中途出现问题，则可以进行down掉，再进行下一个测试用例即可，而且测试用例越细分清楚，则错误定位越简单。
3）当然，大范围做的话需采用框架，但小范围回归测试的话，则采用录制+二次开发的方式会比较高效。所以，不同的方式采用不同的策略是很重要的。
2、命令行或者API测试特点在于：
1）操作方式单一，都是进行命令行的输入。
2）其命令行变化小，但是不同设备有不同命令行集成，脚本数量多，命令行更改也容易造成维护量大。
3）容错性较好，一般命令行自动化测试都是采用输入+回显判断的方式，所以，不易造成测试中断。
4）错误定位方面，靠日志记录的方式即可。
所以，综上，策略为：
1）由于其单一操作性，对于一些简单的回归测试，则可以采用CLI录制的方式，生成一些简单的回归脚本，这样，测试人员也可以进行简单的自动化测试回归设计，辅助提高测试人员的测试效率。
2）对于需要大规模进行例行环境建设方面，更多的是考虑维护量方面的问题，则可以采用关键字驱动的思想，将设备映射成一系列的关键字对象，将其属性进行封装，这样，可以提高重用性和降低维护量。
总之，个人觉得，自动化测试应用的最大策略就是“因地制宜”，主要是抓住其测试方式的特点，然后以不同的策略去对待，这样，才能真正快速应用自动化测试提高测试效率。否则，很容易陷入了“为做自动化测试而自动化测试”的陷阱。