如何组织一场JAVA技能大练兵

近期,公司为了锻炼开发人员技能,举办了一场涵盖多个技术线的技能大练兵,我有幸受邀负责java技术方向的出题和评审工作。下面从以下几个方面回顾下整个过程:

  • 题目设计
  • 程序要求
  • 测试方法

题目设计

题目设计主要考虑以下几点:

  • 技术演进需求:在公司系统云迁移的战略背景下,我们的应用即将从原来传统的虚拟机部署向PAAS云环境进行大规模迁移,需要开发人员掌握云环境的开发技能,应用开发框架需要从原来的SpringMVC+dubbo升级为SpringCloud服务治理框架。

  • 新老员工兼顾:目前公司的开发人员构成中,入职一两年的新员工超过一半,题目设计需要考虑到新员工的技能水平,不宜难度过大,否则会打消新员工参与的积极性。同时,还需要能体现正真的技术实力,不能因为题目过于简单而使得分数拉不开差距。因此,题目设计要使大家都能完成基本功能,同时拿高分的难度较大。

  • 解决生产难题:大练兵的初衷就是锻炼开发人员技术实力,提升企业级应用的开发技能,更好的完成日常任务,最终要解决生产难题,保障线上系统稳定。类似力扣网上的算法题,不适合作为此次大练兵的题目。

基于以上几点考虑,最终题目设计如下:

完成一个交易系统:
产品子系统(product)、订单子系统(order)、积分经验子系统(experience),3个子系统完成分布式部署和调用。
业务场景:
一笔交易过程中,产品子系统要扣减库存,订单子系统要新增订单,积分子系统要有相应的积分增加。积分规则为每消费1元增加1积分。

功能要求:

完成5只接口:下单、查询库存、查询订单、查询积分、个人交易信息概览

题目意在考察大家在完成基本功能的同时,如何保证数据的一致性。

程序要求

根据前期统计的报名意向来看,预计会有50人左右提交比赛交付物。这么多交付物如果要依靠线下演示评审打分的话,周期很长,而且需要人工部署调试,带来巨大的工作量。因此,必须使用自动化的方式进行打分。同时为了控制程序实现范围,防止开发人员无限蔓延开发需求,增加过多考察范围之外的扩展,因此对程序做了以下限制:

  • 中间件限制:由于本次大练兵意在为后续的云迁移做技术储备,因此中间件的选型必须控制在云上中间件的范围内,因此要求使用SpringCloud+consul的服务治理框架、Nginx软负载等中间件,不能使用Apache、Dubbo等云上不用的中间件。

  • 数据格式:题目提供3个子系统中核心的数据库表结构,例如产品信息表、订单信息表、用户经验表等。同时给出5个接口的上送和返回字段,所有人必须按照此格式对前提供服务。

  • 组包格式:由于决定要实现自动化的打分程序,就必须要统一组包要求,包括压缩包的目录层级结构、sql脚本格式、nginx配置文件、start和stop脚本等。题目要求必须实现3个模块(product、order、experience),同时提供了一个可选的其它模块(other),参赛者可根据需要自己实现,如网关、聚合服务等功能都可以放在other模块实现。other模块组包要求同其它3个模块一致。

本次题目主要的考察难点是如何保证数据的一致性。但是由于测试环境是同网段的机器,内网测试环境非常稳定,在正常的程序运行过程中,很难发生数据不一致的情况。如何产生使数据可能不一致的事件,是本次出题的重点。

因此除了以上几个限制,本次大练兵还引入了一个大杀器:chaos-monkey。

chaos-monkey:是由netflix开源的一款软件,它能在生产系统中随机产生异常事件,包括超时、程序异常、宕机等。chaos-monkey的想法源自于“混沌工程”。

混沌工程,是一门对系统进行实验的学科,旨在了解系统对应生产环境各种混乱状况的能力,建立对系统的信心。通过开展混沌工程方面的实验,可以测试出系统是否存在缺陷,从而了解系统在混乱的生产条件下如何表现。

chaos-monkey的原则,避免大多数失效的主要方式就是经常失效。通过经常在生产环境制造故障,以保证生产环境的弹性。

