我先抛砖引玉说说自己的看法，有大佬分享麻烦踢我一脚
1.你是通过不同的用例文件执行读取不同的 sheet 表名来各自取数据吗？那每个文件除了定值（sheet 名或其他）都不该有差异，要做到复制粘贴即用
2.我觉得可以先执行一些接口获取大量必备数据存储到主配置文件中，然后后续接口需要就读取，想用自己的就自己执行然后保存到小配置文件读取
3.不同用例文件只要变的地方只有定值，可以将所有用例文件继承父文件，父文件来写执行逻辑

@ 木小白 ，非常感谢大佬！！！
上面的 1，我的文件，表头都是一样的，表里的值可能都不太一样，比如接口名，参数，预期等，这些都不一样，不能直接复制黏贴，怎么做到复制黏贴呢

上面的 2，我是写了公共的业务方法，需要的时候调用一下，然后用 setattr 存放在临时变量里面，用的时候直接拿，这一点跟你的原理很类似

上面的 3，不太懂你说的文件继承父类，可有例子供参考呢

seldom 项目看看学学

接口名，参数，预期，这些应该控制在 excel 上，文件中只能修改定值。父类的话就是子类继承父类，会拥有父类的方法，知道这个原理，在父类写好 before 和 after，子类只需要继承，就不用自己写了

浅谈下我的观点：
第一点：测试用例里应该全是用例的数据，可能某个参数一样，导致接口返回的结果不一样，这样只需维护好你的 Excel 表就好，这跟代码没有关系。除非你的框架并没有解决用例和代码分离的问题。
第二点：关于一个接口需要依赖多个接口的问题。其实我想到有两个方法，第一个方法是控制用例的执行顺序的方法，先让依赖的接口执行，保存你需要的数据，然后再执行。第二个就是写个方法，用来判断当前用例是否有依赖的接口，如果有就先执行依赖的接口，等依赖的接口执行完成，数据都拿到后，再执行当前用例。当然这种方式最好给每个用例编写好编号，以便于调用。
第三点：对于 testcase 中，如何去减少代码维护，是不是写用例之前得先分清各个接口的共性，同一类的放在同一个 testcase 中。这个应该在你的公共方法类中对不同的接口类型进行封装，比方说 JSON ，PARAMS ，DATA ，FILE ，EXPORT，NONE 等，然后在你的用例标识出来，不用的方法走不通的逻辑。

感谢大佬的不吝赐教！！！，似乎明白了父类继承的原理，目前我的代码确实有很多重复性的

感谢大佬指点！！！
第一点：我的代码是跟数据分离的，但是代码中涉及各类断言，有些接口不一样断言方式也就不一样，是不是要把断言方式也封装成公共方法？

第二点：使用执行顺序，在调试的时候是不是不太方便，我采用的是如果需要依赖，我吧依赖的接口封装成公共方法，在执行接口的用例的之前先执行 这个公共方法，拿到需要的数据，对于加个依赖标识，觉得这个主意很棒，我现在貌似是写死了，有个标识的话可能灵活一点

第三点：你这么一说，我的的用例分类貌似有问题，我的分类好像都是业务模块分类，导致 testcase 里面出现很多重复性的，大部分重复在于获取用例数据，然后发起请求，而区别在于提取数据做断言的部分，最近才对获取数据用例这块封装了公共方法，现在直接调用，是不是也要考虑吧提取数据以及断言分别封装成公共方法

seldom 项目确实没有了解过，感谢大佬的建议

命名能不能统一风格啊，看得强迫症犯了

第一点:断言的确需要封装，因为接口测试中涉及到的断言种类很多，包含，长度，大小，相等，正则匹配，以及还有数数据库断言等等。
第二点：依赖封装成公共方法，这样的话你的用例最好有个编号。然后每次执行依赖就可以直接调用该用例，并且这个用例也可以用与其他接口的调用，避免重发劳动
第三点：我觉得你的框架这块需要优化下。获取用例数据生成可执行文件这块应该是公共方法，通过你的 excel 直接生成 py 文件，你的重心应该在于用例的设计。我现在感觉你在生成这块浪费的时间比较多，有点本末倒置的感觉。建议可以去看看开源的接口测试项目，了解作者的思路可能对你有些帮助

过来人给你个建议要搞就搞 pytest，不要在 excel 上浪费时间，不要自己造轮子，去看 httprunner 源码

感谢大佬的宝贵意见，你的第二点意见很赞，我的用例有编号，但是就没有想过利用这个编号来完成依赖
第三点说到我的痛点了，开源项目可有推荐的啊

注意，本菜鸡要开始胡说八道了

是不是给用例加上一个 “用例类型” 会比较好一点，比如隶属于什么模块属于什么业务链之类的。同时用例中添加一个 “使能” 字段方便暂时排除某些用例，这样维护的时候组织用例的时候要用的时候就打开，不用的时候就关上。

我可能说不到点上，但是我感觉代码框架不一定是问题来源哈。就目前看来，似乎你的问题都能通过用例设计去解决哎。不知道我有没有表达清楚

gitee 上面有很多，你可以看看

很同意这个观点，找一个好的开源项目，然后取其精华应用到自己的项目中，比自己从头到尾造轮子收货要好很多

你这个框架分层好粗糙啊
建议你分三层，公共 API 一层，业务 API 一层，测试用例一层。
每一层都是一个独立的 python 包，这样你再加入新的产品、新的业务 API，就可以做到很好的封装和隔离。
测试数据和测试配置 conf、测试报告都归测试用例那一层。
测试用例的上一层就是测试执行器，也就是你的 run_test.py

你的测试数据如果不是成百上千，你就不要放到 excel 里面管理，直接放在普通文本里面，或者直接作为 python 的变量来储存就行了。一个 Pycharm IDE 就可以管理，非要去打开几个 Excel 占内存干什么。
另外一种变通的做法就是，你把你的接口定义的默认值放在 excel 里面 (注意这个 excel 以后都不动，除非开发增删改了接口)，然后在测试用例里面对这组默认值取相对变化的值 (自己实现一个函数)，来形成同一个接口的各种各样的测试参数。