最近新接手了個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的時長，代替延時