我看了一下代码 当时用了https://gitcode.com/gh_mirrors/eas/easy-flow 把里面的代码抽出来当成项目模块维护了，代码很少，封装也不复杂，适合集成使用。

可以试试 Cursor 编程/学习辅助是个不错的选择哇

Cursor 提供隐私模式，且在官方文档中指出 嵌入向量和元数据（如哈希值、文件名）可能会存储，明文代码片段会在计算后销毁。

总的来说在隐私模式下，Cursor 仍需要处理你的代码，但会通过加密和临时存储等方式保护你的代码隐私，确保你的代码不会被永久保存或用于训练模型。

既然是 py 系的 支持一下前后置执行 py 脚本 就有可能兼容 sosotest（曾经入职迁移过 1500+ sosotest 场景用例）

还有的 AYO-YO-O 加我 我拉你进群交流

可以理解为数据工厂内部包装了一种造数方式其中一种是自动化脚本，作为外层包装，只需要外置一个大家通俗易懂的表单，内部引用自动化脚本，屏蔽内部逻辑，简化使用规则。

自动化脚本内部逻辑略显复杂，而造数的人并不关心内部构造，所以尽量屏蔽这些展示。

屏蔽掉内部逻辑，对外展示就是一个表单 + 一个按钮

关联关系也很简单，几个自动化脚本 + 一个拖拉拽简单表单，表单的 key 为变量，运行时注入即可。

多进程下 ws 连接的 app 实例，与你其他请求连接的 app 实例不是一个，但你都是在内存里存储的连接，而恰好进程资源是不共享的，你可以通过日志打印进程号验证这一点，多进程下你必须通过一个中间件共享资源。

哈哈哈如果你在浙江有婚假 可以从 1.26 休息到 2.19

可以看我历史的帖子 希望方向 对你有帮助

留一两个人做测试技术方面，其他打散分到横向部门去。后续技术方面价值不高的话，也都到横向部门吧。

我是现写的，我觉得初学者用 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

求职软件上看一下高等级的职位要求。

主动去监测变化不如回调通知来的便捷, 例如加 git 仓库提交相关代码变更的事件回调亦或者 pipeline 中部署相关的事件触发回调。

你好，18 年毕业现在应该是六年不到一点的经验吧。 前后端写 CRUD 一俩个月就可以了（科班的）， 主要是看你的兴趣点有没有在这上面，其他设计的时间就比较需要漫长的积累了。

真的喜欢可以先看看 CICD 团队每天都干啥 觉得自己可以胜任不 可以的话内部调岗也不是不可以呀

我可能没有讲清楚，让你可能有点误解。
第一点：工作内容，我的工作除了这个平台我也有参与运维平台/前端建设只不过这些木有分享，另外也有一些资源协调/外包调研的工作项，持续迭代来说一家企业在每个阶段的着重点的也是不一样的，只要是真实落地项目一定随着公司发展而持续并进的，其实你可以通过我发的时间线都可以感知企业发展的过程，其次建设效率上来说这篇文章发的内容开发时间也不过一个多月，时间人力也真是不多的。
第二点： 我觉得领导给不给你时间是取决于你有没有提前展示出你在同等时间内在其他方面产出的价值体现，就像我不可能让一个刚学前后端的人，甚至框架设计也不太明白的人让她 all in 平台建设一样。我的看法是在业余时间丰富自己（我一开始也是这样），做一些超出工作之外的东西，厚积而薄发，起码在领导层面你是一个上进的人。（ps: 如果公司不需要建设这种基建平台，连一个人都不愿意投入的话那真的就没的讨论了 ）