带薪摸鱼的第一天之光明正大写的自动化测试框架

前言：本篇文章非教程，仅简单的分享自己的所学所得，主要介绍框架的组成、测试用例维护、接口维护等几个方面。

1.框架组成

python3 + requests + unittest + ddt + db；

不说废话，上图：

解释：

• allure-report：allure跑完测试用例后自动生成
• allure-result：allure结果数据，非可视化，需要命令去进行可视化
• common：公共配置模块，供接口使用
  • base_cls.py：继承了unittest的基类，其它api类继承此类
  • encrypt_handler.py：加解密的封装
  • logger_method.py：logging的封装，主要作用到执行测试用例时记录相关操作日志
  • mongodb_method.py：pymongo的封装，对数据库内数据的增删改查
  • my_method.py：自定义封装，针对需要进行上下游关联的接口做的特殊处理
  • mysql_method.py: pymysql的封装，对数据库内数据的增删改查
  • openpyxl_method.py：openpyxl的封装，对excel文件内的数据进行读取编译
  • report_method.py：HTMLTestRunner、BeautifulReport两种测试报告的封装，可通过传入的参数选择使用哪种报告
  • requests_method.py：requests的封装，通过传入的mode进行判断需要哪种请求方式来调用对应的代码
• datacase：测试用例的excel文件，一个接口一个sheet表
  • SupTech_Case_Data.xlsx
• lib：第三方库
  • HTMLTestRunnerNew.py
  • .....
• logs：日志文件，测试用例执行过程中产生的日志：执行日志、断言日志、错误日志
  • log.log
• result：HTMLTestRunner、BeautifulReport 跑出来的测试报告
  • 2021-12-15 10时48分06秒VERIFY.html
  • 2021-12-17 14时02...
  • ...
• test_api：测试接口，一个接口一个.py文件
  • conftest.py：收集测试用例执行统计的数据，在发送邮件的时候写入邮件内 测试用例总x条、通过x条、失败x条
  • test_login_01.py：接口文件
  • ...
• testng_result：统计测试用例的执行结果，哪一条PASS，哪一条FAIL
  • testng-results.xml
• main.py：运行主入口文件
• settings.py：配置文件
  • 项目各种地址：测试报告、log、测试用例...
  • 封装的函数所需要传入的实参dict格式：headers、接口地址、mongodb、pymysql、测试报告、日志
  • 个别的数据，反正感觉自己需要写进去的，可自由发挥
• Pipfile：Pipfile 文件用于指定Python应用程序或库的包需求，包括开发和执行（此项目为pipenv虚拟环境，通过pipenv生成的包文件，记录着安装的包，方便项目移植，管理环境）
• Pipfile.lock：根据 Pipfile 和当前环境自动生成的 JSON 格式的依赖文件

以上的代码包并非固定，只是根据个人、当前项目需要可自行更改或者添加一些相关支持的包或者封装。

2.执行时序图

以前整理框架的时候画的，大概就是这么个意思，差别不大，我简单的梳理了一下：

1. 首先由jenkins/手动执行main.py文件，收集测试用例集合；
2. 执行接口测试，初始化数据库，向数据库插入测试数据，做执行测试用例前置工作；
3. 调用接口，通过ddt数据驱动读取excel用例，进行解析出可用测试数据格式；
4. 发送请求数据，根据预期结果进行数据断言；
5. 执行、断言接口产生日志，打印到控制台、log.log文件内；
6. 生成测试报告数据；
7. 把生成最新的测试报告数据文件通过jenkins发送指定的邮箱。

来个更详细的：

 3.测试用例维护：

解释：

• id：测试用例编号
• title：测试用例项，主要验证什么
• mode：接口的请求方式 get、post、del...
• interface：接口标记字段，此字段非接口地址，可以理解为真正的接口地址是一个字典里的value，此字段为key
• headers：标记字段，一般用来常规鉴权提取，比如headers里面需要携带token，则该单元格内我会写成{“headers”：“#headers#”}此方式，在接口类中去匹配对应key的参数
• body_data：测试用例的json格式报文，需要注意的是，一些参数需要进行变量化的，通常用"#name#"形式去标记，比如：我需要去某个地方（数据库/setupclass内）提取对应的name的参数，那么我在这个json 里面就会写成“name”：“#name#”，其中“##”用来供正则匹配过滤，name用来寻找我要提取的对应参数；
• extract：作用为标记需要提取的某个参数，比如我需要当前一条case提取返回参数A的值，那么我就会在此列以{“A”：“A”}的形式填入单元格，当我在接口内容去使用提取参数的函数的时候，函数会自动匹配提取当前A参数的值，通过setattr写入至当前class；
• expected：为预期结果code码或其它任意值
• sql：一般不写真正的sql语句，只用来判断字段是否存在，是否需要做什么
• msg：预期结果接口对应的返回信息数据
• description：测试用例描述，Allure报告内显示方便理解

其中类似headers、extract、sql、msg在我的理解都是标记字段，方便代码读的懂，所以有时候我们要在这些字段里面添加一些东西来让代码明白我们要做什么事情，比如：if case['sql']：意思是如果sql这个字段里面存在数据我会怎样怎样，否则就怎样怎样，类似这种判断。

 4.接口维护

解释：

1. 导入相关包、导入base基类（继承了unittest类）；
2. 创建类继承该base基类；
3. 定义当前接口名称、读取测试用例数据；
4. 重载SetupClass，做前置准备工作；
5. 定义测试函数，使用ddt框架；
6. 传入Allure报告内需要展示的数据；
7. 拼接url、获取body数据、并发送接口；
8. 拿到返回数据后进行断言操作，通过则打印通过的日志；
9. 失败打印接口相关数据及返回数据信息；

 以上只是一个范例，可根据当前接口自由组合调用函数，来达到需求（其中类似Allure报告内展示的代码和断言代码其实都是可以省略的，比如写到base类中或者随便你自己如何封装，因为每个接口几乎都会有这种代码，可以节省一部分代码量，我是为了解释的清楚所以把这部分代码又拉出来了）

5.推送更新的代码至github

  框架已经集成github和Jenkins，所以每次修改代码后，都需要把代码推送至github，因为Jenkins拉代码的地址写的是GitHub的地址

参考：

 更新完代码后，在pycharm->Terminal内敲以上命令可成功推送代码至github

6.邮件

7.Allure测试报告

报告总览：

成功的测试用例：

 失败的测试用例：

失败的测试用例会显示错误代码直接定位至代码块，会显示回溯log日志方便排查问题

先介绍到这里吧，后续我会分享自己学习的框架从第一步开始到最后集成Jenkins是如何搭建起来的。