好久没写了，这段时间接触的东西有点琐碎，加上比较懒，一直拖到现在，弄了httprunner有半个月了，渐渐有点眉目，暂时记录下。
代码结构上，分用例执行层，testcase
通用请求管理层api
数据库查询相关service
配置项config
用例执行层按照业务模块功能划分
在单个用例上，保持统一规范，包含描述信息
! /usr/bin/env python3
--coding:utf-8 --
"""
File : case_volume_backup_image_volumes_del_test.py.py
Time ：2021/6/3 10:34
Author ：xxx
version ：python 3.7
Description：此处可以关联禅道的用例，或者jira
"""
整个的请求代码类似，包含变量配置，基础url的获取，然后是测试步骤，测试步骤包含call的调用，然后当前用例关键步骤的调用。调用的具体请求放置api中，方便后续多场景功能下串联。
整体过程还算中规中矩，这里主要说明里面teardown_hook的使用场景和实现，之所以引用teardown_hook是因为触发接口请求时候，有些接口状态只是单纯的请求，至于是否能否成功，还需要从数据库里面对应的某些字段状态进行查询，所以做了一个验证。让用例执行结果更真实性。
.teardown_hook("volume_id, status, available)}")
拿这句来讲，暴露给用例层，主要是查询数据库里面的接口层返回字段特征值的的一个状态，如果这个状态为available，那么就是可用。
对于里面的调用关系，如下图
从单独的view层进行定义，def query_volume_fromid_wait(querysource, querykey, expectkey, defaulttime=3600):
query_db_status(querysource, querykey, expectkey, query_volid_status, defaulttime=defaulttime)
里面包含对数据库中接口功能对应表的查询，和具体的查询语句，以及具体数据库查询的输出
query_db_status主要是动态查询功能-db_tool_public.py中
query_volid_status是具体的表里面的功能查询--放到单独业查询数据库中
def query_volid_status(id):
ret = query_table_id_status(CinderVolume, id)
return ret
针对里面的查询的状态query_table_id_status，-db_tool_public.py中
def query_table_id_status(tableobj, id):
print(tableobj)
print(id)
row_datas = tableobj.select().where(tableobj.id == id).order_by(tableobj.updated_at.desc())
print(row_datas)
ret = exchange_bulk(row_datas)
return ret
里面的exchange_bulk规划在util中，作为查询数据库的一个通用的规范
具体的数据库连接信息从配置文件中获取，方便后续环境维护
[图片上传中...(image.png-66213b-1623746892425-0)]
可以从本地调试运行
hrun -s -v xxx.py
注意：
用例名称必须_test结尾
git的保存
可用进行简单维护
git status ---检测跟git上代码差异
git add xxx---增加代码
git commit -m "xxx"--添加备注
git pull origin master
git push origin master----提交
配置Jenkins，填写git地址，以及git账号和密码
对其基础环境进行部署和安装
因为Jenkins里面已经集成了allure，所以当httprunner里面不需要再次执行allure generate report
报告是这样的，