在学会使用unittest后,实际上UI自动化的基础骨架已经搭建起来了,剩下的就是利于这套框架,增添一些我们需要的功能,目前看来,我们已经可以使用此框架来批量运行用例,欠缺的是整体的思路以及一些其他功能细节,比如日志记录、封装webdriver、读取数据库等功能的实现;在网上看了很多别人的框架,以及加上自己的理解后,我在这里分享一下我最终所整理的这套框架。
一、框架结构
这里是我的一个框架结构,其中:
common:
一些基础的底层方法类,例如:测试报告类、数据配置读取类、日志类、封装webdriver类、数据库连接类、发送邮件类、公共方法类,只要是我们想要实现的一些功能,可以吧基础方法的实现放在common文件夹。
config:
配置文件放在这里,比如:账号密码、数据库连接地址等。
log:
运行用例后,日志的存储文件夹。
report:
运行用例后,测试报告的存储文件夹。
page:
在POM设计模式下,关于具体UI页面操作的方法。
test_case:
具体存放编写的测试用例。
run_all:
用来批量运行测试用例。
二、一些设计的想法和理念
2.1数据分离
数据分离,顾名思义是指要把代码中的数据和代码分离开来,这样方便管理和维护。
在写用例以及框架时,会涉及到数据的处理,比如说:账号、密码、元素定位、测试数据等等,对于经常会用到,但是不会经常修改的数据,比如账号、密码等,可以写到配置文件里,然后再读取;而对于元素定位的话,我习惯统一放到类里,作为类的全局变量来进行维护调用,而不是写到代码逻辑中,之前尝试过把元素定位放到excel中,但是元素定位需要经常修改维护,其实放在excel里修改很不方便,所以我更习惯作为一个类变量来存储调用。
2.2 POM设计模式
POM简单来说,我的理解就是高内聚低耦合的一种实践,通过分层来使得代码更容易维护表达,同时把复用性极多的方法整合到一起统一调用。运用到UI自动化中,则是把一个UI测试用例的实现,分为了三层来实现;第一层是driver层,我们把常用的方法封装起来,比如查找元素的方法find_element()我们封装成一个定位元素的方法,然后在这个方法里加入元素等待;第二层是page层,也就是页面层,主要把一个页面中的操作写成一个方法,比如点击确定按钮,填写用户名等;第三层是case层,也就是测试用例层,通过把page中的操作像搭积木一样组合起来,实现测试流程。
封装的driver方法 ---> page:页面中的操作 ---> case调用page中的操作
2.3测试框架的完整性
就是加上一些我们需要的功能,比如测试报告、日志的打印记录、发送邮件等功能,当然不仅限于此,在基本搭建好框架后,可以对框架本身进行易用性的整改,比如我要查询数据库获取数据来入参或者断言,那就加入数据库连接的方法;比如为了项目更简单易用,可以加入UI页面的可视化功能,python本身三方库的种类很多,可以根据自己的需要或者想法来改造我们的框架。