開篇先扔一張圖，下圖是我本次
測試對象的簡單架構圖：
meeting
先簡單介紹下整個流程吧，我們根據圖中畫的來說（下文中說到的節點之后會講）：
1、首先瀏覽器發出一個http請求至會管后臺
2、會管收到請求后向zookeeper的一個節點（數據節點）中寫入消息（一般就是某種請求的消息）
3、會議平臺watch到zookeeper中該節點數據變化便從中把這條消息取出，并進行處理。注意：異步消息（我們應用大部分是異步消息）
4、平臺在取出zookeeper節點上的消息后會立即往zookeeper中的另外一個節點（數據節點）上寫入消息（該消息表示我平臺已經收到來自你會管的消息了）
5、會管也會watch到這個節點的變化進而去讀取這個消息，然后將該消息放入xmpp服務器，由xmpp推送給瀏覽器（當然，其實這個消息并沒有什么實際意義）
6、另外還有就是等平臺處理完一開始會管的請求消息后（3中的消息），會再次推送處理結果后的消息（比如某個人被靜音了，就會推送一串json數據，其中有標識說這個人被靜音了）到zookeeper的狀態節點（OK，先不要管他什么數據節點和狀態節點）
7、然后會管watch到后讀取該數據并進行一系列封裝和處理
8、數據處理和封裝完成后將數據放入xmpp服務器
9、由xmpp服務器推送給瀏覽器，從而實現瀏覽器的實時狀態
OK，說到這里，基本的架構以及流程說完了。現在，有一個任務就是，會議管理界面上的某個按鈕點擊之后，“實時狀態”感覺變化很慢。（比如我點擊全部靜音按鈕，頁面上與會人員的圖標會顯示出一個小圖標表示被靜音了，對，就是這個操作后，圖標很久才顯示出來，測試找出原因）
如果交給各位讀者這樣的測試需求（當然，這個根本算不上需求，我就這么被忽悠了），讀者朋友們會怎么進行這項測試呢？？
好了，各位，下面我給出我本次測試中采用的方法（如果覺得有更好的，請留言聯系我?。?，先看圖：