职贝云数AI新零售门户

标题: Python+pytest+allure+log+yaml+mysql+钉钉企微告诉接口自动化框架 [打印本页]
作者: 5LHJF5    时间: 2022-12-30 15:16
标题: Python+pytest+allure+log+yaml+mysql+钉钉企微告诉接口自动化框架
框架引见
本框架次要是基于 Python + pytest + allure + log + yaml + mysql + redis + 钉钉告诉 + Jenkins 完成的接口自动化框架。
git地址: https://gitee.com/yu_xiao_qi/pytest-auto-api2
(, 下载次数: 8)


前言
公司忽然要求你做自动化，但是没有代码基础不知道怎样做？或者有自动化基础，但是不知道如何系统性的做自动化， 放在yaml文件中维护，不知道如何处理多业务依赖的逻辑？
那么这里 Gitte 中开源的自动化框架，将为你处理这些成绩。 框架次要运用 python 言语编写，结合 pytest 停止二次开发，用户仅需求在 yaml 文件中编写测试用例， 编写成功之后，会自动生成 pytest 的代码，零基础代码小白，也可以操作。
本框架支持多业务接口依赖，多进程执行，mysql 数据库断言和 接口呼应断言，并且用例直接在yaml文件中维护，无需编写业务代码， 接口pytest框架生成allure报告，并且发送 企业微信告诉/ 钉钉告诉/ 邮箱告诉/ 飞书告诉，灵敏配置。
完成功能
测试数据隔离, 完成数据驱动
支持多接口数据依赖: 如A接口需求同时依赖B、C接口的呼应数据作为参数
数据库断言: 直接在测试用例中写入查询的sql即可断言，无需编写代码
动态多断言: 如接口需求同时校验呼应数据和sql校验，支持多场景断言
自动生成用例代码: 测试人员在yaml文件中填写好测试用例, 程序可以直接生成用例代码，纯小白也能运用
代理录制: 支持代理录制，生成yaml格式的测试用例
统计接口的运转时长: 拓展功能，订制开关，可以决议能否需求运用
日志模块: 打印每个接口的日志信息，异样订制了开关，可以决议能否需求打印日志
钉钉、企业微信告诉: 支持多种告诉场景，执行成功之后，可选择发送钉钉、或者企业微信、邮箱告诉
自定义拓展字段: 如用例中需求生成的随机数据，可直接调用
多线程执行
目录结构
├── Cache // 存放缓存文件
├── common // 配置
│ ├── conf.yaml // 公共配置
│ ├── setting.py // 环境途径存放区域
├── data // 测试用例数据
├── Enums // 枚举层，用于存放项目中所需的枚举
├── File // 上传文件接口所需的文件存放区域
├── log // 日志层
├── report // 测试报告层
├── test_case // 测试用例代码
├── utils // 工具类
│ └── assertUtils // 断言
│ └── assertUtils.py
│ └── cacheUtils // 缓存处理模块
│ └── cacheControl.py
│ └── redisControl.py
│ └── logUtils // 日志处理模块
│ └── logControl.py
│ └── logDecoratrol.py // 日志装饰器
│ └── runTimeDecoratrol.py // 统计用例执行时长装饰器
│ └── mysqlUtils // 数据库模块
│ └── get_sql_data.py
│ └── mysqlControl.py
│ └── noticUtils // 告诉模块
│ └── dingtalkControl.py // 钉钉告诉
│ └── feishuControl.py // 飞书告诉
│ └── sendmailControl.py // 邮箱告诉
│ └── weChatSendControl.py // 企业微信告诉
│ └── otherUtils // 其他工具类
│ └── allureDate // allure封装
│ └── allure_report_data.py // allure报告数据清洗
│ └── allure_tools.py // allure 方法封装
│ └── error_case_excel.py // 搜集allure异常用例，生成excel测试报告
│ └── localIpControl.py // 获取本地IP
│ └── threadControl.py // 定时器类
│ └── readFilesUtils // 文件操作
│ └── caseAutomaticControl.py // 自动生成测试代码
│ └── clean_files.py // 清算文件
│ └── excelControl.py // 读写excel
│ └── get_all_files_path.py // 获取一切文件途径
│ └── get_yaml_data_analysis.py // yaml用例数据清洗
│ └── regularControl.py // 正则
│ └── yamlControl.py // yaml文件读写
│ └── recordingUtils // 代理录制
│ └── mitmproxyContorl.py
│ └── requestsUtils
│ └── dependentCase.py // 数据依赖处理
│ └── requestControl.py // 央求封装
│ └── timeUtils
├── Readme.md // help
├── pytest.ini
├── run.py // 运转入口
依赖库
allure-pytest2.9.45
allure-python-commons2.9.45
atomicwrites1.4.0
attrs21.2.0
certifi2021.10.8
cffi1.15.0
charset-normalizer2.0.7
colorama0.4.4
colorlog6.6.0
cryptography36.0.0
DingtalkChatbot1.5.3
execnet1.9.0
Faker9.8.3
idna3.3
iniconfig1.1.1
jsonpath0.82
packaging21.3
pluggy1.0.0
py1.11.0
pycparser2.21
PyMySQL1.0.2
pyOpenSSL21.0.0
pyparsing3.0.6
pytest6.2.5
pytest-forked1.3.0
pytest-xdist2.4.0
python-dateutil2.8.2
PyYAML6.0
requests2.26.0
six1.16.0
text-unidecode1.3
toml0.10.2
urllib31.26.7
xlrd2.0.1
xlutils2.0.0
xlwt1.3.0
安装教程
首先，执行本框架之后，需求搭建好 python、jdk、 allure环境
搭建python教程：http://c.biancheng.net/view/4161.html
搭建jdk环境：https://www.cnblogs.com/zll-wyf/p/15095664.html
安装allure：https://blog.csdn.net/m0_49225959/article/details/117194318
如上环境如都搭建好，则安装本框架的一切第三方库依赖，执行如下命令
pip3 install -r requirements.txt

