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

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

緩慢和非決定論的根源

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

單線程或進(jìn)程

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

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

單機(jī)

一些測試跨多個進(jìn)程運(yùn)行，在測試代碼的不同進(jìn)程中啟動數(shù)據(jù)庫和服務(wù)器，并對它們進(jìn)行阻塞調(diào)用。他們甚至可以在同一臺機(jī)器上進(jìn)行網(wǎng)絡(luò)調(diào)用。

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

多臺機(jī)器

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

設(shè)計測試套件

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

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

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

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

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

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

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

結(jié)論

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

· 您的一些測試應(yīng)該是單機(jī)測試，引入不同的本地依賴項(xiàng)并測試不同組件如何相互交互。

· 很少有測試應(yīng)該跨遠(yuǎn)程計算機(jī)運(yùn)行，從而練習(xí)應(yīng)用程序的端到端流程。

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