序言：一般对于C/S架构与B/S架构系统而言，都会包括前端界面或者页面的验证测试，也包括后端设置是否生效的测试，当两者结合测试时，就得有一个好的前后端交互机制来进行协调控制，进而保证测试的有序性与完整性。此，介绍一下自己对于应用RFT来进行前端swing程序的控制以及其后端脚本控制设备来进行交互的框架的研究与设计。希望有同道之士能够对其提供意见即可。

　　一、前后端测试简介

　　在一些测试中，例如，电信自动化测试项目中，需要进行前后端的测试。如果前端是C/S架构，则需要在客户端上进行命令的操作和下发，然后在后端终端上应用CLI进行命令下发是否成功；B/S架构类似。而前后端的测试方法各有不同，所以在交互上需要有一套良好的机制来保证测试的有效运行。

　　二、前端测试方法

　　前端测试，主要是采用Gui测试工作进行其应用的控制。

　　C/S架构的工具，包括：RFT、QTP、abbot（java的自动化开源测试工作，主要是针对其组件的应用）等。

　　B/S架构的工具：包括：RFT、QTP、selenium等。

　　在此，以RFT测试java程序为例子展开说明：

　　根据AUT的具体情况，将其测试架构分为了三层，如下：

　　1）AppObjects，可以采用动态搜索（find）的方法进行界面组件的查找定位，也可以应用getter（即取得组件容器）的方法。比较如下：

　　1、采用find的方法，增加了编程的复杂性，但是在属性的查找定位上更加灵活，拓展性和识别能力也更强。若是有公司产品研发能够做到提供对其组件提供唯一标示id作为识别属性，那么其在组件定位及错误定位上得到很大的帮助。

　　2、采用getter的方法，编程简单且直接面对组件对象，但是其组件查找属性已经固定，所以界面的改动会容易造成组件查找不到。

　　所以，可以针对不同的组件应用不同的方法，具体在实践中总结。

　　2） AppLibs，测试函数库，可以分为组件调用方法库与通用方法库。组件调用方法库是针对AppObjects传过来的组件进行操作；通用方法库则是一系列在架构中需要用到的一些通用方法，例如：模拟键盘的输入、文件的读取、数据库的读取方法等。

　　3）AppTestCases，测试用例库，具体划分针对不同产品，例如：有的按产品线划分，有的可以按同一产品不同型号划分；每个用例为一个模块，能够保证单独执行；且可以建立一个通用的用例库，任一个用例可以进行调用。

　　三、后端测试方法

　　1）对于后端测试方法，可以应用脚本技术即可实现。例如：在电信测试项目中，应用脚本技术测试后端的优点如下：

　　a）脚本编写简单（命令+参数的形式），应用方便，直接使用解释器执行即可。

　　b）与测试仪、分析仪的结合使用方便。

　　c）处理字符的能力较强，容易满足需求。

　　2）对于应用java等语言实现后端测试亦可，不过在编程上实现较为复杂，成本较高，具体情况可以针对公司具体情况分析。