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

新建闭环：货品 - 会员组（+ 会员策略）- 渠道 - 会员 - 货品库存

用 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.还未做到一个测试脚本只创建、一个接口清除创建的数据，如何传参有待思考
优化：不知道