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