我是现写的，我觉得初学者用 element/ antd 这种比高度封装的 admin template 上手更快。

宝 暂时没有呢

可以直接用 BlockingScheduler

在我们公司只要你做的事情对公司有价值，额外抽调一些开发人力去偶尔支持一下也是可以的，一般的测试平台不算是一个非常复杂的系统可能一小会就可以解决。如果公司连这点人力都不肯出那说明这种平台在咱们公司也没啥存在的必要。

我个人是觉得脚本都写的 6 的，无非是工程化差了点，所用的一些库有些区别，其他都是大差不差的，在现有整体平台搭建起来的情况下 改改 bug 应该没有什么问题。

另外我觉得对于个人而言，如果一直抱着使用者这种思路去工作，没有对工具的好奇心，可能最终也只会用工具了。

我认为不管你现在用纯代码也好，用配置文件也好，如果一直可以坚持用下去，那么最终会成为一个平台，放在业务开发上来说，很多细分领域的低代码平台已然很成熟, 大到金蝶云低代码， 小到那些拖拉拽的小应用。而对于测试层面来讲其实底层组件非常适合固化，例如一个步骤执行大概可以分为： 前置动作 - 步骤执行 - 后置动作， 抽象出中间的步骤，具体实现拿出来例如 http/mqtt/ws/modbus 等等。固化后的组装，数据传递则组成了一个场景用例，我认为这是一个非常适合平台化的场景，至于好用不好用，这些都是设计问题都是可以迭代之后改的，没有一个工具从出生就是非常好用的。

另外一个方面接口测试等自动化测试其实在现实的开发测试场景中占的比重并不是特别大，且如果作为一个能力孤岛也无法发挥出其重要作用，这就需要有效能度量，三方对接，采集监控，覆盖率采集，任务调度等等互相依托才可以发挥最大的作用。

举一个实际的例子：
一个公司使用 pytest allure 做自动化测试，那么他要解决以下问题：

1. 使用者人人都熟练 git 的基本操作（即使封装成配置文件执行，也避免不了提交代码）
2. 使用者人人都本地部署一套环境，且大部分的人需要会写 python（暂时不考虑代码质量）
3. 假设使用 jenkins 做 ci，那么生成的 allure 报告需要支持一键重试。 3.1 当你写的用例多切覆盖到业务组比较多的时间，大家仅仅会重试自己的用例，也要支持动态筛选。 3.2 当你的脚本有误的时候，你需要重新提交代码，并且支持手动触发异常用例重试。
4. 如果你的用例很多，你要支持并发执行用例且要支持 allure 报告合并。
5. 你需要将结果落盘，分析数据/趋势。

可以发现这几个基础的问题有很多都涉及到持久化数据，以及代码能力。持久化数据之后最简单的写个页面展示， 代码能力方面，由于自动化测试的代码一直都在变，谁能保证自动化代码没有异常，而平台核心驱动代码可以一直不变，变得是用例配置，可以理解为用用例的配置去测试了平台核心驱动的代码，当用例越多那么平台就越可靠，不会出现使用产品来测试脚本的尴尬情况。

且当然以上这些基本的问题仅出于仅仅是测试这个角色在用的情况下，当一个用例作为监控/待办工具下，其他的角色（产品经理/研发）都会遇到更多的问题， 综上不管怎么样 拥有一个大家可以访问的页面是肯定的事情，至于平不平台，就要看这个东西大家的依赖程度，依赖越深，迭代越多，你这页面越复杂，慢慢也就成了一个平台。

ps: 附上我司的自动化测试

复写原来的执行 sql 的方法，做一个拦截即可。

像是 LLM Agent 这种开发配置平台，万变不离其宗其实就是个 Flow， 至于是 DAG/LIST 其实也只是一个展现交互方式。 另外我个人觉得这个应该做在低代码平台上面，因为对于低代码平台来讲本身具有规则引擎，并且 API/DB 等这种仅仅是获取资源的一种方式，他们并不该做为平台主体，作为依赖项更贴切一点。

在我目前的思想理解上，现在市面上的 agent 开发平台例如 langflow/dify/coze/chatdb 无非是原本 flow 中一些特殊节点（llm 相关的逻辑推理/知识嵌入/rerank），例如与测试相关的流程类的用例中，因为原本就包含一些控制器步骤（if/for/while）只要步骤增加一些 llm 相关的处理节点，外部套入 sse/ws 接口，就可以对外暴露出一个自己配置的 ai 助手。

正经群 话少也不让说与技术无关的事情 看到会提醒

加我 AYO-YO-O