(, 下载次数: 9)


假如在安装过程中出现如下 Could not find a version 相似的异常， 不用担心，能够是由于你安装的python环境 版本和我不分歧导致的，直接 pip install 库称号，不指定版本安装就可以了。
如上方截图说没有找到 asgiref==3.5.1,报错的意思是，没有找到3.5.1这个版本，那么直接控制台输入 pip3 install asgiref 停止安装即可
接口文档
这里非常感激一位安卓的冤家，给我引荐了开源的接口文件，框架中会针对开源接口中的登录、个人信息、收藏（新增、查看、修正、删除）等功能，编写结果自动化案例 下方是接口文档地址，大家可以自行查看（由于开源的接口，外面有些逻辑性的功能，如修正被删除的网址接口并没有过多的做判别， 因此用例中只写了一些基础的场景，仅供大家参考。） https://wanandroid.com/blog/show/2
如何创建用例
创建用例步骤
1、在data文件夹下方创建相关的yaml用例
2、写完之后，需求执行 utils\readFilesUtils\caseAutomaticControl.py 这个文件，生成自动化代码
3、执行caseAutomaticControl.py文件之后，会发现，在test_case层新增该条用例的对应代码，可直接执行该用例调试
4、当一切接口都编写好之后，可以直接运转run.py主程序，执行一切自动化接口
下面我们来看一下，如何创建用例
(, 下载次数: 14)


上方截图，就是一个用例中需求维护的相关字段，下面我会对每个字段的作用，做出解释。
(, 下载次数: 17)

如何发送get央求
上方了解了用例的数据结构之后，下面我们末尾编写第一个get央求方式的接口。 首先，末尾编写项目之后，我们在 conf.yaml 中配置项目的域名
(, 下载次数: 14)


