前段时间刚测试的一个项目,其中两个系统之间需要实现增量数量的读取更新,即A系统获取到增量数据后通知B系统获取新增数据并进行后续的处理,为达到这一目标,最终设计为A数据存在增量数据至activeMQ,B系统从activeMQ中获取数据,为此,开发童鞋需实现一个通用的客户端工具包,方便两个系统发送和读取消息。
测试思路:
根据项目情况分析,该消息中间件的测试主要关注点是“生产者”、“消费者”两者针对消息的处理是否正常,即:
1.生产者能否将消息正确写入activeMQ
2.消费者能否从activeMQ中拉取出消息
3.写入的消息与拉取的消息是否能一一对应
由于消息的序列化格式使用的是protoBuffer,所以测试之前对其也进行了一下学习了解,主要关注:
1).proc文件格式的定义
在此文件中定义消息的格式字段,主要有三种类型:
required:必须赋值、不可为空
optional:可赋值也可不赋值
repeated:可重复任意次数,可将该关键字修饰的字段看成自动设置size的数组
需根据具体业务分析定义的proc文件中的字段是否符合真实业务的需要
2)proc文件的编译
将定义好的proc文件编译成需要的java文件,命令格式: protoc --proto_path=IMPORT_PATH --java_out=DST_DIR path/to/file.proto
proto_path:需编译的proc文件所在路径
java_out:编译生成java文件的路径,也可在proc文件中定义:option java_package=.....
编译生成的java文件有三种类型:
SPEED:生成的代码效率高,但会占用更多的空间
CODE_SIZE:与SPEED相反
LITE_RUNTIME:生成的代码效率高、占用空间少,但是要牺牲反射功能(这一点不太理解)
可在proc文件中对设置上述三项:option optimize_for=
上述准备工作都就绪以后,便可开始测试:
1.根据proc生成需要的java类,上述3个类型都需生成一份
2.模拟生产者调用开发提供的公共客户端,设置生产者数据并发送到activeMQ中(调用3种类型的java文件,即上面提到的SPEED、CODE_SIZE、LITE_RUNTIME)
3.模拟消费者调用开发提供的公共客户端,从activeMQ中拉取数据并解析(调用3种类型的java文件,即上面提到的SPEED、CODE_SIZE、LITE_RUNTIME)
4.验证生产者数据与消费者拉取到的数据一致
5.上述操作批量执行
测试结果:提供的客户端只能实现SPEED一种java文件定义格式的生产和消费,其他两种会出现异常!