是什麼
探討訊息佇列的測試，那首先就要了解訊息佇列是什麼。
訊息佇列是一種應用程式之間傳遞訊息的非同步通訊機制。這裡傳遞的訊息指的是需要傳輸的資料，可以是一些文字、字串或物件等資訊。
簡述一下訊息佇列工作模式：
- 訊息的生產者將資料存放到訊息佇列中，消費者進行接收處理。生產者和消費者分開，彼此不受影響
- 訊息被儲存在訊息佇列中，訊息佇列把資料進行持久化直到它們已經被完全處理，確保訊息傳遞的可靠性和順序性
- 訊息佇列可以有多個消費者，提高系統處理能力，支援快速水平擴充套件
用哪裡
根據訊息佇列的特性，訊息佇列有以下幾種最常用的應用場景。
非同步處理
非實時的業務場景，可以採用非同步處理來提高系統的吞吐量和響應時間。
系統解耦
透過訊息佇列，可以將不同系統或模組之間的依賴關係解除，使得它們可以獨立地進行開發和部署。
訊息佇列能夠隔離故障，當某個系統發生故障時，不會影響到其他服務，提高了系統的整體穩定性。
限流削峰
在大促、秒殺等活動中，瞬時流量可能會非常大，業務系統直接處理，就會壓力太大就會導致大量系統異常，業務失敗甚至系統崩潰。透過將請求資訊儲存到訊息佇列中，將壓力轉移到MQ中，並由後端服務非同步處理這些儲存在訊息佇列中的訊息，可以有效地緩解系統壓力。
怎麼測
測試前：技術方案評審
QA在參與RD的技術方案評審中，就需要考慮以下三點：要不要用；用的地方合不合適；用哪款
要不要用訊息佇列
在系統設計中，需不需要使用訊息佇列，可以參考上文提到的訊息佇列最常用的應用場景中的一些場景。比如系統需要處理大量併發的請求，並且請求處理時間比較長，就可以使用訊息佇列進行一步處理。又或者系統多個模組之間需要通訊，但是又不希望相互之間之間呼叫介面或者方法，就可以使用訊息佇列進行解耦。
當然，使用訊息佇列也會有一些挑戰。
首先就是資料一致性的問題，資料一致性也是測試的一項重點。消費的重複消費、訊息丟失、分散式系統中訊息事務性和資料庫操作一致性都會帶來資料一致性的挑戰。其次系統中使用訊息佇列是也會增加系統維護複雜性，同時也會增加一定的成本支出。
在實際的技術設計中，需要具體根據實際的業務場景判斷是否使用訊息佇列。
訊息佇列應用的場景是否合理
在技術評審中，QA要根據實際的業務場景，思考設計方案中的訊息佇列中使用場景是否合理。
使用的訊息佇列產品是否合理
訊息佇列也有不同的產品，我們在使用訊息佇列時，也需要根據我們的業務場景選擇合適的場景。常用的訊息佇列產品有三類，分別是基於記憶體的訊息佇列、基於磁碟的訊息佇列、分散式訊息佇列。
Kafka適合大規模資料處理，RabbitMq適合輕量級應用，等等。具體可以根據自己的業務特性來選擇。
測試中：業務中測試
是否能傳達
訊息傳送
- 不同型別(如文字、字串、二進位制資料等)的訊息能否成功傳送到佇列
- 訊息屬性的是否生效，比如過期時間
- 訊息傳送頻率控制，驗證系統能否處理高頻率的訊息傳送
訊息接收
- 訊息佇列的連線測試
- 訊息接收的確認
- 訊息接收的順序性
是否能正常傳達
訊息的重發機制
- 訊息重發機制：故意使消費者接收訊息失敗，檢查訊息佇列是否能夠自動重發訊息
- 引數設定是否有效：測試重發次數、重發間隔等引數的設定是否有效
- 冪等性處理，為防止訊息重複處理，系統需實現冪等性，確保訊息多次重發不會影響業務邏輯。
訊息的防丟失驗證
- 訊息佇列應確保訊息在系統重啟後能夠從儲存中恢復，保證訊息不丟失
- 摸擬故障場景，驗證訊息佇列在系統故障後能否正確恢復訊息狀態，保證資料一致性
是否能高效能傳達
吞吐量
- 訊息處理速率：衡量訊息佇列在單位時間內能處理的訊息數量，反映系統處理訊息的能力。
- 併發使用者：測試在不同併發使用者數下，訊息佇列的吞吐量表現，確保系統穩定執行。
- 系統資源佔用：監控在高吞吐量下系統資源（如 CPU、記憶體)的使用情況，評估資源效率。
延遲處理
- 在不同壓力下，訊息從傳送到被處理的平均時間，確保有訊息佇列的鏈路能滿足整個系統的需要
- 網路傳輸延遲，訊息在不同網路條件下，測試從傳送端到接收端的延遲時間，從而評估網路對訊息佇列的影響
- 在高負載的壓力下，測試訊息佇列的延遲，確保高壓力下系統的穩定性
可擴充套件性測試
- 水平擴充套件
- 在高負載情況下，增加訊息佇列的節點數量，測試系統的效能和吞吐量能否線性提升
- 垂直擴充套件
- 提升單個節點的硬體資源，觀察訊息佇列的效能變化
是否能安全傳達
- 資料加密
- 選擇合適的加密演算法，既能確保資料傳輸和儲存的安全性，又能不過多消耗資源
- 訊息防篡改，驗證訊息在傳輸和儲存過程中是否能夠防止被篡改
- 訪問控制
- 許可權和角色控制，被授權的使用者和角色才能訪問訊息佇列資源
測試後：監控報警配置
在上線之前，為確保系統穩定執行，需與研發（RD）及產品團隊緊密協作，統一報警配置，並制定詳盡的緊急情況應對標準操作流程（SOP）。此過程中，質量保障（QA）團隊將負責核對監控報警系統，確保已配置與訊息佇列相關的監控項及報警機制，並驗證其有效性。監控內容應全面覆蓋，包括但不限於訊息佇列的每秒查詢率（QPS）、伺服器的效能指標等關鍵資訊。針對這些監控指標，QA團隊和RD團隊協作需合理設定閾值，並配置相應的報警規則，以便及時發現並響應潛在問題。