开篇先扔一张图,下图是我本次测试对象的简单架构图:

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