作者 | 赵里京

背景

目前转转的所有业务都在快速增长，支撑其用户服务的客服系统也同样在快速发展，以承接用户每天大量的问题。
最开始转转的客服系统体系如 IM，工单以及机器人等都是使用第三方的产品。但第三方产品对于转转的业务，以及客服的效率等都产生了诸多限制，所以我们决定自研替换第三方系统。下面主要说一下 IM 系统以及相关测试方法，先来了解一下 IM 系统和 WebSocket。

WebSocket？

WebSocket 是 HTML5 出的一种在单个 TCP 连接上进行全双工（通信允许数据在两个方向上同时传输）的通信协议。

• WebSocket 与 http 协议区别：简单的说跟 HTTP 协议基本没有关系，WebSocket 只基于 HTTP，或者说借用了 HTTP 的协议来完成握手动作。
• WebSocket 与 Socket 区别：WebSocket 是应用层协议，Socket 是传输控制层协议，即 WebSocket 建立了 Socket 连接。下图可直接说明两者区别。 IM 系统常用的实现方案：
• http 短轮询：循环发送 request 请求，有没有新消息都会发送
• http 长轮询：Client 端发送 request 请求，server 端收到后保持住此次请求 x 秒，x 秒过程中有消息立刻返回。没有新消息就等待 x 秒，x 秒后放开请求，Client 端再发送请求， 不断反复
• WebSocket 长连接：Client 端发送 http 请求，http 请求会比普通的 http 请求多出信息如下图，这个就是 Websocket 的核心了，告诉 Nginx 注意啦我发起的是 Websocket 协议。与 Server 端建立握手成功后连接建立并在不触发 onClose 事件情况下不会断开

那么哪一种方案更加合适呢？短轮询与长轮询有以下几个缺点：

• 实时性差
• 每一次请求都需要进行用户身份验证。
• 流量开销大，每一次请求都会携带 header，但业务上 header 里面大部分的信息都是多余的，这样就产生了数据的冗余。 而 WebSocket 不存在以上几个问题，身份验证只进行一次。传输信息完全由业务方自定义，不会有冗余。当然 WebSocket 也有自身的问题，应用置后台、终止进程、手机重启、4g 转 wifi、断网等都会中断连接。所以 WebSocket 方案在实时性以及稳定性上更加合适 IM，我们也选择的是 WebSocket。

项目整体测试过程

先从一张图看看我们在项目中的整体测试过程

1. 前置测试阶段 所谓 “前置测试阶段” 就是在开发的过程中进行的测试。首先在需求评审完成后，我们基于 WebSocket 开发了 UserWebSocketClient 和 KefuWebSocketClient 两个 WSClient 实例，分别模拟用户端和客服端。实现功能有：用户与客服登录，相互发送包括纯文本、表情、图片、商品和订单消息，会话转移，坐席状态转换，用户排队等，基于这两个测试实例来不断的测试调试开发的版本。 WSClient 有 4 个主要事件：onOpen、onMessage、onClose 和 onError，首先是 WSClient 发送 onOpen 事件与服务器握手建立连接，成功后发送心跳消息保持连接。同时触发 onMessage 事件，onMessage 开始监听服务端发来的信息，我们可以在 onMessage 中进行需求实现。onOpen、onMessage 为异步操作。以上代码是由一个线程来执行，所以可以对以上代码进行多线程操作。
2. 功能测试阶段 也就是正式的测试阶段，这一阶段除业务需求功能外,有 IM 系统自身的特性，需要我们重点关注以下几点：
   • 消息实时性
   • 消息可靠性
   • 消息断线重连
   • 容灾容错
   • 系统的安全性
   • 系统性能

实时性：
发送端发送消息，接收端能立刻收到。测试手段，在程序的 onMessage 中加入如下逻辑 long t1=System.currentTimeMillis();long t2=System.currentTimeMillis();System.out.println(t2-t1);分别获取发送端，接收端发出和接收信息的时间戳，差值即为延迟时间。还可以给 Server 端施加压力的情况下计算这个时间会更加贴近线上的实际场景。
可靠性：
所谓可靠性是指发送消息不丢失，异常提示准确等；如发送和接收方的消息数量与内容准确，并在网络异常的情况下有保障机制，保证发送的消息在网络恢复后，能够正常的发送到接收方。可在 WSClinet 的 onMessage 中循环发送大量消息，另一端进行统计，测试数据一致性。
异常提示准确，如网络情况的断网恢复提示，发送失败提示，已读未读提示等相关提示信息，能够保证用户清晰了解系统状态。
断线重连：
WebSocket 对于应用置后台、终止进程、手机重启、4g 与 wifi 互转、断网等都会中断连接，并且这些场景在实际使用中会经常发生。所以要对这些场景进行模拟。在这些场景下，IM 系统自身保证一个合理的功能。
容灾容错：
多集群场景，在其中一个服务停止运行后还可以保证会话重连。
安全性：
跨脚本站点攻击，用户可以发送任何文本内容，所以一定要做的就是跨站点脚本攻击的测试。发送消息到任意用户，即修改目标 id。验证会话的身份校验。
系统性能：
WS 在性能方面很重要的一点是在服务器上最大能支持的连接数量，最后会简单介绍一下使用 jmeter 如何进行 ws 建立连接的性能测试。

3.线上监控阶段
上线后我们使用 puppeteer 对线上进行 ui 自动化功能监控，监控主要有 3 个方面内容：
（1） 监控主流程的 ui 用例
主要包括的场景：用户客服登录 IM、机器人问题校验、用户与机器人互动、用户申请人工客服、排队、建立会话、消息发送回复最后关闭会话等。
（2） 监控平台
如果上面的用例执行失败，产生了快照，我们会将失败信息与快照上传到监控平台。可对错误记录进行查看和编辑。如图

目前平台功能简单，后期也会不断增加功能，如用例管理，监控频率设定，手动触发用例等等。
（3）上线自动触发 ui 用例
对应的集群上线完毕后，会通过 mq 消息推送到监听服务，监听服务收到后会自动触发用例执行，回归线上功能，并返回结果。

WebSocket 性能测试

最后，我们来简单介绍一下如何使用 Jmeter 进行 WebSocket 的性能测试。首先是 Jmeter 环境搭建和脚本配置，需要下载 jar 包

1. Jmeter（已有就不用了）
2. websocket 请求模板 JMeterWebSocketSamplers
3. jetty-http
4. jetty-io
5. jetty-util 6.websocket-api 7.websocket-client 8.websocket-common 将 2~4 中下载的 jar 包放到 Jmeter 以下目录下，就能够被调用了。再将你下载的所有 jar 包，复制到 apache-jmeter-4.0\lib\ext 下 (apache3 也可以)。 先在测试计划中添加线程组，然后右键添 Sampler 时就能看到 websocket 的模板，常用的就是 websocket request-response Sampler（连接 + 发送 data 或者只发 data）

如果需要用户认证，再加上用户的信息 http 信息头管理器，进行用户认证，连接和发送接收消息的基本配置搞定。就可以对 server 端进行 websocket 的连接和发送消息的压力测试了，非常简单。