RF结合Page Object模式web自动化测试架构

前言：

这是本人在自己项目中设计的一个web自动化测试架构，架构可能仍存在问题，目前仍在优化，在本人的项目中已能正常使用，之前在测试架构上犯过错误，导致测试的同事浪费了时间在不太恰当的架构上进行测试用例的编写，后来结合实际情况分析，最后将架构调整为以模块为中心的架构，不是以基本功能为中心的架构，还好调整得早，不然等第一期用例写完再调整，那时间可是翻倍算啊，从这次经历中也体会到，架构是一个多重要的东西

Page Object模式介绍

那到底什么是PageObject模式？

PageObject 见名思意思，就是页面对象，也就是把界面定位和业务操作分开，在我现在团队我推行的是三层模式，把UI自动化分为了对象库层，操作层和业务层。PO思想对界面交互细节进行了封装，这样可以使测试案例更关注业务，而非界面细节，提高了测试案例的可读性，同样也可以为我后期BDD（Behavior Driven Deveopment）的推行打好基础。

RF结合Page Object模式web自动化测试架构

RF，即RobotFramework，结合RF的特征和Page Object的模式实现web自动化测试的效果可以说是淋漓尽致，不多说，看看总是架构是如何的：

从总体架构上可以看到：

1、UI架构

将UI布局模块中的页面元素封装到对应的Rescource，然后通过一个类似UI工厂类的Rescource将和布局模块中的页面元素封装好的Rescource再封装，这么做是为了后面的基本功能操作可以使用到所有的UI元素，同时也便于对新增元素的管理，对于业务模块相对较小的项目比较高效，符合增量模型，具体UI模块架构如下：

2、功能架构
1、功能模块方面先引入原生的类库，如Selenium2Library，AutoitLibrary等，加入一些全局变量或测试初始化的变量，如选择浏览器等

2、同时引入之前封装好的UI的Rescource，封装成原生方法的Rescource，类似于原生方法工厂，就可以开始根据布局模块中的功能模块，通过原生方法(关键字)+页面元素进行基本功能操作封装，形成原子测试用例

3、这里的原子测试用例是不输入数据以及对输出结果进行校验的，基本功能操作的模块划分是和界面元素一致的，这是为了能快速的找到功能操作对应参与的基本页面元素，也便于模块化的维护

4、模块之间的方法可以互相调用，组合成复合功能操作，最后将各模块封装好的功能操作通过一个类似基本功能操作的工厂封装起来，

补充：

在分级上UI和基本功能的分级方法是一致的，分3级：布局模块UI（对应功能组）>布局模块中细分模块UI（对应功能组）>具体UI元素(具体功能3级)，各模块用同样的方法将具体UI或功能封装到对应模块的工厂，在将对应模块的工厂封装到全局模块的工厂，实行层级管理

3、用例架构
1、基本功能操作的工厂封装起来后便可以组合组合基本功能操作编写测试用例，同时引入测试数据，RF是支持数据驱动的，也可以直接关键字驱动或模块驱动

2、通过输入的数据+基本功能操作组合+输出结果校验组合成一个基本的测试用例

3、 用例之间以功能模块划分为主，分3级，功能模块测试用例组>功能测试用例组>具体功能测试用例

4、 测试用例之间可以组合成新的测试用例再进行业务流程上的测试

5、用例的执行可以单模块内执行，可以多模块间执行，这里要注意具体的业务流程，要考虑模块间的操作是否会导致其他模块出现异常，如申请流程和审批流程，单个流程可能功能正常，流程组合起来就未必一定正常，要做好模块间的业务联系

6、测试步骤完成后输出测试报告，并根据测试报告的结果分析是web的bug还是自动化脚本测试用例的bug，根据分析得到的结果联系到对应负责人员

4、架构优略

1、本架构适用于增量模型的业务量较少的项目，添加或删减资源方便，也适应需求变动较频繁的项目，通过结合RF的特征，使用Rescource将UI，功能和用例像一条线一样串联起来，使用更加方便

2、但本架构没有具体的考虑到性能方面问题，假如项目后期界面元素多了，功能多了，引入的类库多了，可能会照成Rescource线的压力，这里是否也可以根据模块分出多条Rescource线来缓解加载方面的压力，同时也更加具体的将模块分开，但目前由于本人的项目业务量不太，所有一条Rescource线将全部模块融合一起已经够用了，如果将来业务量多了，再加一条线也是比较容易的，这也是本架构易维护的特点