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

问题矛盾: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:增加了一个服务,需要确保服务的正常运行

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

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值