前一阶段我们的产品接入了云信SDK，下面是核心的测试用例。
云信IM用例.png
需求评审会结束后，技术负责人组织了开发设计评审会。了解到，之前我们设计是通过uid两个用户进行通信，接入云信IM，相当于接入了SDK。其他的服务怎么可是识别我们的uid，再说了如果讲用户信息提供给第三方岂不是很不安全，所以需要将用户的uid与云信ID绑定，然后用户通过云信ID做唯一标识来通信。
首先，用户如何通过云信通信？
- 新注册的用户是否直接绑定了云信ID
- 老用户并没有云信ID，需要服务端跑脚本绑定（用户群体大的时候需要考虑到服务器的压力及处理能力）
- 老版本升级到新版本（老版本没有处理云信ID的逻辑，升级为新版本是否获取并存储了云信ID）
想想，云信服务，肯定要通信了，所以要测试socket的连接情况以及处理机制，比如socket断开重连机制
- 网络环境良好，聊天会话页面长时间socket连接是否正常
- WiFi->4G,socket是否有重连机制
- 网络环境较差时，是否有丢包现象，以此来衡量socket的稳定性
- 在非会话页面，socket连接情况，比如其他同级页面，子页面，应用挂至后台等
- 账号退出后，socket是否断开（用户间通信都是用过云信ID，账号退出了，云信ID没有退出岂不是尴尬）
- 账号间切换，信息显示及socket连接情况
- 用户清除本地数据是否会把云信ID清除
当然，虽说上面主要说socket通信及相关处理机制，用户ID与云信ID绑定，但是发现忽略了重要的一点，就是网速很差的时候，获取不到云信ID怎么办？岂不是前置条件都忘记了？比如请求多次用户信息获取云信ID，尽量保证通信ID获取到，用户间可以正常的通信
特殊情况
- 云信ID有没失效时间，其要大于等于用户ID的token失效的时间，所以要对云信
- 用户重新登录时会重新获取token值，此时云信token会不会更新
所以要了解token的更新及缓存机制，深入了解技术设计
