大佬啥时候开源

等待开源

后端的用例组织和运行 直接用 for 循环吗？

等一手开源

楼楼啥时候开源

大佬，准备好开源了吗？

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

没有弄过数据库设计，像这样子弄可以不？

伸手党的我请问什么时候开源~

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

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

cy

感觉接口平台不实用

什么时候能开源呀？学习学习

哥 整理的如何了啊 指望着靠你这个涨工资了

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

2 个月了，继续等待开源

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

哥啥时候开源啊 我现在 django 和 vue 也学的 7788 了 但是自己写框架没思路啊 自己也不知道怎么设计 ya 图 做数据处理
还有测试报告我想集成 allure 可惜能力有限

大佬开源吗？跪求开源~自己设计毫无思路

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

催

大佬，定时任务怎么实现的？为什么不用 crontab 格式呢？感觉更实用一些

排队等开源

等一手开源

赞赞赞

哈哈哈，似曾相识啊，点个赞~

没，INSTALLED_APPS 如下

请问楼主，Framework 中有用到 Django Rest 吗？

感谢支持，一起加油

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

我去体验了下，理性上来讲，基本功能是有了，只是比较粗糙；我最抗拒的一点是用例要一条条自己填数据进去，这个太浪费时间了，如果要在项目中使用这个平台，我想我是拒绝的

支持一下！！！！！！！！

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

插眼，期待开源

落地效果咋样呢？

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

另外还要断言还需要考虑数据类型不一致的场景，所以我这边做的是都转为字符串形式，并且比较的断言为 utf-8 的字符集，防止中间因为 json 解析出现编码问题导致断言出错。
所以考虑的场景是：不同系统的响应给的编码，还有数据类型是需要考虑的，因为==判断符是判断值相等，如果一个是 int 数据类型，一个写在数据库里面的是字符串（数据库存储断言值），会出现断言出错。

你那个断言方式的话比较损耗性能，一个是字符串判断本身比较损耗性能，第二个是进入到最下面的断言的时候，需要走上面的判断，都走一遍。（另外第三个断言写错了 “<”）

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

能具体些的写一下用到了哪些框架吗，比如请求接口用的什么，希望大佬能开源

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

我是这么做的，都去除空格，转成 utf8 字符串，用 jsonpath 的语法匹配断言

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

确实，你的校验到当前接口的返回就为止了，而我们可能还会调用其他接口去验证当前接口的结果，做一个业务闭环。其实最主要的问题还是数据驱动的引入，不能一个接口只写一个断言去处理当前接口所有的测试场景，得一种场景写一个断言。如果中途能引入一些自定义函数或支持插入自定义步骤，比如随机数，字典、列表等数据二次处理再组装就更好了。

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

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

大赞一个，业务很类似。似乎当业务用例里面涉及多个接口请求去取前置数据时还是有一定的局限性，比如我要从其他接口取一组数据用于另一个接口测试，但是有可能我取不到，我就会去做新建数据操作给自己造数据测试，这时感觉局限性就出来了不能做判断走分支控制测试流程？然后断言部分，我们的业务可能会涉及根据请求的入参类型，去断言得到具有特征的 response(或者其中某个字段)，不单单是断言数据，还有可能断言数据逻辑，似乎看起来也不能很好支持？有过这方便的拓展想法么？

你这里说的是公共前置用例吗， 如果我们每个用例 断言时， 都会调用另一个接口来验证， 比如 注册接口， 断言注册接口返回的值后，我们会调用登录接口来辅助验证 是否是注册成功 ， 这种情况 支持吗，

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

大佬，业务用例里， 接口之间的参数传递是如何做的呢

很实用，期待大佬开源

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

为什么总是无止境的搬来搬去。 是为了绩效嘛、麻烦多做点创新的东西。low!!!!!!!!!!!!!!!!!

前辈

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

感谢回复。数据驱动确实有必要，还有类似的就是自定义函数功能，比如类似于注册这种功能，自己定义一个函数功能，每次执行用例时随机生成一个新的手机号取注册。swagger 文档导入这个功能并不难，现在用 swagger 的公司挺多的，后端给接口都是直接给 swagger，做个一键导入就很方便，可以了解下。那个模块功能我觉得把它独立到菜单栏和’ 项目管理 ‘、’ 接口管理 ‘、’ 用例管理 ‘并列会更方便，然后在’ 接口管理 ‘、’ 用例管理 ‘页面上的搜索做个过滤筛选，加两个下拉选框’ 所属项目 ‘、’ 所属模块 ‘，这样会更方便些。

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

之前也用过一些接口平台我觉得有两点感觉可以增加一下：
1.上传接口文档后，自动生成接口，如果一个个填太费时间了；
2.对非空参数可以自动生成非空检查的用例，对 Int 参数生成输入 string 的用例..

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

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

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

期待开源。但看截图有些晕。有个疑问：添加用例里的多接口模式是怎么样的？有 2 种场景需要用到多接口，第一种是同个接口不同的请求参数，比如测试登录的接口，需要测试已注册、未注册账号，正确密码、错误密码等情况，但这些其实都可以归为同一条用例，也就是我在一条登录的用例里多次请求登录的接口，但传不同的参数；第二种是前后接口依赖，比如需要先请求第一个接口拿到返回值传给第二个接口，看到介绍好像有提取为全局变量，但很多时候提取的返回值的使用频率很低，只在该用例里用的到，支不支持在同个用例里的多个接口中把前面接口的返回值提取出来传给后面的接口？最后导入接口希望可以加入导入 swagger 的功能

感谢肯定，一步一步来

也很高兴给你有所帮助

很赞啊，希望早点开源

哈哈 我来瞻仰下 猜猜我是谁

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

vue 我也是写这个项目的时候开始学习，大佬就算不上了，就自己够用 ，感谢你的肯定 ，vue 我也在持续学习。

点个赞，目前还在看 vue 方面的内容，等待开源向大佬学习一波。

看起来很不错啊，期待后续分享

这两个都没有用，这两个用了，我感觉限制性比较大，就自己写了断言的逻辑 。很多设计确实费脑子。

嗯共勉，我得好好整理整理

请问下用的 unittest 还是 pytest？
期待大佬开源，自己写毫无设计思路，太菜了

老哥 你现在搞的就是我现在学习的方向啊 我就是在学 vue 加 django 的 希望以后能够开源

感谢你的肯定 ，刚开始写前端也是坑坑洼洼

哈哈哈，不谋而合，源于工作

目前代码在整理中，要整理的东西有点多，过一段时间我再考虑开源吧

都是基于平时的工作场景进行的设计，这说明我们的工作场景差不多

目前代码都在整理中，过一段时间，我再考虑开源吧

还以为开源了呢

还以为开源了呢

和我之前的想法非常一致

很贴近日常使用场景，赞

代码可以看下吗