看到 runnergo 就知道事情不简单

这个是当初为了解决跨越的问题，临时加了个/api/路径，你可以在前端配置文件里面，注释掉那断配置，然后重新打包，再放到后端是 static 目录下

看路径多了个 api，前端的配置文件里面去改一下

A 佬太牛了

就说爱不爱吧

哈哈，感谢认可，推动整个 UI 自动化进步，还是夸大了

这个有考虑到的
1.关于取值：不管从 response 还是 response-headers 取都一样，都属于接口的内容，都是 json，要从 params、data 里面取值，扩展一下取值范围就行，框架是支持扩展的
2.关于随机数据：里面是有写一些随机方法，用的 faker 库，调用方法：{function.arg}，方法是可以自己写的，包括前置数据处理也可以写好方法来调用

●后端
○https://gitee.com/myjiee/fast-api_auto_test
○https://github.com/My-Jie/FastApi_auto_test
●前端
○https://gitee.com/myjiee/auto_test_web
○https://github.com/My-Jie/auto_test_web

使用的 aiohttp，没用用第三方工具

个人觉得：录制，是当前测试用例快速成型的必备方法之一。
最近流行的 playwright 就是基于录制，生成 ui 测试脚本。selenium4 好像也支持录制（未了解过
那么，api 用例也是可基于录制，来输出用例。这是一个好的开始，因为你在考虑怎么降低测试用例的编写难度了，编写测试用例复杂度以前大多数人都没注意到这个。1 个小时的编写，和 10 分钟的编写是区别很大的

然后对于 1 楼说的使用场景，其实这与 “录制 “这个动作没太大的直接关系，录制只是快速获取 api 的方式。至于如何灵活，需要你的编码能力和设计，是可以解决的。

录制的 response 完全可以利用起来的，这对上下级数据关联有极大的帮助，做得好可以全自动关联，所以有了下面的建议：
取消变量的设定，用接口用例序号去做上下级数据关联

我为什么知道，因为我就是这样做的，只不过我用的 charles 录制，再解析，落的是数据库而不是 yaml

至于第 6 点，不要质疑自己，如果你觉得它给你带来了不一样的便捷，自己都用得舒服，那就是值得的。反之亦然
如果想交流，可以看我的文章

二次元是第一生产力 (●ˇ∀ˇ●)

有解决方案，非原创
在项目目录中 run_pytest.py 文件，就是专门运行和处理 allure 报告的，包括 history

谢谢提醒和建议
数据处理，后置脚本等的加入雀食可以思考下怎么融入进去
但参数提取和替换的机制并不会去改变
可以说没有这个机制就没有这个平台
我宁愿让程序的复杂度提高，也不想让自己写用例的操作复杂
^{_^} 这是我必需坚持的初衷

嗯呐，这个核心机制，解决了绝大部分编写用例的烦劳
在这个基础上，我再去做接口参数变更、接口顺序变化、等功能，去辅助完善录制来的用例的缺点

我这个是倾向于长业务流程测试，比如一个业务场景 100 个接口，就能很快速的输出一条可用的自动化用例

这个平台做接口测试的核心机制

以一个测试场景来说：为每一个 api 生成一个 number
我们都知道，业务接口用例一般都是按顺序执行的（至少在运行用例时，它是有顺序的）
那么接口上下级数据的关联与替换，就全由接口的 number 去关联：无需去思考参数的提取与变量的命名、参数的引用
这里完全没有

*表达式：{{14.$.result.roles.0.id}} *
在上面这个表达式中，14 就是指：去第 14 个接口取值，怎么取？$ 后的 jsonpath 表达式
这个表达式就是自动生成的，无需抠破脑袋的去找

我的方式是：
后端：写一个专门查用例进度的接口，数据存在一个全局 dict 里面（每次用例执行前，会存入用例执行的相关数据：api 总数、成功 api 数，失败 api 数，执行一个 api 跟新一次全局 dict 值）
前端：进入用例列表就开始轮询 5 秒一次，然后通过计算百分比去展示进度条

欢迎大家提 issue，我会认真考虑采纳
这个平台的功能比较单一，主要是解决了一些编写效率，让写起来更顺滑，不去为软件使用难易度困扰
计划是持续更新本项目，还有一些小功能未完成
个人对 python 相对熟悉些，vue3 也是边学边写，也只是能照着使用的程度
会慢慢的完善主要功能

感谢建议，已记录上了
欢迎提 issue

什么玩意儿。。。