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