域名配置好之后，我们来编写测试用例，在 data 文件下面，创建一个称号为 collect_tool_list.yaml 的用例文件，央求/lg/collect/usertools/json这个收藏网址列表接口，一切接口的详细信息，可以在接口文档中查看，下方不在做赘述
接口文档：https://wanandroid.com/blog/show/2
  1. # 公共参数
  2. case_common:
  3.   allureEpic: 开发平台接口
  4.   allureFeature: 收藏模块
  5.   allureStory: 收藏网址列表接口
  7. collect_tool_list_01:
  8.     host: ${{host()}}
  9.     url:/lg/collect/usertools/json
  10.     method: GET
  11.     detail: 查看收藏网址列表接口
  12.     headers:
  13.       Content-Type: multipart/form-data;# 这里cookie的值，写的是存入缓存的称号
  14.       cookie: login_cookie
  15.     # 央求的数据，是 params 还是 json、或者file、data
  16.     requestType: data
  17.     # 能否执行，空或者 true 都会执行
  18.     is_run:
  19.     data:
  20.       pageNum:1
  21.       pageSize:10# 能否有依赖业务，为空或者false则表示没有
  22.     dependence_case:False# 依赖的数据
  23.     dependence_case_data:assert:# 断言接口形态码
  24.       errorCode:
  25.         jsonpath: $.errorCode
  26.         type:==
  27.         value:0
  28.         AssertType:
  29.     sql:
复制代码
get央求我们 requestType 写的是 params ，这样发送央求时，我们会将央求参数拼接中url中，最终像服务端发送央求的地址格式会为：
如: ${{host()}}/lg/collect/usertools/json?pageNum=1&pageSize=10
如何发送post央求
  1. # 公共参数
  2. case_common:
  3.   allureEpic: 开发平台接口
  4.   allureFeature: 收藏模块
  5.   allureStory: 收藏网址接口
  7. collect_addtool_01:
  8.     host: ${{host()}}
  9.     url:/lg/collect/addtool/json
  10.     method: POST
  11.     detail: 新增收藏网址接口
  12.     headers:
  13.       Content-Type: multipart/form-data;# 这里cookie的值，写的是存入缓存的称号
  14.       cookie: login_cookie
  15.     # 央求的数据，是 params 还是 json、或者file、data
  16.     requestType: data
  17.     # 能否执行，空或者 true 都会执行
  18.     is_run:
  19.     data:
  20.       name: 自动化生成收藏网址${{random_int()}}
  21.       link: https://gitee.com/yu_xiao_qi/pytest-auto-api2
  22.     # 能否有依赖业务，为空或者false则表示没有
  23.     dependence_case:False# 依赖的数据
  24.     dependence_case_data:assert:# 断言接口形态码
  25.       errorCode:
  26.         jsonpath: $.errorCode
  27.         type:==
  28.         value:0
  29.         AssertType:
  30.     sql:
复制代码
这里post央求，我们需求央求的数据格式是json格式的，那么requestType 则填写为json格式。 包括 PUT/DELETE/HEAD 央求的数据格式都是一样的，独一不同的就是需求配置 reuqestType， 假如需求央求的参数是json格式，则requestType我们就填写json，假如是url拼接的方式，我们就填写 params
如何测试上传文件接口
首先，我们将一切需求测试的文件，全部都放在 files 文件夹中
(, 下载次数: 9)

  1. requestType:file# 能否执行，空或者 true 都会执行
  2. is_run:
  3. data:file:
  4.      file_name: 排入水体名.png
复制代码
在yaml文件中，我们需求留意两个地方，次要是用例中的requestType、和 filename 字段： 1、requestType: 上传文件，我们需求更改成 file 2、file: 假如是文件上传的话，就不需求要有file，然后我们上传的文件写在file下方 3、file_name: 首先，这个file_name是我们公司接口定义的上传文件的参数，排入水体名.png 这个是我们放在Files这个文件夹下方的文件称号 程序在执行的时分，会判别假如你的requestType为 file的时分，则会去执行file下方的参数，然后取到文件称号直接去执行用例
上传文件接口，即需求上传文件，又需求上传其他参数
  1. requestType:file# 能否执行，空或者 true 都会执行
  2. is_run:
  3. data:file:
  4.      file_name: 排入水体名.png
  5.   data:
  6.      is_upload:0
  7.   params:
  8.      collect: false
复制代码
上方的这个案例，央求参数即上传了文件，又上传了其他参数
1、file： 这里下方上传的是文件参数
2、data： 这个data下方是该接口，除了文件参数，还需求上传其他的参数，这个参数会以json的方式传给服务端（假如没有其他参数，可以不用写这个）
3、params： 这个是除了文件参数以外的，上传的其他参数，这个参数是拼接在url后方的

(, 下载次数: 10)


