开发Mock服务做性能测试 （下）

上期背景已经做了介绍，为D公司的WMS性能压测做Mock挡板。
接下来是公司内部的OMS系统需要做压测了，整个链路的测试方式如下图

内部系统链路概略图

一、内部系统测试场景需求
　1. 大并发量测试：
　 　a) 需要有开关来控制订单数量，例如订单文件达到一定阈值时会自动把保存的订单数据从库表中读取出来批量生成测试订单数据；
　 　b) 测试过程可以随时停止；
　 　c) 手动输入命令后就立即开始把积累的测试数据全部发往被测系统；
　 　d) 可以统计执行的结果数据，形成简单的测试报告；
　2. 饱和测试
　 　（解释： 类似于负载测试的概念，让公司的各个服务系统都处于一直在工作状态，这时候再把需要的测试数据发往对应的测试系统来检查这时该系统的性能情况）
　 　a) 开关控制Mock服务的文件读取；
　 　b) 一旦有新的订单文件包上传就下载并解析，生成测试数据后就直接发往OMS，不再积累数量；
　 　c) 可以统计执行的结果数据，形成简单的测试报告；

二、设计测试解决方案
　1. Mock Service内部有三个功能模块：
　 　a) 定时任务：FTP文件扫描，用于处理原始订单文件的下载，解压，读取，入库等细节；
　 　b) 定时任务：测试数据扫描，用于处理入库后的测试数据的数量监控、生成测试数据、下发测试数据文件；
　 　c) Jmeter压测执行：接收测试人员指令，自动执行压测任务，收集测试结果数据；
　 　注：下图中3个橘色时钟图案表示Mock service三个模块

设计测试方案

三、详细设计
　1. 定时任务：FTP文件扫描 （spring boot + quartz）
　 　a) 实现ScanShipmentJob: 大并发量测试时，用于订单数据文件的处理；
　 　b) 实现ScanAutoJob: 饱和测试时使用，用于记录扫描到的数据文件并记录其批次；
　2. 定时任务：测试数据扫描（spring boot + quartz）
　 　a) 实现ScanShipmentJob: 大并发量测试时使用，用于一次性将测试数据文件下发至各个Jmeter slave；
　 　b) 实现ScanAutoJob: 饱和测试时使用，分批次下发至各个jmeter slave，并执行测试；
　3. Jmeter压测执行
　 　a) 增加接口/ship/run来，执行大并发量测试；
　 　b) 配置jmeter的执行时的测试数据文件路径、测试数据文件的名称、保存测试结果的文件路径；
　 　c) 编写shell命令，让/ship/run接口可以调用；
　 　d) 测试结果的统计；
　4. 创建表
　 　a) 表global_config：设置大并发量测试时，开关和需要积累生成测试数据的阈值；
　 　b) 表history_files：用于订单数据是一次性消费，所以需要保存FTP上已经扫描过的文件名称，避免重复下载；
　 　c) 表auto_config：设置饱和测试时，程序是否扫描FTP和自动发送订单的开关，用于饱和测试；
　 　d) 表auto_batch：记录每一次自动扫描FTP获得的tgz文件的数量以及发送后，该批次的数据的使用情况；
　 　e) 表result，统计jmeter运行结果；

四、实现
　 　a) 1个master和4个slave；
　 　b) 在master上jmeter/bin目录下设置scripts、run_test、results文件夹；
　 　c) 在4个slave上设置testdata文件夹在4个slave上；
　 　d) 测试数据的分片：在不同的slave上其测试数据名称相同，但里面的内容不能相同，因为订单数据的处理不能重复，一个订单号只能用一次；
　 　e) 在run_test文件夹下编写shell脚本：run_jmeter.sh；

jmeter部署
run_jmeter.sh内容

五、部分标结构
　 　a) auto_batch: 记录饱和测试时扫描到的数据信息:
　 　 　 　* batch_id: 用时间戳来标识某次任务执行扫描到的文件批次号；
　 　 　 　* batch_amount: 该批次文件中的订单数量；
　 　 　 　* is_used: 该批数据是否已经被创建为csv测试数据文件了；
　 　 　 　* batch_id: 用时间戳来标识某次任务执行扫描到的文件批次号；

auto_batch

　 　b) global_config:记录大并发测试时开关：
　 　 　 　* shipment_amount: 累积订单数量阈值；
　 　 　 　* shipment_switch: 定时任务扫描FTP文件服务的开关；
　 　 　 　* is_used: 该批数据是否已经被创建为csv测试数据文件了；
　 　 　 　* batch_id: 用时间戳来标识某次任务执行扫描到的文件批次号；

global_config

c) result: 从jmeter的jtl文件中统计结果:
　 　 　 　* phase: 订单处理有两种状态, 1代表过仓反馈，2代表出库确认；

result

d) shipment_confirm：记录订单数据的详细信息；

六、一些缺点和问题：
　 　a) 饱和测试的过程还是单线程的，模拟的近似度还不够；
　 　b) 没有实现压测的动态控制线程大小，在压测过程中只能以固定的线程数去执行；
　 　b) 在从FTP服务器下载数据时，会遇到有些时候，压缩文件很大，订单还没有完全复制完成，就被我扫描到了，并且下载，导致订单文件不全或丢失；

相关文章：开发Mock服务做双十一压测 （上）