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

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

我是现写的，我觉得初学者用 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: 如果公司不需要建设这种基建平台，连一个人都不愿意投入的话那真的就没的讨论了 ）

其实建设成本很低的，设计开发运维目前都只是一个人，只不过个人兴趣使然会在空的时候经常维护，投产范围的话实习生/测试/前端/开发/产品都在用。 商业化前 CTO 也有想过，但可能需要更多时间人力投入了，就先搁置。 这玩意其实会者不难，有真正落地的项目的话其实维护到最后也都会成这样全方位的内部建设平台的，更多情况下常说的接口测试/ui 测试也只是测试的一小方面，还有更多的功能面需要更完善的功能去覆盖。

用了 Master -Slave 分布式多节点模式 APScheduler 作为调度器分发任务 Celery Work 作为执行者获取任务执行回传

落地迭代时间略长 现在的内部逻辑属实有点复杂...

https://testerhome.com/topics/37824 可以参考我这个中的代码扫描就是发现此类问题

可以的呀 不嫌麻烦可以加 AYO-YO-O 我拉你进去

有帮助就好

可以参考一下我之前发的，都是工作上实际落地使用的。

王总你都快把我的平台照着画完了都