測試場景：

　　1.多名用戶加入房間。

　　2.房間人數(shù)為固定人數(shù)（比如4人）

　　3.有人進入時，進入用戶會收到反饋當前房間人員列表。

　　4.其他人會收到反饋新加入用戶的信息消息。

　　5.當人數(shù)已滿時，會自動推送消息給所有人。

　　6.在人滿后，每個人需要按固定序列，發(fā)送消息。

　　7.所有人發(fā)送特定消息后，推進房間狀態(tài)，返回新的一組信息。

　　jmeter的邏輯結構

　　建立連接

　　循環(huán)1開始

　　進入房間

　　循環(huán)2開始

　　接受消息

　　解析消息

　　if（消息格式符合條件1）

　　執(zhí)行動作1

　　if（消息格式符合條件2）

　　執(zhí)行動作2

　　設置循環(huán)2控制變量，跳出循環(huán)

　　...

　　循環(huán)2結束

　　循環(huán)1結束

　　在整個編輯過程中，踩了幾個小坑。

　　1.用戶自定義變量 不可修改

　　問題場景：在控制循環(huán)2的跳出條件時，直接使用了【用戶自定義變量】來定義控制循環(huán)2的變量，結果，總是無法正確觸發(fā)跳出循環(huán)。查詢資料才知道【用戶自定義變量】是會只讀一次的類型。

　　解決方案：修改為【用戶參數(shù)】，解決問題。

　　2.while循環(huán)和if判定的條件格式

　　問題場景：同樣是用于條件格式，只有if強調(diào)了需要使用 __jexl3() 來計算語句邏輯，最終必須為true格式。

　　然后在實際使用中發(fā)現(xiàn)，while的判斷也需要類似的需求。

　　最初填寫的內(nèi)容為  ${x}==a  ，此處由于  ${x} 不為 null 或false，就直接驗證為成功了。

　　之后嘗試修改 ${x}的值，仍然無法正確跳出循環(huán)，再加上問題1，導致浪費了很多時間。

　　解決方案：通過修改為 ${__jexl3(${notInRoom}==1,)}，強制邏輯計算，解決手問題。

　　3.變量格式不一致，導致的判斷異常

　　問題場景：同樣是if判斷，在判斷中，由于字符變量的表現(xiàn)格式，在jmeter和java中的差異導致。

　　原本的判斷類型為變量 stage 的值是否為字符串 settle。開始使用 ${__jexl3( ${stage} == settle,)}，總是無法正確獲取判斷結果。

　　解決方案：修改兩側(cè)格式為字符串，${__jexl3( "${stage}" == "settle",)}，解決問題。

　　4.固定定時器的延時狀態(tài)會導致接受消息的時機被錯過。

　　問題場景：原本為了放緩代碼的刷新速度（調(diào)試階段，太多了看不過來），在循環(huán)中添加了【固定定時器】延時。

　　結果在延時的過程中，經(jīng)常會丟掉一些關鍵信息，導致本地邏輯無法繼續(xù)。

　　解決方案：加長 response timeout的時長，代替延時