测试场景：
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的时长，代替延时