一、自动化测试工具的应用方向

　　个人觉得，RFT的优点就在于其丰富和开放的API，你完全可以基于这些API，脱离RFT的IDE，因此，最好的方式是尽量将RFT提供的功能进行删减。

　　个人认为：伴随着这么些强大工具的推出，为什么还有好多一些公司的自动化测试一直不能规模化，究其原因是因为自动化测试的具体“战术”是根据环境变化的，而自动化测试工具设计的时候只是为了做出一款集成的测试工具，是根据工具设计人员对自动化测试理念设计出来面向大众的，大多中小公司拿到工具之后，以自动化工具为中心去做自动化测试，而渐渐脱离了做自动化测试的本质。

　　所以，做自动化测试，需以公司需求为中心，尽量将自动化测试工具给拆离（拆离的方法便是从底部开始，例如RFT，就可以从其API入手），然后将其满足需求的部分应用到自身的自动化框架中。

　　二、自动化测试框架重要方面简述

　　其重要方面，一为执行无人值守；二为结果定位准确。

　　其实，自动化测试，个人认为，分为两种情况：一是辅助手工测试；二是回归版本测试。第一种情况就是在手工测试的执行过程中，有一些重复的测试步骤或者很繁琐的步骤（做自动化比手工测试执行的时间和效率高），这种自动化测试其实也可以认为是半自动化测试，它主要是帮助测试人员解决一些无味的工作。第二种自动化测试可以俗称为“例行测试”，它必须做到无人值守的情况下执行，其主要作用是回归版本，加速产品发布速率，并且保障产品质量。因此在这种测试过程中，其结果的定位尤其重要，在例行执行完毕之后，需要有一份总的结果报告，并且有问题的情况下能够根据LOG记录详细定位问题。

　　三、自动化测试框架的具体细节设计

　　1、自动化测试用例的组织管理

　　这是自动化测试框架设计很重要的一个方面，管理的方式可以通过“EXCEL表、CSV文件、数据库等”，然后应用“自动化测试框架执行引擎”去解析“自动化测试用例表”去执行自动化测试。而其中自动化测试用例表中可以依靠一些关键字对自动化测试用例的执行方式和状态进行定义和查看。

　　2、自动化测试执行方式

　　通过“执行引擎”去解析自动化测试用例表，根据其用例表的“执行状态”的关键字判断其是否需要执行。并且下一个测试用例的执行还需要读取上一个用例的“完成状态”为“完成”之后，才执行，否则，一直处于等待过程。

　　3、自动化测试对异常的处理

　　自动化测试过程中往往会出现一些异常造成自动化测试过程的中断，因此如何去处理这些异常，保证自动化测试的不间断执行，个人设计的方式是：在具体的测试用例中加入异常判断处理（try-catch），然后判断过程为只要抓到Exception，测试过程则会关闭整个测试过程，并且在“自动化测试用例表”中将相应的“测试完成”状态置为“完成”，将“测试结果”置为“失败”，并且进行下一个测试用例。

　　4、自动化测试日志

　　RFT的日志反馈太过于凌乱，并且不好与自动化测试框架的结合，因此，个人认为，可以将其日志去掉，建立自己的LOG机制，在每个方法中设计其LOG的输出，而当遇到异常时，则进行异常的输出，这样的话，就能够从全局上把握其测试的结果了。

　　5、自动化测试结果

　　对于结果的查看，可以在“自动化测试用例表”中进行统一查看，由关键字“result”定义，若有错误的，则再根据具体的日志去定位问题。

　　总之，以上只是一些自动化测试设计的细节想法，当然，一定还有人有更好的方式，希望能够共同探讨。但是，个人坚信，工具本身是为测试需求服务的，所以，大家一定要警惕自动化测试工具的陷阱，不能陷入以“自动化测试工具”为中心的漩涡中，而要以自身的自动化测试框架为中心，将自动化测试框架插入其中，这样你才能做到“收发自如”。

　　顺便一句：其实我们的人生又何尝不是这样呢，吾以为：人生的最大追求为能够掌握自己的内心，真正做到“收发自如”，但若限制太多，抓不住本质，又何能做到此呢。

　　正所谓：

　　花开花谢，云卷云舒，静看日出日落，卧听雨滴天明

　　以何吾能达此状态矣？吾问吾心，答曰：自然而为之~

　　与君共勉之…