最近新接手了个websocket项目，消息模式有点类似聊天室的操作。
没有办法确定response的内容和时间。在网上搜了一圈，也没有找到类似的科普文章。
在这里写一篇文章记录一下问题和解决情况。
希望能抛砖引玉，把这个问题攻克下来。
首先，准备jmeter环境和websocket的支持库。
相关操作在简书《JMeter测试WebSocket的经验总结》一文中可以找到。原文地址：
https://www.jianshu.com/p/bb8b3e928607
感谢 smooth00 大神的引用授权。
测试场景：
1.多名用户加入房间。
2.房间人数为固定人数（比如4人）
3.有人进入时，进入用户会收到反馈当前房间人员列表。
4.其他人会收到反馈新加入用户的信息消息。
5.当人数已满时，会自动推送消息给所有人。
6.在人满后，每个人需要按固定序列，发送消息。
7.所有人发送特定消息后，推进房间状态，返回新的一组信息。
jmeter的逻辑结构
建立连接
循环1开始
进入房间
循环2开始
接受消息
解析消息
if（消息格式符合条件1）
执行动作1
if（消息格式符合条件2）
执行动作2
设置循环2控制变量，跳出循环
...
循环2结束
循环1结束
在整个编辑过程中，踩了几个小坑。
1.用户自定义变量 不可修改
问题场景：在控制循环2的跳出条件时，直接使用了【用户自定义变量】来定义控制循环2的变量，结果，总是无法正确触发跳出循环。查询资料才知道【用户自定义变量】是会只读一次的类型。
解决方案：修改为【用户参数】，解决问题。
2.while循环和if判定的条件格式
问题场景：同样是用于条件格式，只有if强调了需要使用 __jexl3() 来计算语句逻辑，最终必须为true格式。
然后在实际使用中发现，while的判断也需要类似的需求。
最初填写的内容为 ${x}==a ，此处由于 ${x} 不为 null 或false，就直接验证为成功了。
之后尝试修改 ${x}的值，仍然无法正确跳出循环，再加上问题1，导致浪费了很多时间。
解决方案：通过修改为 ${__jexl3(${notInRoom}==1,)}，强制逻辑计算，解决手问题。
3.变量格式不一致，导致的判断异常
问题场景：同样是if判断，在判断中，由于字符变量的表现格式，在jmeter和java中的差异导致。
原本的判断类型为变量 stage 的值是否为字符串 settle。开始使用 ${__jexl3( ${stage} == settle,)}，总是无法正确获取判断结果。
解决方案：修改两侧格式为字符串，${__jexl3( "${stage}" == "settle",)}，解决问题。
4.固定定时器的延时状态会导致接受消息的时机被错过。
问题场景：原本为了放缓代码的刷新速度（调试阶段，太多了看不过来），在循环中添加了【固定定时器】延时。
结果在延时的过程中，经常会丢掉一些关键信息，导致本地逻辑无法继续。
解决方案：加长 response timeout的时长，代替延时
原文地址：https://www.cnblogs.com/worker-overtime/p/10197513.html