项目背景
项目是一个传统的web端,技术架构采用jsp架构。
基于这种项目架构,项目已经有UI自动化,并已经做的比较成熟,但出于各种原因,框架缺少测试前后数据的处理,这部分工作可以通过基于框架外的其他脚本实现,同时框架的特点是方便上手,相对于方便,但是也有其缺点,执行速度较慢,实现的功能有限。
为了提高测试的准确性和提升工作效率,工作中开发了很多小工具,后来发现这些小工具有代码耦合部分,可以将公共部分提取出来。
框架实现的主要部分是pytest+django,pytest可以集成很多插件,方便测试用例的执行,django可以将此框架拓展成测试平台,也方便开发微服务,为postman等其他接口工具调试提供便利。框架也集成了其他库,Requests调用接口,allure产生测试报表,DB驱动连接数据库,csvReader,csvWriter,openpyxl等处理测试数据,Re,BeautifulSoup处理返回结果。
设计思路
- 搭建整体框架 包含 项目基础配置(django,pip配置),工具类,fixture前后置管理,测试输入输出数据,测试策略main入口,测试日志,测试用例,测试报表,外部依赖等
- 编写测试用例公共部分,如测试用例在不同项目的登录和登出,编写在fixture里面
- 编写第一版测试用例
- 继续优化提取公共部分
- 参数化测试数据,将测试数据提取到配置文件或者数据文件中
- 根据功能,作者,场景等为测试用例添加标签方便统计
- 添加执行策略,编写main入口
- 添加日志报表
- 优化执行策略,适应于不同的测试环境
10.自定义命令行参数,生成模板测试用例
项目结构
- django的包,进行django的基本配置。可以提供开发微服务,日志,项目的根目录等功能。
- util包:提供一系列框架中需要使用的工具,主要包含
- config类 主要使用到configparser(),读取.ini配置文件
- db类
- 封装不同数据库操作的增删改查方法
- 工具类调用不同的数据库给外界使用
- public类 封装openpyxl,csv,以及默认库的读写操作,BeautifulSoup,Re处理接口返回数据
- remote类 使用paramiko进行远程连接,可以作为某些测试用例的前置后置数据处理
- requests类 基于不同协议发送请求的封装,http协议使用request库的get post delete put等方法
- settings类 提供django的logger和项目根目录给其他类使用
- file包
- config 一些项目运行的环境信息,如DB,请求的Host和一些必要参数等。不同环境维护在不同的文件上,其中有一个文件作为读取文件,其他文件维护不同环境的配置信息。当把项目放在流水线时只需要传递必要的参数,将其他环境的配置信息通过io读写,写到读取配置的文件。
- result 存放测试用例执行的结果,便于结果分析,也可以作为执行用例的evidence使用
- test_data 测试用例用到的测试数据,数据选型主要用到csv文件和xlsx文件两种形式,其中csv文件内存会更小,xlsx文件使用相对方便,相比于xls文件格式占用内存也会更小。
- lib 某些接口传参需要依赖其他语言对传参进行加密处理,该目录存放该类文件,可以通过python调用处理不同语言的第三方库处理这些文件。
- test case包
- pytest.ini pytest的配置,根据项目的需求可以将pytest.ini放到不同的位置
- fixture 测试用例的前置和后置处理,比如登录和登出等操作,对于通过session管理登录状态的,登录后返回session,对于通过token登录的,将获取到的鉴权加入到header中返回。
- 日志包 存放测试用例执行的日志,加入流水线时保存到文件里,本地调试输出到控制台
- report包 主要包含allure的测试报告,流水线中allure会捕获django RotatingFileHandler的日志
- mange.py django的执行入口
- main包 测试用例执行的入口,在此维护测试用例的执行策略,也可以赋予根据标签统计等功能。对于用例执行可以维护成读取接口入参或者cmd入参或者pytest自定义参数的形式,主要包含两个动作
- 根据接入的传参确定取哪个配置文件的信息,切换不同的测试环境
- 根据传参确定执行哪些测试用例
- 另外在测试用例执行时有一部分耦合,比如不同的接口测试用例都需要检查联通性返回结果是200,这时可以单独创建一个自己生成测试用例的py文件,文件包含接口标准化参数的文件路径,模板路径和生成测试用例的路径,生成对应的测试用例。
设计原则
保持整体项目的框架代码和业务代码松耦合,在如上的项目结构中,util和django相关是项目的公共代码,此处保持和业务解耦,方便框架的拓展,其他如main包,test_case包,是业务部分,这部分编写业务相关的逻辑。
关于登录接口
登录是测试用例的起点,在接口中也是比较难的部分,工作中的项目是多团队协作的项目,发现编写好的登录脚本工作一段时间后,突然失效了,通过debug发现,可能是接口的加密逻辑变更了,最后无奈使用selenium进行登录,登录后将cookie传给requests的session继续使用,可以继续使用其访问其他接口
session=requests.session()
cookies=driver.get_cookies()
for cookie in cookies:
session.cookies.set(cookie['name'],cookie['value'])
项目执行顺序
以流水线中的执行顺序为例
项目实践
工作中的项目结构较为复杂,主系统是传统的jsp架构,系统后台通调用其他项目的接口返回,通过过滤处理,响应对应的数据到前端。工作时将框架作为工具使用取得了不错的效果,比如需要检查其他项目提供的数据是否可用,这时可以调用其他项目的接口,根据响应的状态码判断数据的有效性,调用主系统的接口,判断数据是否可用,以及爬取接口返回的html数据和其他项目返回数据做对比,判断开发在开发代码时是否有遗漏和疏忽的地方。项目对接口的返回处理使用了很多爬虫手段,与单纯使用selenium相比,速度会提升很多,也更为灵活,缺点是代码量实现难度相对大一些,封装的难度也较大。