Python+Django+Requests+Pytest+Alure测试框架设计思路

项目背景

项目是一个传统的web端，技术架构采用jsp架构。
基于这种项目架构，项目已经有UI自动化，并已经做的比较成熟，但出于各种原因，框架缺少测试前后数据的处理，这部分工作可以通过基于框架外的其他脚本实现，同时框架的特点是方便上手，相对于方便，但是也有其缺点，执行速度较慢，实现的功能有限。
为了提高测试的准确性和提升工作效率，工作中开发了很多小工具，后来发现这些小工具有代码耦合部分，可以将公共部分提取出来。
框架实现的主要部分是pytest+django，pytest可以集成很多插件，方便测试用例的执行，django可以将此框架拓展成测试平台，也方便开发微服务，为postman等其他接口工具调试提供便利。框架也集成了其他库，Requests调用接口，allure产生测试报表，DB驱动连接数据库，csvReader,csvWriter,openpyxl等处理测试数据，Re,BeautifulSoup处理返回结果。

设计思路

1. 搭建整体框架 包含 项目基础配置(django,pip配置)，工具类，fixture前后置管理，测试输入输出数据，测试策略main入口，测试日志，测试用例，测试报表，外部依赖等
2. 编写测试用例公共部分，如测试用例在不同项目的登录和登出，编写在fixture里面
3. 编写第一版测试用例
4. 继续优化提取公共部分
5. 参数化测试数据，将测试数据提取到配置文件或者数据文件中
6. 根据功能，作者，场景等为测试用例添加标签方便统计
7. 添加执行策略，编写main入口
8. 添加日志报表
9. 优化执行策略，适应于不同的测试环境
   10.自定义命令行参数，生成模板测试用例

项目结构

1. django的包，进行django的基本配置。可以提供开发微服务，日志，项目的根目录等功能。
2. util包:提供一系列框架中需要使用的工具，主要包含
   1. config类 主要使用到configparser(),读取.ini配置文件
   2. db类
      1. 封装不同数据库操作的增删改查方法
      2. 工具类调用不同的数据库给外界使用
   3. public类 封装openpyxl，csv，以及默认库的读写操作，BeautifulSoup，Re处理接口返回数据
   4. remote类 使用paramiko进行远程连接，可以作为某些测试用例的前置后置数据处理
   5. requests类 基于不同协议发送请求的封装，http协议使用request库的get post delete put等方法
   6. settings类 提供django的logger和项目根目录给其他类使用
3. file包
   1. config 一些项目运行的环境信息，如DB,请求的Host和一些必要参数等。不同环境维护在不同的文件上，其中有一个文件作为读取文件，其他文件维护不同环境的配置信息。当把项目放在流水线时只需要传递必要的参数，将其他环境的配置信息通过io读写，写到读取配置的文件。
   2. result 存放测试用例执行的结果，便于结果分析，也可以作为执行用例的evidence使用
   3. test_data 测试用例用到的测试数据，数据选型主要用到csv文件和xlsx文件两种形式，其中csv文件内存会更小，xlsx文件使用相对方便，相比于xls文件格式占用内存也会更小。
   4. lib 某些接口传参需要依赖其他语言对传参进行加密处理，该目录存放该类文件，可以通过python调用处理不同语言的第三方库处理这些文件。
4. test case包
   1. pytest.ini pytest的配置，根据项目的需求可以将pytest.ini放到不同的位置
   2. fixture 测试用例的前置和后置处理，比如登录和登出等操作，对于通过session管理登录状态的，登录后返回session，对于通过token登录的，将获取到的鉴权加入到header中返回。
5. 日志包 存放测试用例执行的日志，加入流水线时保存到文件里，本地调试输出到控制台
6. report包 主要包含allure的测试报告,流水线中allure会捕获django RotatingFileHandler的日志
7. mange.py django的执行入口
8. main包 测试用例执行的入口，在此维护测试用例的执行策略，也可以赋予根据标签统计等功能。对于用例执行可以维护成读取接口入参或者cmd入参或者pytest自定义参数的形式，主要包含两个动作
   1. 根据接入的传参确定取哪个配置文件的信息，切换不同的测试环境
   2. 根据传参确定执行哪些测试用例
9. 另外在测试用例执行时有一部分耦合，比如不同的接口测试用例都需要检查联通性返回结果是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相比，速度会提升很多，也更为灵活，缺点是代码量实现难度相对大一些，封装的难度也较大。