端到端測試：隔離式服務器

　　Web 應用的測試經常需要進行從用戶角度的系統性的功能測試，涉及到從用戶請求到服務器響應的整個過程，也叫做端到端測試。在最近的 Google Test Blog 上，我看到一篇文章，覺得是進行這種測試一個不錯的思路，翻譯如下，供大家參考。

　　隔離式服務器

　　By Chaitali Narla and Diego Salas (原文地址)

　　讓我們考慮一個復雜的 Web 應用程序。 實現它的可能是成堆的服務器，而且每臺服務器都運行著不同的任務并相互通訊。 每個用戶操作都會訪問這個服務器集群，并經歷一次從用戶到數據存儲再到用戶的往返。 包括 GMail 和 Google+ 在內的很多 Google 的 Web 應用都是這樣工作的。 那么我們如何為它們編寫端到端的測試 (end-to-end test) 呢?

　　“端到端”的測試

　　在 Google 測試世界里，端到端測試是指作用于從用戶請求到響應的整個流程和全部服務器集群的測試。下面是一個簡化的由端到端測試所涵蓋的被測系統 (SUT) 的示意圖。注意圖中被測系統的的前端服務器連接到了一個第三方后臺服務器，但是這個第三方服務器并不被圖中特定的用戶請求所使用。

　　為這樣的系統編寫一個快速而可靠的端到端測試所面臨的一個挑戰是要避免網絡訪問。涉及到網絡訪問的測試要比那些只訪問本地資源的測試執行得慢，而且訪問外部服務器可能由于外部服務器不可用或不穩定而帶來怪異的結果。

　　隔離式服務器

　　我們在 Google 設計端到端測試的一個技巧就是使用隔離式服務器 (Hermetic Servers)。

　　什么是隔離式服務器? 簡短的定義就是“單機服務器”。 如果你能在一臺單獨的沒有網絡連接的機器上啟動整個服務，并使其正常工作，它就是一臺隔離式服務器! “隔離”的概念從更廣義上來講適用于所有隔離的系統而不一定是單臺機器，但這里提到的是一個特例。

　　為什么隔離式服務器很有用呢? 因為如果整個被測系統由隔離式服務器構成，它就能在一臺單獨的機器上啟動來用于測試;根本不需要網絡連接! 這臺單機可以是物理機，也可以是虛擬機。

　　設計隔離式服務器

　　構建隔離式服務器的過程需要從新服務器設計階段的前期就要開始。需要注意下面一些事情：

　　服務器中所有與其他服務器的連接都需要在運行時注入。這可以通過一種適合的依賴注入形式完成，例如命令行標志或者 Guice 。

　　所有必需的靜態文件都要打入服務器的二進制包。

　　如果服務器需要訪問數據庫，則需要保證數據庫能被數據文件或者內存數據庫模擬。

　　滿足上述要求保證了我們的服務器具有高度的可配置性，從而有條件成為隔離式服務器。但它目前還不能被用于測試，我們還需要完成下面一些事情：

　　確保我們的測試不會訪問到的連接點都具有相應的模擬對象，這樣可以驗證這些連接確實沒被訪問。

　　提供一個模塊可以簡單地向數據存儲填充測試數據。

　　提供日志記錄模塊，可以幫助跟蹤請求/相應回路在被測系統中流轉的過程。

　　在測試中使用隔離式服務器

　　我們看一下前面提到的那個被測系統。假設里面的所有服務器都是隔離式服務器，那我們的對同樣一條用戶請求的端到端測試就會是下面這個樣子：

　　這個端到端測試執行了以下步驟：

　　在單獨的一臺機器上啟動圖中所示的整個被測系統

　　通過測試客戶端向服務器發送請求

　　驗證服務器響應

　　需要注意的是圖中到模擬服務器的連接在這個測試中并不需要。如果被測試的請求需要連接這個后端服務，我們就需要在這個連接點也提供一個隔離式服務器。

　　由于沒有用到網絡連接，這個端到端測試就更加可靠了。因為它所需要的所有東西都在內存或者本地硬盤存儲，這個測試也會更加快速。我們在持續構建中執行這樣的測試，讓它們可以在每次提交影響到被測系統中任意一臺服務器的情況下被運行。如果測試失敗，就可以通過日志模塊幫助在被測系統中跟蹤失敗出現的位置。

　　我們在大量的端到端測試中用到了隔離式服務器。一些基本的例子包括：

　　對使用了 Guice 框架的服務器進行啟動測試，用來驗證在啟動過程中沒有 Guice 的錯誤。

　　后臺服務器的 API 測試

　　微型環境的基準性能測試

　　前臺服務器的 UI 和 API 測試

　　結語

　　隔離式服務器還是存在局限性的。每次執行端到端測試的時候都啟動整個被測系統，這回延長測試執行的時間。如果你的測試所用需資源是有限的，如內存和 CPU，隔離式服務器的使用可能會由于交互的復雜性而使得資源不足。使用內存數據存儲也會讓測試集的大小比生產環境數據存儲小得多。

　　隔離式服務器是一個很好的測試工具。但像其他工具一樣，需要在使用前好好思考它的適用性。

原文轉自：http://testing.etao.com/node/618