问答 python+requests 接口自动化测试基于场景形式，接口管理、单接口调试、数据依赖问题如何解决？
如题，在做接口自动化的时候，一般会有多个自动化场景：比如 ：
场景 1：创建问卷
场景 2：h5 端提交问卷
测试场景：由多个不同的操作步骤组合而成
操作步骤由：多个 api 接口串行组成
接口池：系统中所有的接口
如图：
在做接口自动化测试时，想要达到以场景运行测试，我的思路是这个图中的接口池中，多个接口组成操作，多个操作组成一个场景。
我的疑问就是这个接口 api 是非常多的，而一个操作步骤由多个 api 串行时，上下文的数据是有依赖的，我每次执行测试时，并没有初始化测试数据，而是模拟真实的用户操作步骤去发起请求。
目前遇到的难点 1，比如这么多的 api，一个接口一个 py 文件去进行维护的，非常复杂和繁多，之前想过使用 excel 去管理 api 接口，感觉也不太优雅，我目前是根据 api 的 py 文件的路径来当作接口的 url 路径来进行的接口管理，感觉也不太优雅，有没有更好的方式。
此图中，login 文件的路径，来定义 login 接口的路径，如 login 接口地址：\hzx_manager\login
遇到的难点 2，目前基于场景接口自动化时，一套串行的接口执行，接口与接口之间会有数据依赖的问题，我目前的解决方式是，所有接口的数据都储存在一个公共的文件中，或者存储在一个全局变量中，这样每次执行都会生成一个很大的临时数据文件。···
遇到的难点 3，比如我目前基于场景的接口自动化，想触发单个接口进行调试就比较麻烦。
跟各位讨论一下，大佬们在做接口自动化时，如果做过场景接口自动化，是如何进行 api 的管理的，以及如何解决上下文接口之间的数据依赖，还有就是如何进行单个接口的调试
大佬都不屑回答的吗？
楼主这个问题最优解应该是引入一个数据仓库，提前生成好需要的数据。
测试用例的编写有一个很重要的原则，只做一件事 。而这件事之外的事，应该在其他时候做。
比如楼主的例子，测试问卷的前提是要创建一个问卷，这个流程如果是串行的，那么就让这个自动化用例变得臃肿了，并且在做自己想要的事（测试问卷）的时候，额外增加了一件事（创建问卷）而这个过程的不稳定会导致后续的验证都无法执行。
如果把这个流程改成预先生成一批各式各样的问卷，要测试的时候直接拿这个问卷来测，而无需实时创建，那么这个问题就解决了。同时由于有了问卷池，那么即使创建问卷的功能有问题，也不会影响测试问卷这个功能。
楼主的问题 2 也是同类型的问题，不同的场景对应的底层问题就是数据的不同（或者状态不同）。通过一个数据仓库覆盖这些场景的数据就可以解决大批量串行流程构造前置条件的问题。
至于 api 管理这个层面，我个人认为应该是把这些 api 服务化，而不是一个一个的脚本。
互相学习：
1.用例使用 yaml，用模板生成 yaml，用管理模板的方式来维护；
2.使用反射 setattr 和 getattr 处理接口依赖；
3.使用 pytest.mark 标记单个接口进行调试
可以用 yaml 文件管理用例和变量，我一套流程跑下来两万次请求，一万多个依赖变量都是用 yaml 文件管理的
无邪
回复
请问一下大佬，所有的 api 使用 yaml 文件去进行管理，会不会使得 yaml 单文件特别多，比如要定位某一个业务的接口，如何快速找到具体是哪一个文件呢
善用 mock 和 fixtrue，尽量保持单个 case 的独立性
就目前我们做的：
1、用例的管理其实用 yaml 和 xmind，我觉得都可以，看起来都会比 excel 的结构层次更好；
2、数据的依赖，看数据依赖的多少，不多的话 可以就放全局变量里，不需要使用后立即清除就行。或者使用过后就删除，下次需要时重新获取，较多的话 可以考虑变量写入文件、数据库之类的
3、基于场景的接口测试，本身一个场景就是很多接口的集合，要是想单独对一个接口进行测试，那数据依赖肯定是需要 提前准备好的