基于集群的CI微服务测试架构设计与实现

Posted 2022-12-13 hello-Will

问题矛盾：CI测试中经常遇到整个流程时间太长，需求测试结果很急。

全自动CI集群测试缩短测试时间。

old

例如100个case，假设原来CI测试需要12小时（一台机器把所有的case跑一遍）

new

假设又N个机器，这里为了说明具体点，我们举例三个机器
TA, TB,TC
在三台机器都能连接的server上建立case 池，静态方式case.json状态文件，动态方式起个server服务与测试端通信, 文件解释
1 : 表示有效可以被选中case还没有机器选中去跑，优先分配
0：已经有机器选中，1的分配完才会被分配。
2：case结果已反馈给server， 不能再分配。

# cat case.json

    "C111":2，
    "C222":1，
    "C333":1，
    "C444":1，
    "C555":0，
    "C666":0，

1：测试架构

2：case 分配算法（负载均衡算法）

这里主要是负责负载均衡，在test 代码测试端，用户的测试环境一般都有个可用机器最大值，例如这里我们设置为unit_number :10，根据用户场景修改
举例：
TA：机器测试的时候首先分配 allcase/10
TB：机器测试的时候首先分配 allcase/10
TC：机器测试的时候首先分配 allcase/10
当第一轮跑完以后再次按照上面逻辑进分配，若1的分配完了，选值为0的case，等所有case的标志为2，结束。
可以根据具体测试场景，进行算法的调整。例如，按照历史时间平均分配case，按照分类测试分配case，可以预先编辑一些分配规则，用户根据需求进行选择分配算法。

3：报告生成

由上面架构图，我们可以看到每个测试客户端都会与报告服务进行交互，当每个机器跑完当前分配的case后都会发送给report service，添加gui,用户可以实时看到case状态，当所有case跑完后，生成统一的报告。

优点
1：大大缩短CI / patch的验证时间。
2：不同平台的机器可以汇总在一个报告里面对比分析
3：平台的cover度更高，减弱平台的影响
4：灵活配置，可单可多
5: 可以动态添加/删除测试case

缺点：
1：如果某个平台有问题，影响结果分析。
2：增加了一个服务，需要确保服务的正常运行

设计草稿，如有建议，欢迎提出，共同进步。