近期，公司为了锻炼开发人员技能，举办了一场涵盖多个技术线的技能大练兵，我有幸受邀负责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包和配置，要求参赛者必须引入，以模拟超时或者异常，从而引发数据不一致，测试程序的健壮性。

测试方法

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

服务拓扑图如下：

自动部署

所有选手的交付物都提交到统一的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！