最开始搭建 pytest 接口自动化，我是跟着这篇https://testerhome.com/topics/23441文章一步步搭成功。
但是后来各种原因没有继续使用下去，主要原因有两个：
1）因为在 yaml 里面维护 path 和 method ，如果我要测试两组数据，params 有 20 个字段，我就要复制非常长的数据，所以觉得挺不方便。但是自己又不会改造。。。
后来自己想办法用@pytest.mark.parametrize 直接写在请求接口上入参，没有数据分离，如果换到预发布域名，这写参数又很麻烦去改。
2）我们每个接口的都有一个加密的字段追加到请求参数和 header 中，当时写了几个接口，觉得自己一直在复制粘贴，想着有没更好的办法。
后来加上工作变动，这个框架我也就放下了。新的工作我又在想搞接口自动化，我又开始看 testhome，搜到这篇文章https://testerhome.com/topics/33016
又跟着去他提到的 github 下载别人的框架，已经搭建好了。
我从他说的砍掉了 operation 层，我把这层砍掉了。
后续的内容我还看不太懂，还有他说的【既然我们要维护这么多个 api，且这些 api 结构也都类似，那么自然也需要抽象 1 个 BaseRequest ，所有 api 都共用的能力可以放到这里来。 这个 base 层不光可以放 BaseRequest，像一些基本异常、基本响应也可以抽象出来放在这里。】没有代码，我自己也不知道怎么写。。。。
所以现在我想知道 operation 层到底该不该砍掉，还有我现在的这种每个接口都会根据参数加密追加到请求中和 header 中，还有没优化的空间。。。
好的框架是什么样的，有无分享？
当然，不管怎么样，只是做到这里有这个疑问，我会继续做下去做完。做多了遇到问题了，自己再去想办法找解决的答案，去优化。
设想下，如果基于 mitmproxy 录制接口，然后自动生成 yaml 文件，同时 yaml 里可支持参数化。如果固定用户，只需录制接口生成 yaml 文件即可。然后再加入返回结果对比验证，可以验证字段，也可以验证 schema。。。。。。。
这里可以优化成维护对应的 post、get、put、delete 的四种类型 API。至于每个接口加密，可以写个通用的加密方法，让 api 调用
1.请求体可以用解构
比如你要传入 args1 和 args2，2 个参数，用
data = {"args1":xxxx,"args2":xxxx} 这样也容易维护
def method_ex(args1,args2):
...
# 改成下面的
def method_ex(data):
...
# 这样会自动进行匹配，字典也可以维护成json，容易维护。
method_ex(**data)
# 等于把要传递的数据包含加密的，在data管理时都做了。
2.基本异常、基本响应抽象出来是框架做得事情，看抽象维度是以框架多加一层在到场景层都可以。
3.现在的这种每个接口都会根据参数加密追加到请求中和 header。可以单独写一个方法，在请求时先使用这个。
比如下面这个简单例子，如果是加密的，可以看看 1，加密一般是对请求体内容的某个字段加密，如果是加密放到包头里面,比如 token
headers = {"Authorization": f"Bearer {JWT}","token":"部分参数加密后的数据"}
def get_header(module:str,data:dict)->dict:
"""
设置包头 放入到请求库的headers字段
在配置层维护一个 {module:data}的map结构
:param module:模块名称 不同模块加密方式不一样
:param data:解构的结果 传入
:return:
"""
...
http 镞包头也是验证合法来源的，所以放到配置层里面。
懒人
回复
又认真比对了下，你这种方法跟我看到的第一个文章的类似（https://testerhome.com/topics/23441）
他的 path 和请求方式也放到 yaml 里维护，看来这种方式是最简洁了
那对比第二篇文章中提道的 github 项目（https://github.com/wintests/pytestDemo）
是把 api 和 operation 层都砍掉了。🤔️
风子
回复
https://github.com/wintests/pytestDemo 应该是跟这个比较像，因为我最开始按照这个去调整的，后面觉得调用链太长把 api 给砍掉了，operation 我觉得每个接口一个方法很重复就直接封装 post、get、put、delete 四个方法适应所有 method 方式的接口。不过在 testcase 类是一个接口一个方法，yaml 不用指定 method,因为在 testcase 的方法里是知道该接口的请求方式，直接调用 operation 封装的方法就好，至于 path 放 yaml 或者 testcase 都没问题，放 yaml 是为了完整性，因为框架写好了，最多的工作还是在写 ymal。
懒人
回复
请教下，这种 yaml 管理测试数据的方式，如果接口涉及关联呢，如：
1.新增公告 - 保存
2.公告提交 - 启动审批流
3.公告审批 - 审批通过
4.检查公告的发布状态为发布成功
我要测一个发布公告的场景，这里面涉及到 4 个步骤，多个接口协作，中间我还需要拿到新建的公告 id 去数据库关联查审核任务的 id，然后才能去审批接口使用审批通过。像这种场景请教下，yaml 文件管理测试数据的，是什么个思路？我目前的方式比较笨，太过依赖 pytest 的 fixture 固件了...
接口自动化的尽头是接口自动化平台，免费的 MeterSphere 接口测试平台你值得拥有，docker 部署简单方便，团队都能用维护成本币代码低多了
