开篇先扔一张图，下图是我本次
测试对象的简单架构图：
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，说到这里，基本的架构以及流程说完了。现在，有一个任务就是，会议管理界面上的某个按钮点击之后，“实时状态”感觉变化很慢。（比如我点击全部静音按钮，页面上与会人员的图标会显示出一个小图标表示被静音了，对，就是这个操作后，图标很久才显示出来，测试找出原因）
如果交给各位读者这样的测试需求（当然，这个根本算不上需求，我就这么被忽悠了），读者朋友们会怎么进行这项测试呢？？
好了，各位，下面我给出我本次测试中采用的方法（如果觉得有更好的，请留言联系我！），先看图：
