最近接触了一个基于SeleniumRC的自动化框架与之前项目中接触的不太一样，在这里把这两种框架的理念、方法总结比较一下，以便以后应用。先将两种不同的方式做一个大致介绍再进行比较。

　　之前接触的框架，主要思想是通过继承selenium的API，并将应用系统中的页面定义为一个个的PageObject。这些pageobjcts如同“源代码”，里面定义了每个页面的固定元素以及页面上操作的方法。这些“源代码”中的变量和方法都定义为静态常量，那么在测试用例中调用的时候不用实例化类，直接用pageobjct调用就可以了。页面元素通过元素的id或name属性定义，页面操作则是通过覆盖seleniumAPI来实现的。举例说明，如果测试步骤需要click选择页面的一个数据，这里大家都知道可以通过xpath定位数据。可是，对于复杂的页面定位xpath是一个比较费时费力的过程，即使完成了xpath的定义也很有可能在执行阶段由于查找时间过长导致selenium自动timeout，测试运行失败。因此，我们对selenium的API进行覆盖并封装，通过要操作数据的其他信息定位到对应的checkbox，例如在其他td内的文本信息，运用xpath的兄弟结点、父子节点、或者各种attribute，力求用更多匹配的信息提高定位的速度。其次，对selenium的start、stop等方法也进行了封装。最后，通过Junit和maven实现testreport及自动化测试的持续集成。

　　新接触到的框架更多的是开发了一个自己的框架，将编写的测试用例转换成selenium可执行的方式，通过TestNG框架和seleniumRC的服务器运行测试。通过TestNG中的Factoryannotaion和Testannotaion，框架解析TestCases中的steps和要执行的某个process的casestep或者是某个suite。TestCase的step通过htm定义，包括每一步的action，target以及value，value可以通过。properties文件用参数的形式调用，这样就实现了数据驱动的测试。解析成类似IDE中录制的脚本，再通过selenium的doCommand（）运行，最后当所有steps或者所有cases运行完后由TestNG生成report。从这个角度来说，我们不必关心应用系统是如何开发的，只要把用例设计编写好就可以了，其他的事情都由框架来做。

　　从框架复用性来说，第一种框架借用了更多selenium自己的东西，需要了解更多应用技术方面的信息，在应用框架时需要对每个页面进行重新定义，因为xpath不同了；而第二种框架，以一种解析的形式通过统一的用例编写形式达到了一定框架复用性，这里我也实验了一下其他的系统是可以跑通的。

　　从用例编写的角度来说，第一种要用的什么变量或者方法直接用相应的页面调用就可以了，不用太多考虑xpath的问题，xpath是在定义源代码部分调用的时候会稍快一点，个人感觉稳定性也高一点；第二种直接写在htm中，一个是花时间定位数据。另外，在对业务逻辑进行测试时，xpath的形式可能会比较固定也不够直观，不知道操作的是哪条数据。

　　从数据驱动的角度来说，第一种框架我们在实施时数据驱动做的并不是很好，虽然使用的是初始化数据，但对于login这样的操作，还是用给方法传参的方式进行的。如果换了库，改每个case中用到的数据可能会花费很长时间了；第二种框架在数据上的区别还没有体会很深，至少已经采用了参数文件的形式进行驱动。

　　就目前我对这两种框架的理解，我进行了一些简单的比较，可能想的并不全面，还请大家多多指正，呵呵。