1、接口用例直接写在代码里面，一个用例一个函数，这种能更多的使用 pytest 的功能
2、接口用例写在 yaml 或者 execl 里面，一个用例一条记录，这种需要自己写一些方法结合 pytest 处理
暂定用例设计格式文章源自玩技e族-https://www.playezu.com/190972.html
#用例(名称)标题
case_name:
#接口地址
path:
#请求方法
method:
# 备注信息
remark:
# 是否运行
is_run: True
#请求参数较多，这里就使用原始字典格式，除了提取表达式，其他的都带上引号，预防出错
data:
{"id":$.tq_data.id,"projectNo":"320SF000206004","name":$.tq_data.name}
#从接口返回结果提取哪些字段和提取表达式,比如从返回数据提取用户id和name
extract_key:
id: $.data.id
name: $.data.name
#断言表达式
assert_expression:
- 1=='1'
- cc=='dad'
- 12 in '123'
- ig in $.lpl.ig
软件测试功能文档文章源自玩技e族-https://www.playezu.com/190972.html 文章源自玩技e族-https://www.playezu.com/190972.html
未知地区 1F
pytest 官方有示例
https://www.osgeo.cn/pytest/getting-started.html#create-your-first-test个人我而言，喜欢直接写代码，能接受 yaml，其次 JSON，Excel 强烈拒绝
能把用例转化成 yaml，然后可视化还是不错的。但是我一般不会用 yaml 编写用例那你是怎么编写自动化用例的看实际场景需求和资源来定 如果参与脚本开发的人都有一定的代码能力 可以直接写代码 这样最灵活 对人员要求也要高一点
否则可以封装起来 对外只使用 excel 或 yaml 文件编辑 参与开发的人员只需要熟悉你框架开放的 api 规则就行了
存储介质常见的几种方式各有利弊 我们一般是使用 excel 编辑效率比纯文本文件高很多 https://blog.csdn.net/aaaaaaaaanjjj/article/details/122487373 我之前写过个框架，应该算是直接写代码来编写用例的。我现在打算写一个已 yaml 文件来作为用例的框架，最后可以写个 yaml 文件和 execl 文件数据转换的方法我们团队目前的实现就是用的思路 2：Python+Pytest+Allure+Request+Excel
1、只需为每个项目创建一个 Excel 文件，维护测试用例即可，无需编码；
2、实现了案例读取、执行、断言、报告聚合、消息发送、用例自动生成等功能；
interfaceEx 接口自动化测试框架
欢迎交流好的#用例(名称)标题
case_name:
#接口地址
path:
#请求方法
method:
# 备注信息
remark:
# 是否运行
is_run: True
#请求参数较多，这里就使用原始字典格式，除了提取表达式，其他的都带上引号，预防出错
data:
{“id”:$.tq_data.id,”projectNo”:”320SF000206004″,”name”:$.tq_data.name}
#从接口返回结果提取哪些字段和提取表达式,比如从返回数据提取用户id和name
extract_key:
id: $.data.id
name: $.data.name
#断言表达式
assert_expression:
– 1==’1′
– cc==’dad’
– 12 in ‘123’
– ig in $.lpl.ig
读取结果：{‘case_name’: {‘path’: None, ‘method’: None, ‘remark’: None, ‘is_run’: True, ‘data’: {‘id’: ‘$.tq_data.id’, ‘projectNo’: ‘320SF000206004’, ‘name’: ‘$.tq_data.name’}, ‘extract_key’: {‘id’: ‘$.data.id’, ‘name’: ‘$.data.name’}, ‘assert_expression’: [“1==’1′”, “cc==’dad\'”, “12 in ‘123’”, ‘ig in $.lpl.ig’]}}
我准备这样设计用例，然后对 is_run，data，extract_key，assert_expression 等字段进行单独处理，最后组合最终请求数据是用 pytest。就是比较常规的设计，接口定义层，业务逻辑层，用例层这样。每个用例要能独立运行。用例函数 (或者用例类) 尽量只与 fixture 交互，比如通过 fixture 执行通用的前提条件，通过 fixture 加载数据以及参数化，通过 fixture 获得业务逻辑层的业务实体对象，然后调用实体对象的方法。
优点是测试用例函数代码看起来很简短，阅读起来方便。缺点主要是会用到很多 fixture，而且还有多层 fixture 嵌套。不喜欢 Excel，主要因为 Excel 文件不是纯文本文件 (除非用 csv 保存)，而且不好通过 git 进行版本管理 (查看 diff)。我可能有点开源洁癖，所以不喜欢用微软的 office 软件 (捂脸)可以试下 HttpRunner，可以支持将抓包导出的 HAR 文件、Postman 转换为 pytest 格式的用例。
https://httprunner.com/blog/hrp-convert-intro/1、接口用例直接写在代码里面，一个用例一个函数，这种能更多的使用 pytest 的功能
推荐采用这种方式，详细教程可参考：
https://dongfanger.gitee.io/blog/%E6%B5%8B%E8%AF%95%E5%B7%A5%E5%85%B7/000-%E3%80%90%E6%9C%80%E6%96%B0%E3%80%91tep%E5%AE%8C%E6%95%B4%E6%95%99%E7%A8%8B%E5%B8%AE%E4%BD%A0%E7%AA%81%E7%A0%B4pytest.html
可以选择代码加 json 或 yaml ，参数少就直接放代码里面，参数多就放文件里面