接口测试 测试小白 - 接口自动化从 0 到 1-持续优化中(第一篇)

褐茶 · 2024年07月15日 · 最后由 褐茶 回复于 2024年07月18日 · 7323 次阅读

搭建一个应用场景的接口自动化

新建闭环:货品 - 会员组(+ 会员策略)- 渠道 - 会员 - 货品库存

用 abcde 替代五个接口,接口关系:
a 接口的返参货品 id 是 e 接口的入参,b 接口的返参体系组 id 和会员策略 d 是 c 接口的入参,c 接口的返参渠道 id 是 d 接口和 e 接口的入参。

删除闭环(目前并未做到): 货品库存 - 会员 - 渠道 - 会员组(+ 会员策略)- 货品

目录结构


其中目前实际用到的只有 APIs,data,report,TestCase 四个目录,还有 config.py、pytest.ini。
目录结构的缺陷:很多目录层没有用到

config.py 此文件用于配置服务器地址、请求头,项目根路径。


config 文件缺陷:目前没有做登录初始化,而是直接用的固定永久性请求头来登录,后续需要优化

pytest.ini 文件配置 pytest 的一些设置:设置存放 report 的目录、测试脚本层目录、测试文件开头前缀、测试类开头前缀、测试方法前缀

[pytest]
addopts = -s --alluredir report
testpaths = ./TestCase
python_files = test*.py
python_classes = Test*
python_functions = test*

API 层

定义了货品、会员组(+ 会员策略)、渠道、会员、货品库存这五个实体的增删改查
GoodsAPI:货品

MemberSystemAPI:包含了会员策略的 api

ChannelAPI:渠道

MemberAPI:会员

GoodsInventoryAPI:货品库存

API 层的缺陷:api 层的初始化是将接口的 url 和 moduleid 进行定义,一个接口对于五六条 url 和 moduleid,目前只做五个接口还好,后期如果持续扩大接口数量,初始化中的 url 维护起来会比较麻烦,要单独找接口 api 进行修改
API 层的优化:可能会把所有接口的 url 放到配置层或者一个 yaml 文件进行读取,再看看吧。

测试用例层

测试用例层使用 parametrize 来进行参数化传参,所以用到了公用方法 build_data,但是目前还没封装到公用脚本层,作用是:读取 json 文件中的 json 数据,并用 list 形式存放到元组:
def build_data(json_file):
json_list = []
with open(json_file,"r",encoding="utf-8") as f:
json_data = json.load(f)
for case_data in json_data:
data = case_data.get("data")
moduleId = case_data.get("moduleId")
json_list.append((data,moduleId))
return json_list

Goods 测试用例:
此用例定义两个 test 方法,一个是用来创建并审核货品,一个是反审核并删除货品。并且定义了类变量:GoodsBillIdList,GoodsBillId。分别用于删除和反审核的传参,但也有明显的缺陷,就是删除的传参依赖于创建时的返参,要执行删除操作必须执行整个测试类,删除依赖于创建,无法单独做闭环。

MemberSystem 测试用例:D1 接口的创建需要 D2 接口的创建后的返参作为入参,因为又是参数化从 json 数据中拿值,解决方法是:test01 中存储为类变量,在 test02_MemberPolicyCreate 中,用类变量 memberSystemId 替换文件拿的 data 值中的 memberSystemId 字段。


Channel 测试用例:还没做删除,和 goods 的删除一样的,严重依赖于创建时的传参

Member 测试用例:

GoodsInventory 测试用例:

缺陷:
1.build_data 没有封装公用方法
2.删除的传参依赖于创建时的返参,要执行删除操作必须执行整个测试类,删除依赖于创建,无法单独做闭环。
3.因为是 parametrize 读取 json 文件进行取值,有些接口的关联参数需要定义为类变量并替换参数的值,不够简洁
4.对于接口之间关联的字段
5.还未做到一个测试脚本只创建、一个接口清除创建的数据,如何传参有待思考
优化:不知道

共收到 14 条回复 时间 点赞

今天吃完饭继续优化

褐茶 回复

可以不吃饭就优化嘛

用 yaml 的话感觉更简洁一些吧

CmYzzZ 回复

在优化了,感觉自己现在在加工一坨翔

Kirakuin 回复

认同并给你点了个赞

挺好的,起码楼主行动起来了,加油

一些个人的建议哈:

  1. 建议不要直接用 request ,可以做一层公共的封装。 好处是后面如果想做一下 log 的增加,统计每个请求的时间,或者做一些自定义的功能, 就可以直接在公共方法里面做,不用所有地方都改一遍。
  2. 关于前置请求, 数据初始化之类的,考虑一下 pytest fixture
Jerry li 回复

感谢大佬的建议,对我帮助很大!😀

白展堂 回复

哈哈哈哈谢谢大佬鼓励

褐茶 #10 · 2024年07月17日 Author

最近又忙起来了,有空继续学习,目前这个框架都算不上的玩意是自己看了几篇文章就瞎写的,欢迎各位大佬留言给家建议!

好强,大佬

住下了

褐茶 #13 · 2024年07月18日 Author
Putao0v0 回复

最近测试任务重,没啥时间研究,有第二篇再踢你,欢迎小伙伴交流学习

褐茶 #14 · 2024年07月18日 Author
lujunxian 回复

借鉴了很多前辈的思路,担不起大佬😁

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册