代码统计

Ayo · 2024年03月07日 · 最后由小黑子-祖国人回复于 2024年10月26日 · 10569 次阅读

历史帖

前言

没有源码！对测试平台功能设计感兴趣或者不知道做什么功能的可以看下去，希望对你有点启发 🙏

风险跟踪

背景

在实际使用中测试中包含了大量回归任务与其他检查机制，仅接口回归任务而言目前执行的接口已经达到了 3500w+，每日场景用例执行量达 5w+，自动检测任务总运行 50w+ ，但由于各种历史包袱或者使用频次，非重要功能等原因一些检测到的风险并未及时修改而导致长时间存在，又由于未将风险关联到人，导致风险项无法流转追溯，所以需要一个风险跟踪机制将问题持久化并将负责人拉入风险处理的流程内，在有空的时候主动推进，让问题最终得到解决，避免历史风险持续叠加导致各类棘手的问题。

功能介绍

数据看板将展示所有风险并根据风险类型 - 风险来源 - 风险名称 - 负责人聚合, 在此可以审查系统近期捕获到的一切异常信息

在工作台内可以将任务单个/批量指派给他人，可以将任务单个/批量更改状态，可以单个/批量评论任务，可以记录任务各个字段的更改人 - 前后更改 diff 值 -以及持续时间

任务编排

背景

随着公司项目越来越多，而对应的测试回归用例也越来越完善，但面对客户项目上线发布的频率增高，尤其是临时定版热修的情况下，测试用例回归将会耗费大量时间，最终会消耗一定的时间在于等待回归用例的执行，为了减少这种窘况的发生，对于任务用例编排以及执行优化迫在眉睫，我们希望通过以下方式来减缓这种问题的情况：

采用更加智能多线程用例编排执行用例 —— 解决耗时大的用例被同个线程获取导致最终执行慢的问题
运行时的错误用例报告/剩余队列数展示 —— 提前暴露问题提前查看问题所在
线程阶梯下降自动重试 —— 减少并发执行带来的用例异常问题
增加多队列模式动态统计历史不可并发用例至单线程队列 —— 减少人为维护不可并发数据以及减少不可并发用例在并发下的错误影响

编排设计

基于贪心算法的线程级别的用例编排，使用历史执行数据根据线程数量动态分组执行队列，另外对于执行用例按照用例执行时间从小打大依次扔入队列，使得消耗时间越大的上用例都在最后，可以在有限时间内看到更多用例的执行情况；

开启自动重试，自动重试默认采用 2 个线程执行，而平时用的都是单线程，这样设计为了提高给到大家重试时的及时性，以及大家自己重试时的正确性；另外对于不可并发的任务，采用多线程执行后将会将第一次执行异常的用例落库，并在下次执行时动态的分配到单线程执行队列中，在多线程只任务结束后，由单线程执行；

数据同步监测

背景

目前通过 flink cdc 通过模拟 mysql slave 的方式订阅 binlog 的变更消费，来做数据同步到 starrocks，但由 flink 组件复杂且不是特别稳定，有时候会出现 taskmanager 假死，binlog 数据无序消费从而造成同步数据异常的问题，现在需要一个工具可以验证同步任务是否正常运行；
现在通过每个环境自动创建一张表，并写入此次检查的时间戳，下次执行时检查 starrocks 与 mysql 中的时间戳的差值，差值则为最小的延后时间（经测试在没有压力的时刻 mysql 修改/增加的数据写入 starrocks 将会非常快，几乎无感)

功能介绍

支持公共/自定义配置环境阈值/环境忽略等配置；支持异常推送/恢复推送/失联推送等；支持历史检查日志/延后趋势汇总/前一天的探测成功率汇总；支持屏蔽指定时间/环境的消息；支持全环境的状态总览；异常推送到指定群组

历史延迟趋势审查

消息聚合屏蔽/汇总

数据开发

背景

可视化编辑 Dinky Flink SQL，并自动关联当前业务数据库，拖拽预览/生成 FlinkSQL 并保存进 Dinky，解决 Dinky 无法关联业务库，无法直接判断表是否存在以及不同 FlinkSQL Diff 功能。

功能介绍

根据业务库查询所有表，解析 FlinkSQL 查看已存在的表，并做可视化编辑以及 diff 操作

代码统计

背景

为了统计热点服务，聚焦核心功能以及分析人员能效的一个维度；

功能介绍

部门服务下人员提交汇总聚合展示代码增加/变更量

代码提交按照人员的排序列表以及人员最近提交趋势

17 个赞

共收到 20 条回复时间点赞

li_40 #19 · 2024年03月07日

那个群还能加嘛

鑫 #17 · 2024年03月07日

发现 A 佬，拜读一下佬的文章，把历史帖贴出来太贴心啦

Ayo #16 · 2024年03月07日 Author

对

鑫回复

有帮助就好

Ayo #15 · 2024年03月07日 Author

对

li_40 回复

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

cooling #14 · 2024年03月08日

定时任务中心怎么做的

悲伤蛙 #1 · 2024年03月08日 2 个赞

这个平台除了测试业务，其他技术选型和业务比大部分被测的系统还要复杂。。。

Ayo #13 · 2024年03月08日 Author

对

悲伤蛙回复

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

Ayo #8 · 2024年03月08日 Author

对

cooling 回复

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

测试新人 #11 · 2024年03月08日

对

悲伤蛙回复

超越问题本身了哈哈哈哈，其实我觉得作者为什么不干脆跟公司提个需求，把你的平台商业化，公司多新开一个项目，然后去拉订单。你这平台建设成本都大于测试的项目了吧，看起来很像可以盈利的项目

Ayo #10 · 2024年03月08日 Author

对

测试新人回复

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

测试新人 #9 · 2024年03月08日

对

Ayo 回复

你这不是前后迭代了 4 年，成本还低呀........我倒是挺好奇是什么公司会给这么多时间你搞，从你的文章里可以看出，你应该是从来都没有功能测试过的，全职开发的概率很高。而且会者是不难，难的是给时间

Ayo #12 · 2024年03月08日 Author 1 个赞

对

测试新人回复

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