历史帖

前言

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

风险跟踪

背景

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

功能介绍

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

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

任务编排

背景

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

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

编排设计

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

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

数据同步监测

背景

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