为了方便大家了解，上方将该参数，以postman的方式上传
多业务逻辑，如何编写测试用例
多业务这一块，我们拿个简单的例子举例，比如登录场景，在登陆之前，我们需求先获取到验证码。
(, 下载次数: 12)


(, 下载次数: 18)


首先，我们先创建一个 get_send_sms_code.yaml 的文件，编写一条发送验证码的用例
  1. # 公共参数case_common:allureEpic: 盲盒APP
  2.   allureFeature: 登录模块
  3.   allureStory: 获取登录验证码
  5. send_sms_code_01:host: ${{host()}}url: /mobile/sendSmsCode
  6.     method: POST
  7.     detail: 正常获取登录验证码
  8.     headers:appId:'23132'masterAppId: masterAppId
  9.       Content-Type: application/json;charset=UTF-8# 央求的数据，是 params 还是 json、或者filerequestType: json
  10.     # 能否执行，空或者 true 都会执行is_run:data:phoneNumber:"180****9278"# 能否有依赖业务，为空或者false则表示没有dependence_case:False# 依赖的数据dependence_case_data:assert:code:jsonpath: $.code
  11.         type: ==
  12.         value:'00000'AssertType:success:jsonpath: $.success
  13.         type: ==
  14.         value:trueAssertType:sql:
复制代码
编写好之后，我们在创建一个 login.yaml 文件
  1. # 公共参数case_common:allureEpic: 盲盒APP
  2.   allureFeature: 登录模块
  3.   allureStory: 登录
  5. login_02:host: ${{host()}}url: /login/phone
  6.     method: POST
  7.     detail: 登录输入错误的验证码
  8.     headers:appId:'23132'masterAppId: masterAppId
  9.       Content-Type: application/json;charset=UTF-8# 央求的数据，是 params 还是 json、或者filerequestType: json
  10.     # 能否执行，空或者 true 都会执行is_run:data:phoneNumber:18014909278code:# 能否有依赖业务，为空或者false则表示没有dependence_case:True# 依赖的数据dependence_case_data:-case_id: send_sms_code_01
  11.         dependent_data:-dependent_type: response
  12.             jsonpath: $.code
  13.             replace_key: $.data.code
  15.     assert:code:jsonpath: $.code
  16.         type: ==
  17.         value:'00000'AssertType:sql:
复制代码
其中处理多业务的核心区域，次要在这里:
  1. dependence_case:True# 依赖的数据dependence_case_data:-case_id: send_sms_code_01
  2.         dependent_data:-dependent_type: response
  3.             jsonpath: $.code
  4.             replace_key: $.data.code
复制代码
首先，我们 dependence_case 需求设置成 True，并且在下面的 dependence_case_data 中设计相关依赖的数据。
case_id：上方场景中，我们登录需求先获取验证码，因此依赖的case_id 就是发送短信验证码的 case_id ：send_sms_code_01
dependent_type：我们依赖的是获取短信验证码接口中的呼应内容，因此这次填写的是 response
jsonpath: 经过jsonpath 提取方式，提取到短信验证码中的验证码内容
replace_key：拿到验证码之后，我们将本条用例中的data中的code参数，那么我们运用jsonpath的方式，停止交换 $.data.code
多业务逻辑，需求依赖同一个接口中的多个数据
  1. dependence_case_data:-case_id: send_sms_code_01
  2.     dependent_data:# 提取接口呼应的code码-dependent_type: response
  3.         jsonpath: $.code
  4.         replace_key: $.data.code
  5.       # 提取接口呼应的accessToken-dependent_type: response
  6.         jsonpath: $.data.accessToken
  7.         # 交换央求头中的accessTokenreplace_key: $.headers.accessToken   
复制代码
如上方示例，可以添加多个 dependent_type
多业务逻辑，需求依赖不同接口的数据
假设我们需求获取 send_sms_code_01、get_code_01两个接口中的数据，用例格式如下
  1. dependence_case:True# 依赖的数据dependence_case_data:-case_id: send_sms_code_01
  2.     dependent_data:# 提取接口呼应的code码-dependent_type: response
  3.         jsonpath: $.code
  4.         replace_key: $.data.code
  5.   -case_id: get_code_01
  6.     dependent_data:# 提取接口呼应的code码-dependent_type: response
  7.         jsonpath: $.code
  8.         replace_key: $.data.code
