本文章转载于搜狗测试

项目背景

公司产品的UI自动化测试，由于产品的业务流复杂，所以只针对部分流程进行自动化测试，复杂的业务流还是需要手动测试，因为可能花费了大量的时间去写脚本和维护，然而手工的话只需要几下就好了，在进行自动化的时候，一定要想清楚，哪些适合做，哪些不适合。

也就是我们常说的投入产出比，一定要考虑好这个才行。

一般说来，针对UI自动化，都是选取界面稳定，业务流不复杂的。

RF介绍

Robot Framework是一款python编写的功能自动化测试框架。具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口，可以进行分布式测试执行。主要用于轮次很多的验收测试和验收测试驱动开发（ATDD）。

RIDE编辑器介绍

RF是通过RIDE编辑器进行工作的，安装成功后，执行命令“[PythonDir]\Scripts\ride.py”，就可以打开RIDE编辑器。

分层思想

说起分层，就一定能要说下“关键字驱动”。

关键字驱动就是当调用不同的关键字，导致测试结果不同。

RF的分层，类似于selenium的POM模式，可以提高用例的可维护性，提高用例的可读性，提供较高的可扩展性。

实践展示

目前的分层如下：

第一个是测试用例层，这里保存全部的测试用例，第二个是功能模块层，将需要做的功能都都细分后放在里面。第三个是数据库层，通过对数据库的校验，来验证UI操作的的成功与否。第四层是元素层，将各个功能中涉及的元素都提取出来，便于后期维护修改。

第五个是业务流层，这里就是展现我们业务逻辑的层面。

测试用例层

名单管理部分就是测试用例层，所有需要执行的测试用例都放在这里，这里可以再仔细看下

这里面按照系统功能模块进行划分，新建了几个resource，再resource下建立新的测试用例。

下面是用户信息查询的测试用例

在这里我们可以看到，表格中没有关键字，只有数据，我们只需要在这里输入不同的数据，就可以实现数据驱动，输入不同的数据，检测结果，进行测试。

那用例流程在哪里呢，可以看到template中，就是我们导入测试用例的地方，需要在resource中导入相关的关键字才行。

只有变为蓝色时，才表示可用的。如果已经正确导入，但是没有及时变蓝，那么就关闭ride，重新打开，相信我，我遇到很多次这样的情况了。

功能模块层

下面是功能模块层，把每个功能都作为一个关键字封装起来，

看一个详情，这其中包含了添加风险等级的操作流程，并且基本上每一个操作都封装为一个用户关键字了，这就是为了提高用例的可读性

基本上通过看这个用例，就可以知道干了什么事情。

同时也提高了脚本的可维护性，便于维护脚本。当一个操作的元素定位变化时，我们不需要修改整个脚本，而只需要找到对应的关键字，修改它的定位元素就行了。

元素层

看一下点击新建这个关键字

可以看到这个关键字中内容很少，只是一个点击操作，点击一个元素。

也许有人觉得这样也需要去单独转化为一个关键字吗，直接写多方便。

是的，可以直接写在脚本中，但是直接看这个代码，你能知道这个点击元素的操作产生了什么效果吗？加入其他地方也需要点击这个按钮，那么是不是其他地方再写一遍呢？

当然不，注意看左边，这个关键字是在一个叫public-opera的resource中的，因为系统的原因，有很多业务都需要操作相同的元素，所以这里将这里单独分层出来，作为“公共元素层”

这样当其他的脚本中需要用到这些操作时，只需要导入public-opera，然后直接调用就可以了

数据库交互层

在此系统中，很多操作都对后台有交互，所以不能仅仅检查页面元素的显示，而且需要连接数据库，进行校验，以便检测操作是否真正成功。

变量

在数据库连接脚本中，以及测试脚本中，需要重复用到很多变量，于是将这些变量也提出来，方便维护，这样以后当变更数据库地址，或者其他变量时，不需要找到对应的脚本中修改，只需要在这里修改即可。

自定义库

在使用RF的过程中，RF自身提供的关键字很多时候并不满足我们的需求，此时就需要自己开发系统关键字，自定义库这一层中便放了自定义的几个系统关键字。使用python写了一个py文件，然后将py文件导入，就可以使用py文件中的方法了

业务流层

这里才是具体的业务流展现的地方，将每个业务都封装成一个关键字，在test case中的template直接输入关键字名字便可调用了。

这里便展现了一个业务具体的操作流程，从登陆，进入指定页面，然后搜索对应的数据，获取页面上的数据，与数据库中的数据进行比对，如果相同，说明成功，反之失败。

当业务流有变化时，直接调整各个关键字的顺序即可，这也是分层的优势，大大提高了脚本的可重用性和可维护性。