前段时间刚测试的一个项目，其中两个系统之间需要实现增量数量的读取更新，即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文件定义格式的生产和消费，其他两种会出现异常！