复制代码
将依赖的数据直接存入缓存中
按照上方我们所写的，如今用到的是 replace_key去对原先用例中的内容停止交换，当然我们也提供了可以直接将数据存入缓存中 这里我们需求用到set_cache的关键字。
  1. -case_id: get_code_01
  2.     dependent_data:# 提取接口呼应的code码-dependent_type: response
  3.         jsonpath: $.code
  4.         # 讲我们提取到的内容直接存入缓存中，set_cache后方定义的值，是我们缓存的称号# 称号可以自定义， set_cache 和 repalce_key 的方法可以二选一，两种都支持set_cache: verify_code
复制代码
将当前用例的央求值或者呼应值存入缓存中
有些小伙伴之前有反馈过，比如想要做数据库的断言，但是这个字段接口没有前往，我应该怎样去做校验呢？ 程序中提供了current_request_set_cache这个关键字，可以将当前这条用例的央求数据 或者呼应数据 给直接存入缓存中 如下案例所示：
  1. current_request_set_cache:# 1、response 从呼应中提取内容  2、request从央求中提取内容-type: response
  2.     jsonpath: $.data.data.[0].id
  3.     # 自定义的缓存称号name: test_query_shop_brand_list_02_id
复制代码
央求用例时参数需求从数据库中提取
(, 下载次数: 10)


如上图所示，用例中的 dependent_type 需求填写成 sqlData。 当你的依赖类型为 sqlData 数据库的数据时，那么下方就需求再加一个 setup_sql 的参数，下方填写需求用到的sql语句
留意case_id： 由于程序设计缘由，通常状况下，我们关联的业务，会发送接口央求，但是假如我们依赖的是sql的话， 是不需求发送央求的，因此我们假如是从数据库中提取数据作为参数的话，我们case_id 需求写self ，方便程序中去做区分
  1. ApplyVerifyCode_01:host: ${{host}}url: /api/v1/merchant/apply/verifyCode
  2.     method: GET
  3.     detail: 校验曾经审核经过的供应商手机号码
  4.     headers:Content-Type: application/json;charset=UTF-8# 央求的数据，是 params 还是 json、或者file、datarequestType: params
  5.     # 能否执行，空或者 true 都会执行is_run:data:mobile:18811111111authCode:123456# 能否有依赖业务，为空或者false则表示没有dependence_case:True# 依赖的数据dependence_case_data:-case_id: self
  6.         dependent_data:-dependent_type: sqlData
  7.             jsonpath: $.username
  8.             replace_key: $.data.mobile
  10.     assert:code:jsonpath: $.code
  11.         type: ==
  12.         value:200AssertType:applyId:jsonpath: $.data[0].applyId
  13.         type: ==
  14.         value: $.applyId
  15.         AssertType: SQL
  16.       applyStatus:jsonpath: $.data[0].applyStatus
  17.         type: ==
  18.         value: $.applyStatus
  19.         AssertType: SQL
  21.     sql:- select a.apply_id as applyId, a.to_status as applyStatus, a.sub_biz_type as subBizType, a.operator_name as operatorName, a.operator_user_id as operatorUserId, b.apply_type as applyType from test_obp_midware.apply_operate_log as a inner join test_obp_midware.apply as b on a.apply_id = b.id where b.id = $json($.data[0].applyId)$ order by a.id desc limit 1;
  22.     setup_sql:- SELECT * FROM test_obp_user.user_biz_info where user_id = '300000405'
复制代码
用例中需求依赖登录的token，如何设计
首先，为了防止反复央求调用登录接口，pytest中的 conftest.py 提供了热加载机制，看上方截图中的代码，我们需求在 conftest.py 提早编写好登录的代码。
如上方代码所示，我们会先去读取login.yaml文件中的用例，然后执行获取到呼应中的token，然后 编写 Cache(‘work_login_init’).set_caches(token)，将token写入缓存中，其中 work_login_init 是缓存称号。
编写好之后，我们会在 requestControl.py 文件中，读取缓存中的token，假如该条用例需求依赖token，则直接停止内容交换。
(, 下载次数: 5)

  1. @pytest.fixture(scope="session", autouse=True)
  2. def work_login_init():
  3.     """
  4.     获取登录的cookie
  5.     :return:
  6.     """
  7.     url = "https://www.wanandroid.com/user/login"
  8.     data = {"username":18800000001,"password":123456}
  9.     headers = {'Content-Type':'application/x-www-form-urlencoded'}# 央求登录接口
  10.     res = requests.post(url=url, data=data, verify=True, headers=headers).json()
  11.     token = res['response']['token']
  13.     CacheHandler.update_cache(cache_name='work_login_init', value=token)
