前段時間剛測試的一個項目，其中兩個系統之間需要實現增量數量的讀取更新，即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文件定義格式的生產和消費，其他兩種會出現異常！