项目背景
公司产品的UI自动化测试，由于产品的业务流复杂，所以只针对部分流程进行自动化测试，复杂的业务流还是需要手动测试，因为可能花费了大量的时间去写脚本和维护，然而手工的话只需要几下就好了， 在进行自动化的时候，一定要想清楚，哪些适合做，哪些不适合。
一般说来，针对UI自动化，都是选取界面稳定，业务流不复杂的。
RF介绍
Robot Framework是一款python编写的功能自动化测试框架。具备良好的可扩展性，支持关键字驱动，可以同时测试多种类型的客户端或者接口，可以进行分布式测试执行。主要用于轮次很多的验收测试和验收测试驱动开发（ATDD）。
RIDE 编辑器介绍
RF 是通过 RIDE 编辑器进行工作的，安装成功后，执行命令“[PythonDir]\Scripts\ride.py”，就可以打开 RIDE 编辑器。
分层思想
说起分层，就一定能要说下关键字驱动。
关键字驱动就是当调用不同的关键字，导致测试结果不同。
RF的分层，类似于selenium的POM模式，可以提高用例的可维护性，提高用例的可读性，提供较高的可扩展性。
实践展示
目前的分层如下：
测试用例层
名单管理部分就是测试用例层，所有需要执行的测试用例都放在这里，这里可以再仔细看下
这里面按照系统功能模块进行划分，新建了几个resource，再resource下建立新的测试用例。
下面时用户信息查询的测试用例
在这里我们可以看到，表格中没有关键字，只有数据，我们只需要在这里输入不同的数据，就可以实现数据驱动，输入不同的数据，检测结果，进行测试。
那用例流程在哪里呢，可以看到template中，就是我们导入测试用例的地方，需要在resource中导入相关的关键字才行。
只有变为蓝色时，才表示可用的。如果已经正确导入，但是没有及时变蓝，那么就关闭ride，重新打开，相信我，我遇到很多次这样的情况了。
功能模块层
下面是功能模块层，把每个功能都作为一个关键字封装起来，
看一个详情，这其中包含了添加风险等级的操作流程，并且基本上每一个操作都封装为一个用户关键字了，这就是为了提高用例的可读性
基本上通过看这个用例，就可以知道干了什么事情。
同时也提高了脚本的可维护性，便于维护脚本。当一个操作的元素定位变化时，我们不需要修改整个脚本，而只需要找到对应的关键字，修改它的定位元素就行了。
元素层
看一下点击新建这个关键字
可以看到这个关键字中内容很少，只是一个点击操作，点击一个元素。
也许有人觉得这样也需要去单独转化为一个关键字吗，直接写多方便。
是的，可以直接写在脚本中，但是直接看这个代码，你能知道这个点击元素的操作产生了什么效果吗？加入其他地方也需要点击这个按钮，那么是不是其他地方再写一遍呢？
当然不，注意看左边，这个关键字是在一个叫public-opera的resource中的，因为系统的原因，有很多业务都需要操作相同的元素，所以这里将这里单独分层出来，作为公共元素层
这样当其他的脚本中需要用到这些操作时，只需要导入public-opera，然后直接调用就可以了
数据库交互层
在此系统中，很多操作都对后台有交互，所以不能仅仅检查页面元素的显示，而且需要连接数据库，进行校验，以便检测操作是否真正成功。
变量
在数据库连接脚本中，以及测试脚本中，需要重复用到很多变量，于是将这些变量也提出来，方便维护，这样以后当变更数据库地址，或者其他变量时，不需要找到对应的脚本中修改，只需要在这里修改即可。
自定义库
在使用RF的过程中，RF自身提供的关键字很多时候并不满足我们的需求，此时就需要自己开发系统关键字，自定义库这一层中便放了自定义的几个系统关键字。使用python写了一个py文件，然后将py文件导入，就可以使用py文件中的方法了
业务流层
这里才是具体的业务流展现的地方，将每个业务都封装成一个关键字，在test case中的template直接输入关键字名字便可调用了。
这里便展现了一个业务具体的操作流程，从登陆，进入指定页面，然后搜索对应的数据，获取页面上的数据，与数据库中 的数据进行比对，如果相同，说明成功，反之失败。
当业务流有变化时，直接调整各个关键字的顺序即可，这也是分层的优势，大大提高了脚本的可重用性和可维护性。