复制代码
这里在编写用例的时分，token 填写我们所编写的缓存称号即可。
(, 下载次数: 23)


用例中依赖cookie如何设计
(, 下载次数: 16)


首先我们在conftest.py中编写获取cookie的方法
  1. @pytest.fixture(scope="session", autouse=True)
  2. def work_login_init():
  3.     """
  4.     获取登录的cookie
  5.     :return:
  6.     """
  7.     url = "https://www.wanandroid.com/user/login"
  8.     data = {"username":18800000001,"password":123456}
  9.     headers = {'Content-Type':'application/x-www-form-urlencoded'}# 央求登录接口
  10.     res = requests.post(url=url, data=data, verify=True, headers=headers)
  11.     response_cookie = res.cookies
  13.     cookies = ''
  14.     for k,v in response_cookie.items():
  15.         _cookie = k + "=" + v + ";"
  16.         # 拿到登录的cookie内容，cookie拿到的是字典类型，转换成对应的格式
  17.         cookies += _cookie
  18.         # 将登录接口中的cookie写入缓存中，其中login_cookie是缓存称号
  19.         CacheHandler.update_cache(cache_name='login_cookie', value=cookies)
  20. 和token一样，我们假如用例的央求头中依赖cookie, cookie中的值，直接写我们存入缓存中的称号即可
  22.     headers:Content-Type: multipart/form-data;
  23.       # 这里cookie的值，写的是存入缓存的称号cookie: $cache{login_cookie}
复制代码
用例中如何生成随机数据
比如我们有些特殊的场景，能够会触及到一些定制化的数据，每次执行数据，需求按照指定规则随机生成。
(, 下载次数: 12)


如上图所示，我们用例中的 reason 审核缘由后方，需求展现审核的当前工夫。那么我们首先需求封装一个获取当前工夫的方法
(, 下载次数: 9)


那么我们就在 regularControl.py 文件中，编写 get_time 的方法。编写好之后，在用例中编写规则如下：
  1. reason: 审核工夫${{get_time()}}
复制代码
运用 ${{函数称号()}}的方法，程序调用时，会生成当前工夫。在regularControl.py 文件中，我还封装了一些常用的随机数，如随机生成男生姓名、女生姓名、身份证、邮箱、手机号码之类的，方便大家运用。 如，随机生成邮箱，我们在用例中编写的格式为 ${{get_email}} 。
其他所需随机生成的数据，可在文件中自行添加。
自动化函数传递参数
首先异样和上方一样，创建一个随机生成的方法，改方法支持接收参数
  1. @classmethod
  2. def random_int(cls, min_num,max_num):
  3.     """
  4.     随机生成指定范围的随机数
  5.     @param min_num: 最小数字
  6.     @param max_num: 最大数字
  7.     @return:
  8.     """
  9.     num = random.randint(int(min_num), int(max_num))
  10.     return num
复制代码
在用例中，假设我们需求获取一个 1-10之间的随机数，那么我们直接这样调用该数据即可
  1. reason:{{random_int(1， 10)}}
复制代码
断言http呼应形态码
置信有些小伙伴在做接口测试的过程中，有部分接口是没有任何呼应的，那么在没有呼应数据的状况下 我们就只能经过 http的形态码去判别这条用例能否经过，我们可以这样写
  1. assert:status_code:200
复制代码
我们直接在assert下方添加一个 status_code 参数，形态码我们判别其为 200
用例中添加等待工夫
程序中可以设定接口央求之后，等待时长，假设A接口依赖B接口的业务，A接口央求完时，我们需求让他等待几秒钟 再次央求B接口，这样的话，我们可以运用sleep关键字
  1. sleep:3
复制代码
断言类型
下放截图中，是一切断言支持的类型
(, 下载次数: 8)