本次比赛提供了chaos-monkey的jar包和配置,要求参赛者必须引入,以模拟超时或者异常,从而引发数据不一致,测试程序的健壮性。

测试方法

测试主要分为两步骤:自动部署和自动测试。

服务拓扑图如下:

如何组织一场JAVA技能大练兵

自动部署

所有选手的交付物都提交到统一的ftp目录,因此从ftp中遍历文件并触发部署即可。

流水线步骤如下:

for(遍历ftp上的包)
    清除redis缓存
    执行题目提供的sql建表语句,初始化数据库
    从FTP获取压缩包,并解压
    If(有nginx配置文件)
	替换nginx配置文件,并重载
    else
	分发默认的nginx配置文件,并重载
    执行铺底数据脚本
    For(遍历服务个数)
	按规则将各个服务压缩包分发至各服务节点
	if(存在额外的init.sql)   
            执行init.sql
	执行服务的启动脚本start.sh
    运行测试脚本,收集测试结果,计算分数,并输出到CSV文件
    停止各服务

通常情况下,自动部署使用Jenkins实现。但是Jenkins不支持循环遍历,一个job只能完成一个参赛者的部署和测试。如果每个参赛者一个job,不能保证每个job配置的正确性,并且由于只有一套评审环境,每个人一个job的话,不能保证job的串行执行,多个job同时执行会相互影响。因此决定自己编写部署脚本,仅在部署完成后,需要测试时触发测试job,由测试job完成测试和打分。部署脚本监听测试job的状态,测试完成后,再开始执行下个参赛者的部署流程。

自动化测试

公司本来就具备完善的Robot Framework自动化测试基础设施,本次测试直接使用即可。由于部署程序已经在程序启动前完成了数据库和缓存的初始化,因此测试程序仅需读取测试数据并向Nginx发起调用即可。

由于要测试程序异常时,数据的一致性,因此要在测试开始之前开启chaos-monkey,在执行写入数据的逻辑后(即下单接口),关闭chaos-monkey,再开始查询,通过查询各个接口的数据并于写入的数据相比对,验证数据的一致性,并打分,步骤如下:

1.开启各服务的chaos-monkey功能;

2.执行写数据的测试脚本,即调用数百次下单接口;

3.关闭各服务的chaos-monkey功能;

4.执行单个数据查询接口,验证每个接口的可用性,并记录分数;

5.执行组合验证逻辑,验证多个服务的数据一致性,并记录分数。

每个参赛者的测试执行完成后,要将计算的分数写入汇总到csv文件中。拿到最终的csv文件后,即可利用excel实现按照成绩排序。

思考

通过本次大练兵,有以下几点思考:

  • 工具建设要持续投入:工具建设可使用最小的成本,获取最大的收益。此次练兵,开发部署流水线和自动化测试脚本各投入1人,仅在2周内使用业余时间就完成了开发和测试,比人工部署、演示、测试的成本要低得多。同时工具可重复执行,每次修改完后自动触发。日常的开发和测试过程应尽可能多的使用工具去做回归测试,避免人为疏忽引起的分析遗漏而没回归覆盖。
  • 环境问题不容忽视:每个人都能在自己的环境中跑通程序,但是在评审环境中,有些程序却无法运行。因此在日常测试过程中,我们除了程序本身的正确性以外,还需关注环境差异可能带来的问题。这里顺带吐槽一下,如果公司能使用docker等容器技术,将会提升我们的版本质量,降低因环境不同而出错的概率。
  • 规范意识有待提高:虽然题目中已经将组包格式、程序端口等做了要求,也已将注意点通知到所有人,但是还是有很多人没有遵守,导致测试程序跑分较低。这反映出大部分开发人员的特点,只管闷头写代码,却忽视了规范要求,导致日后返工,甚至产生线上故障,导致严重的后果。建议大家在日常编码之前,提前熟悉并遵守规范和要求,避免走弯路。

最后,感谢大家对我的容忍。2021,愿所有程序都不出bug!

发表评论

评论已关闭。

相关文章