測試場景：

　　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的時長，代替延時