可以的，分层明确就可以，数据库设计的话，也可以写到哪个模块再写，根据每个模块的所需要的业务设计就可以。

感谢你的耐心阅读 日志本身就有；钉钉告警，我 8 月初的时候在分支上写了，没合到主干。就是计划中不区分钉钉机器人还是企业微信机器人，统一一个 webhook 链接就可以。

这种是根据工作的实际应用环境设计，如果你当前的工作环境，对接口自动化需求不是很大，那就是框架层面的设计就可以，实现脚本式的维护就可以；当量大的时候，平台的作用在一个团队中就会发挥优势。结合自己的工作环境即可。

allure 这个报告你要集成得话，那你需要用 pytest 测试框架了，我感觉做成平台局限性会很大，不过你可以试试

感谢发现问题，你描述的这个问题，我试了很多遍，都能正常添加，倒是出现了一个网络错误，不知道你是否也是这个问题，导致没法添加，非必现，代码逻辑应该没有问题，只是一个添加。这块没有啥逻辑

实用这个根据你得真实环境来的，像我在得团队人数不多，怎么简单怎么来，怎么开发落地快怎么来；当时看了几个定时任务框架，我觉得实在搭建太麻烦了，给后续得同学，学习成本也高，不符合我当前得环境；所以就自己写了专门得定时任务，项目启动得时候这个 time 服务（我把这叫 time 服务）也会随着项目启动，时间自己设置多久检查一次，我设置了 30 秒检查一次；

没，INSTALLED_APPS 如下

感谢支持，一起加油

感谢体验，能否讲一下使用过程中你感觉粗糙得点，罗列一下，我这边可以看一下优化，每个人都有自己不同的操作习惯；
若这个用例只有一个接口，我可以弄数据驱动的方式，这样的话还可以增加导入功能；用例一个个填进去，这个是因为考虑到业务用例复杂性，多接口多操作，都是动态取值得；
用例不太好能做导入操作，不过也有用例复制功能；

这个问题，让我有种自卖自夸的感觉 ，你可以好好自己感受下，哈哈

感谢指正，已修复上线，我这边设计是这样的，只有断言通过，我才会把服务端返回的结果保存，所以比较的是实时的，而不是取保存后的结果去比较；
1、性能这一块，实际使用中，感觉不大，原因 1 可能数据量没达到一定的量，2 单线程跑用例（这一步主要防止数据污染），
2、[进入到最下面的断言的时候，需要走上面的判断，都走一遍] 这个不就是把你需要断言的字段进行判断吗
3、数据类型你是担心服务端在我这边反序列化类型错误是吗，这一点我在封装请求服务端的这一层，加了一层，就是防止服务端的数据不规范，只要是规范的，就能反序列化，才有接下来的比较；"=="这一点我比较的就是两个值是否相等，预期值会转换成前端填写的类型，两个类型不一致也是断言失败的，这一步前端填写的原因，而不是往实际结果类型转的原因，我是考虑到有的场景就是想要他类型不相等。

框架就是标题写道的两个前后端框架，你想问我 python 用了哪些库是吧

我这边的断言一部分逻辑是预期值需要填写类型，后端这部分逻辑如下

接口 A；接口 B;接口 C
那我可以理解为你的意思就在接口 A 的断言部分某 b 字段运行了接口 B 当预期，某 c 字段运行了接口 C 当预期，然后填充了这个预期值；如果你在断言里面加一个接口，是不是也要在那个接口中加断言，这样子的逻辑会显得复杂，前端也不好规划，不易呈现；换个思路，就是多加了一个或者多个接口其实也可以达到闭环的效果，本质是运行接口。
随机数这种自定义函数，需求量不大的话，可以在接口的某个字段选择一下这个类型，后端处理这个类型逻辑就好了。

感谢你的肯定 ， 在一个用例中，每一个步骤的前置用例（我这里的前置用例必须是一个单接口的用例，因为如果一个用例里面套了前置，多起来，我没法溯源按照顺序执行，有尝试过树，但是太复杂了），只要填写了，我都会运行，可以拿到你想要的结果值，通过【用例 id】去取，这里的局限性你方便举个栗子吗，你大致意思我能明白，但是实际栗子我更能准确回答；断言，我明白你说的意思，一般数据逻辑可以通过其他场景去验证，比如我下完单了，可以在收货那边查看是否下单成功这个逻辑；我这里设计的时候，考虑的是对单个接口的结果断言，我有想过接口返回值和数据库 sql 语句查的值做对比，拓展就是不好把控前端的显示（内容太多，显示设计真的不好看 ），后端加个逻辑是没有问题。

首先断言是针对单个接口执行结果的断言，如你所举例的，注册流程，只要你在一个用例中在增加一个登录接口步骤，就可以验证是否注册成功。我支持用例 id 和接口 id，也就是说公共用例执行结果我也会进行保存，只要填写上对应的 id 就可以取到这个结果。

把每个接口产生的结果保存好，通过接口 id 去取值，$ 用来标识字段，通过这个字段找到对应接口的结果字段

你好，不知道你处于什么而说的这些话，这些东西做的过程中都是自己亲自设计，很多细节都是都是自己使用时改良，花了很多心血和不计其数的熬夜，没有理由你上来就否定一个人努力的过程，不知道你处于什么目的；抱着学习的心情我欢迎，抱着恶语的态度，我也祝你生活愉快。

数据驱动，我在设计这个平台的初始的时候，就考虑上，只不过一直没有好好设计；自定义函数，如果需求量少的话，可以配合请求参数的类型用；swagger 这个主要我的工作环境，我接手的时候没有规范的文档，所以也没有 swagger 导入的需求，导入规则匹配上应该不难；接口管理、用例管理，侧标栏有个全部项目，展开其实就是项目和模块，可以通过这个筛选。

谢谢你的建议
1、关于第一点，接口一个一个添加麻烦，这一点我有涉及到，就是有一个接口批量导入的功能
2、关于第二点，不是很明白；非空参数这一点，就拿我工作环境来说，其实大多数在开发的时候，接口文档定义不明确，很多时候依赖抓包去看字段，所以我这里在添加接口的功能中没有添加非空参数的一个判断。

谢谢 ，这个月因为一些事情，需要处理尘埃落定后，才有心思整理

第一个场景（测试登录）：同一个接口，不同的参数，一个用例中可以有多个步骤（步骤即为一个接口），假设你的登录只调用一个接口，每个步骤填写不同参数即可组成一个用例就好，但是我觉得这个方式虽然可以实现，但还不太好，我有考虑加一个数据驱动的模块，然而实际场景一个 app 登录业务却不止掉了一个接口（有是否注册，请求验证码，登录等），所以针对不同参数话的话，目前只能是一个接口，多接口不同参数话，太复杂了设计起来；

第二个场景，这个我是支持的，无论你是哪个接口，只要在这个接口在同一个用例中，我都可以取到值，比如第 4 个步骤接口 body 中 bookId，想要第 1 个步骤接口的返回值的中的同字段的值，写法就是第一输入框就是 bookId，第二个输入框填 $bookId,选择这个字段的类型（这里假设 int），勾选取值框，选择接口 ID，填写第 1 个步骤接口的接口 ID，选择下标（因为可能第 1 个接口步骤产生的取到 bookId 有多个结果，我这里结果都是 List 的类型，所以通过下标取对应的 bookId）
第三个点：导入 swagger，目前我们公司没有这个场景，我可能不太会开发这个。
最后，也感谢你看完后提出的疑问。

感谢肯定，一步一步来

也很高兴给你有所帮助

感谢你的肯定 ，我得好好花时间整理