傳統(tǒng)上，自動化測試分為單元測試、集成測試和端到端測試。這種分類是基于測試的范圍，盡管不同類型之間的區(qū)別并不總是很清楚。單元測試的范圍很窄，通常測試單個方法或類。集成測試驗證不同組件之間的交互。端到端測試通常在平臺或 Web 應用程序上執(zhí)行完整的用戶流程，涉及多個不同的系統(tǒng)。

隨著代碼庫的增長，緩慢且不穩(wěn)定的測試開始影響開發(fā)人員的生產力。從另一個維度(速度和確定性)檢查測試套件是有啟發(fā)性的。

緩慢和非決定論的根源

通過直覺和經驗，我們知道端到端測試和集成測試比單元測試更慢、更不穩(wěn)定，但為什么會這樣呢?讓我們考慮一下測試運行的環(huán)境。

單線程或進程

當測試在單個進程中運行時，被測試的代碼也在同一進程中運行。這阻止了在單獨的進程中創(chuàng)建服務器或數(shù)據庫并在測試中連接到它們。依賴于服務器或數(shù)據庫的測試必須使用模擬或偽造。

這些測試不會進行任何阻塞的進程間 I/O 調用，從而消除了緩慢和不確定性的主要根源。

單機

一些測試跨多個進程運行，在測試代碼的不同進程中啟動數(shù)據庫和服務器，并對它們進行阻塞調用。他們甚至可以在同一臺機器上進行網絡調用。

測試代碼現(xiàn)在依賴于其他進程才能可靠運行，但情況可能并不總是如此?，F(xiàn)在，測試代碼在進行 API 調用時會受到操作系統(tǒng)調度程序和其他因素的影響。盡管與單線程測試相比，這會帶來一些緩慢和不穩(wěn)定的情況，但限制在一臺機器上仍然會阻止測試對其他機器進行遠程調用，這是不確定性的最大來源。這讓我們……

多臺機器

這些測試的運行實際上沒有任何限制。特別是隨著云環(huán)境成為 SaaS 應用程序的常態(tài)，測試套件可以啟動多個云資源并跨多個虛擬機運行完整的系統(tǒng)測試。由于測試現(xiàn)在有多個依賴項，因此即使一個組件出現(xiàn)故障也會影響整個測試。

設計測試套件

一個好的測試套件有幾個好處：

1. 可維護性——經過良好測試的代碼更易于維護，允許開發(fā)人員添加新功能、修復錯誤和重構代碼，而不必擔心無意中破壞不相關的代碼。

2. 文檔– 鑒于有關服務或功能的文檔很容易過時，編寫良好的測試通常是理解代碼行為的最佳方法。

3. 干凈的 API – 黑盒測試確保被測代碼公開正確的 API 接口。

4. 覆蓋范圍——廣泛的測試覆蓋范圍使工程和非工程利益相關者(包括銷售和市場推廣團隊)對發(fā)布過程充滿信心。

為了使測試套件有效且可靠，同時提高開發(fā)人員的工作效率，它必須最大限度地減少緩慢和不確定性。單元測試、集成測試和端到端測試之間的界限也可能是模糊的。因此，在為系統(tǒng)設計測試套件時，根據測試使用的資源來考慮測試會很有幫助。

Mike Cohn 的測試金字塔為思考如何構建不同類別的測試提供了一個很好的起點。這里我們也用它來類比基于范圍的測試和基于環(huán)境的測試。

結論

· 大多數(shù)測試應該是快速且可靠的單線程測試，針對狹窄的代碼部分。

· 您的一些測試應該是單機測試，引入不同的本地依賴項并測試不同組件如何相互交互。

· 很少有測試應該跨遠程計算機運行，從而練習應用程序的端到端流程。

這種結構傾向于在廣泛的覆蓋范圍、最大化速度和最小化片狀性之間取得適當?shù)钠胶?，從而形成有效的測試套件。