用例中如何停止接口断言和数据库断言
假设如今我需求测试一个报表统计的数据，该接口前往了义务的处理时长 和 处理数量。功能如下截图所示：
(, 下载次数: 6)


假设下方是我们拿到接口呼应的数据内容：
  1. {"code":200,"times":155.91,"counts":9}
复制代码
这个时分，我们需求判别该接口前往的数据能否正确，就需求编写sql，对呼应内容停止校验。
(, 下载次数: 14)


因此我们编写了如上sql，查出对应的数据，那么用例中编写规则如下，下方我们分别断言了两个内容，一个是对接口的呼应code码停止断言，一个是断言数据库中的数据。
  1. assert:code:jsonpath: $.code
  2.       type: ==
  3.       value:200# 断言接口呼应时，可以为空AssertType:do_time:# jsonpath 拿到接口呼应的数据jsonpath: $.times
  4.       type: ==
  5.       # sql 查出来的数据，是字典类型的，因此这里是从字段中提取查看出来的字段value: $.do_time
  6.       # 断言sql的时分，AssertType 的值需求填写成 SQLAssertType: SQL
  7.    question_counts:jsonpath: $.counts
  8.       type: ==
  9.       # value: $.question_counts
  10.       # 断言sql的时分，AssertType 的值需求填写成 SQLAssertType: SQL
  11.   sql:- select * from test_goods where shop_id = 515
复制代码
我们分别对用例的数据停止讲解，首先是呼应断言, 编写规则如下
  1. code:# 经过jsonpath获取接口呼应中的code {"code": 200, "times": 155.91, "counts": 9}jsonpath: $.code
  2.   type: ==
  3.   value:200# 断言接口呼应时，可以为空AssertType:
复制代码
下面是对sql停止断言
  1. question_counts:# 断言接口呼应的成绩上报数量counts {"code": 200, "times": 155.91, "counts": 9}jsonpath: $.counts
  2.       type: ==
  3.       # 查询sql，我们数据库查到的数据是一个字段，数据是这样的：{question_counts: 13, do_time: 1482.70}, 这里我们经过 jsonpath获取question_countsvalue: $.question_counts
  4.       # 断言sql的时分，AssertType 的值需求填写成 SQLAssertType: SQL
  5.   sql:- SELECT round( sum(( UNIX_TIMESTAMP( filing_time )- UNIX_TIMESTAMP( report_time )) / 60 ) / 60, 2 ) AS do_time, count( id ) AS question_counts FROM fl_report_info WHERE state IN ( 1, 3 )
复制代码
有些细心的小伙伴会发现，我们的sql，是列表类型的。这样就意味这，我们的sql可以同时编写多条，这样会对不会编写多表联查的小伙伴比较敌对，可以停止单表查询，获取我们需求的数据。
  1. sql:- select * from users;
  2.   - select * from goods;
复制代码
运用teardown功能，做数据清洗
通常状况下，我们做自动化一切新增的数据，我们测试完成之后，都需求讲这些数据删除，程序中支持两种写法 一种是直接调用接口停止数据删除。另外一种是直接删除数据库中的数据，建议运用第一种，直接调用业务接口删除对应的数据
1、下面我们先来看看第一种删除方式，teardown的功能，由于需求兼容较多的场景，因此运用功能上相对也会比较复杂 需求小伙伴们一个一个去渐渐的了解。
下面为了方便大家对于teardown功能的了解，我会针对不同的场景停止举例：
假设如今我们有一个新增接口，写完之后，我们需求先调用查询接口获取到新增接口的ID，然后再停止删除 那么此时会设计到两个场景，首先执行新增接口ID，然后再拿到呼应（这里有个逻辑上的先后关系，查询接口，是先发送央求，在提取数据） 获取到查询的ID之后，我们在执行删除，删除的话，我们是直接发送央求
那么针对这个场景，我们就需求有个关键字去做区分，什么场景下先发送央求，什么场景下后发送央求，下面我们来看一下案例，方便大家了解
  1. teardown:# 查看品牌审核列表，获取品牌的apply_id-case_id: query_apply_list_01
  2.     # 留意这里我们是先发送央求，在拿到本人呼应的内容，因此我们这个字段需求写param_prepareparam_prepare:# 由于是获取本人的呼应内容，我们dependent_type需求写成 self_response-dependent_type: self_response
  3.         # 经过jsonpath的方法，获取query_apply_list_01这个接口的呼应内容jsonpath: $.data.data.[0].applyId
  4.         # 将内容存入缓存，这个是自定义的缓存称号set_cache: test_brand_apply_initiate_apply_01_applyId
  5.         
  6.         # 支持同时存多个数据，只会发送一次央求-dependent_type: self_response
  7.         jsonpath: $.data.data.[0].brandName
  8.         set_cache: test_brand_apply_initiate_apply_01_brandName
  9.    
  10.   # 删除-case_id: delete_01
  11.     # 删除的话，我们是直接发送央求的，因此我们这里写 send_requestsend_request:# 我们上方曾经拿到了ID，并且将ID存入缓存中，因此这里依赖数据的类型为cache，直接从缓存中提取-dependent_type: cache
  12.         # 这个是缓存称号cache_data: test_brand_apply_initiate_apply_01_applyId
  13.         # 经过relace_key 去交换 delete_01 中的 applyID参数replace_key: $.data.applyId
