WebSocket技術的負載和性能測試

隨著HTML5的引入，WebSocket協議允許瀏覽器和網站之間進行更多的交互，促進實時應用程序和實時內容。WebSocket技術在客戶機和服務器之間創建持久連接，從而避免了由客戶機發起的HTTP請求觸發服務器響應的要求。WebSocket通過一個TCP連接提供了一個全雙工通信通道，是最有效的網絡實時響應協議。

如果你使用WebSocket技術，性能測試將歸結為模擬應用程序的雙向特性。

同步與異步調用

首先，您需要了解應用程序使用的WebSocket通信類型:同步調用還是異步調用。

除了方便實時應用程序之外，web開發人員還使用WebSockets來維持客戶端和服務器之間更快、更長的連接，甚至用於傳統的請求-響應目的。這種通過WebSockets進行的傳統請求-響應通信導致同步調用。

另一方麵，異步調用不需要客戶端請求來發起服務器響應。服務器自動通過單個TCP連接(保持打開狀態)推送信息和更新，允許進行持續的雙向對話。

測試人員必須意識到兩者之間的差異，以便正確地測量響應時間和驗證應用程序的性能．

注意事項

異步調用

在測量異步調用的響應時間時，事情可能會變得有點棘手。傳統上，測試人員將測量從客戶端發送請求到接收響應所花費的時間。對於異步調用，最終用戶的操作將決定服務器交互，因此，很難測量將消息傳輸到客戶機所花費的時間或延遲。

因為消息是由外部事件生成的，並且服務器決定何時將消息發送到所有連接的客戶端，所以測試人員最感興趣的是測量觸發外部事件後客戶端接收消息所需的時間。

同步調用

與異步調用相比，測量同步調用的響應時間要容易得多，也更直接。它與問答方法有關，測試人員隻是發送請求並等待響應。

設計測試

為同步調用設計測試用例很簡單，因為測試人員隻需要理解與用戶交互相關的每個請求/響應。真正的挑戰在於為異步調用設計測試。

異步調用的性質改變了設計的負載測試場景中所需的邏輯，並且測試人員還麵臨許多與測試流媒體和長輪詢相關的問題。

限製

測試人員在測試WebSocket技術時可能會麵臨硬件和瀏覽器兼容性的限製。開放的WebSocket通道促進了客戶端和服務器之間的直接、開放連接。如果有成千上萬的客戶或連接通過您的服務器訪問數據，測試人員將需要根據單個服務器可以處理的套接字數量相應地調整後端。

還有一些瀏覽器不支持WebSocket通信。在這種情況下，應用程序將用長輪詢代替WebSocket通信。對於性能工程師來說，這意味著為每個用例創建兩個用戶路徑(一個使用WebSockets，另一個使用長輪詢)。確保現實負載測試，測試人員必須考慮兼容websocket的瀏覽器和不兼容的瀏覽器的比例。

WebSocket技術的負載和性能測試技巧

異步調用

測量異步調用延遲的方法與應用程序框架直接相關。例如，當使用套接字。IO，在WebSocket消息中包含時間戳應該是一個要求。測試人員可以立即發送消息，然後，在收到客戶端級別的響應後，計算時間戳之間的時間。WebSocket沒有一個標準的框架，在支持WebSocket通信的框架中，很少會自動包含時間戳。測試人員可能需要與開發人員一起在消息中包含這些信息。這可能很痛苦，但是測試WebSocket的性能是必要的。

同步調用

為了測量同步調用的響應時間，您需要確保您的負載測試解決方案首先支持WebSocket技術。它還應該能夠將WebSocket請求與適當的WebSocket響應鏈接起來。重要的是要注意，測試這種異步通信的能力在軟件測試產品中是罕見的——明智地選擇您的工具。

設計測試

對於較新的測試人員和習慣於設計普通web場景的測試人員來說，設計通過WebSocket處理調用的測試可能會令人困惑。這將歸結為理解您的應用程序和請求-響應通信的性質。在設計測試時，請確保您正在重現應用程序與真實瀏覽器通信的行為。

同樣，為同步調用設計測試用例相當簡單，因為這些調用使用傳統的請求/響應通信。為了測量它們的性能，您需要為您的測試團隊配備一個負載測試方案允許測試WebSockets上的同步調用。

為異步調用設計測試用例更具挑戰性。在這種情況下，通過WebSockets連接的用戶將從信息顯示在屏幕上的那一刻起采取特定的操作。例如，當價格達到一定水平時，用戶可能決定購買股票。否則，用戶可能不采取任何操作。請記住，用例中包含的用戶操作取決於是否通過WebSocket通道到達的信息。

限製

為了解決硬件問題，您需要確保有多個服務器來平衡訪問WebSocket連接的負載。與HTTP通信不同，在成功的請求-響應交互後，連接將被關閉，WebSocket連接將保持打開狀態。如果服務器無法處理負載，則這些連接將關閉，從而導致終端用戶的應用程序性能較差。

為了解決瀏覽器不兼容的問題，可以引入WebSocket框架作為解決方案。否則，您將需要在負載和性能測試期間設計和執行輪詢場景。

WebSockets的本質也帶來了挑戰——它是一個傳輸層，所以你的項目可以交換文本數據、二進製數據等等。性能工程師將需要解碼或反序列化WebSocket消息，以便關聯測試場景。

結論

WebSockets隻是提供了一種交換數據的方式，所以這項技術不會徹底改變組織處理測試的方式。測試團隊隻需要了解他們在測試WebSocket技術時所麵臨的挑戰——比如瀏覽器不兼容和收集異步調用的響應時間。

最終，為您的測試團隊配備負載測試解決方案，不僅能夠測試利用WebSockets的請求-響應應用程序，還可以管理服務器發送的非初始響應，這將導致最有效、最現實的性能測試。

為了確保無縫的用戶體驗，僅僅測量延遲是不夠的。為了真正驗證利用WebSockets的應用程序的性能，您應該將WebSocket負載測試場景與基於瀏覽器的工具(如Selenium)上的場景結合起來——但這是另一個話題了。

本博客最初發布於2017年1月，並於2021年7月更新。