web自动化测试第21步：UI自动化框架结构以及思路

在学会使用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本身三方库的种类很多，可以根据自己的需要或者想法来改造我们的框架。