复制代码
那么有些小伙伴会在想，异样我们以上方的接口场景为例，有些小伙伴会说，我公司的新增的接口，有直接前往ID，不需求调用查询接口 程序中当然也支持这种场景，我们只需求这么编写
  1. -case_id: process_apply_01
  2.   # 异样这么写 send_requestsend_request:# 这里我们从呼应中获取-dependent_type: response
  3.       # 经过jsonpath的方式，获取呼应的内容jsonpath: $.data.id
  4.       # 运用repalce_key停止交换replace_key: $.data.applyId  
复制代码
程序中也支持从央求外面获取内容，编写规则如下
  1. -case_id: process_apply_01
  2.   # 异样这么写 send_requestsend_request:# 这里我们从呼应中获取-dependent_type: request
  3.       # 经过jsonpath的方式，获取央求的内容jsonpath: $.data.id
  4.       # 运用repalce_key停止交换replace_key: $.data.applyId
复制代码
自动生成test_case层代码
小伙伴们在编写好 yaml 用例之后，可以直接执行 caseAutomaticControl.py ，会跟你设计的测试用例，生成对应的代码。
(, 下载次数: 8)


发送钉钉告诉告诉
(, 下载次数: 10)


发送企业微信告诉
(, 下载次数: 14)


日志打印装饰器
(, 下载次数: 11)


在requestControl.py中，我单独封装了一个日志装饰器，需求的小伙伴可以不用改动代码，直接运用，假如不需求，直接注释，或者改成False。控制台将不会有日志输入
统计用例运转时长
(, 下载次数: 10)


异样，这里封装了一个统计用例运转时长的装饰器，运用改装饰器前，需求先停止导包
  1. from utils.logUtils.runTimeDecoratorl import execution_duration
复制代码
导入之后，调用改装饰器，装饰器中填写的用例执行时长，以毫秒为单位，如这里设置的2000ms，那么假如该用例执行大于2000ms，则会输入一条告警日志。
  1. @execution_duration(2000)
复制代码
生成allure报告
我们直接运转主程序 run.py ，运转完成之后，就可以生成美丽的allure报告啦~
(, 下载次数: 9)


(, 下载次数: 10)


其他
本框架为2.0晋级版本，晋级之后的功能，如今基本上都是在yaml中维护用例，无需测试人员编写代码， 和 1.0版本的区别在于，1.0版本还需求测试人员手动编写多业务逻辑的代码，需求有一定基础编码的才能
但是1.0版本，异样也可以自动生成代码，yaml中维护数据，对相对简单，假如偏于yaml简单维护的同窗，可以切换查看1.0分支 下方是1.0分支的操作文档：点我查看
以上便是整个框架的运用阐明，这个框架属于个人专业工夫开发，大家假如在运用中遇到什么成绩，或者有相关建议，可以随时反馈给我， _框架内容会随着大家的反馈，持续更新！邮箱地址：1602343211@qq.com
假如觉得框架有协助到你，费事收藏一下哦~~谢谢。



欢迎光临 职贝云数AI新零售门户 (https://www.taojin168.com/cloud/) Powered by Discuz! X3.5