很不幸，自動化測試永遠只能是必要非充分條件

“ 對自動化測試的合理預期非常重要。”

—

關於自動化測試的爭論

關於自動化測試，一直是我們部門多年的痛。

我們的核心繫統是第三方的供應商系統，大量複雜的需求需要在這套系統上實現，而這些需求的開發週期長，各項目爲了能按自己的節奏開展，都要求供應商在各自的分支上進行開發。但是由於生產環境只有一套系統，這就不可避免要在上線前進行分支合併。

大家可以想象，這種大範圍的分支合併必然是高風險的，基於多年的經驗，我們對供應商的交付質量信心並不那麼放心，因此合併後的迴歸測試必不可少。

但是這種大規模的迴歸測試如果手工進行的話，則起碼需要耗時數週。因此，如何藉助自動化測試來加快這個過程，成爲一個重要議題。

然而，在我們的內部討論中，對於自動化測試的預期並沒有統一。

有人認爲，自動化測試就是把項目累積的人工功能測試全部自動化；有人認爲由於供應商系統對我們來說是黑盒子，我們只能通過調用UI來測試，但UI測試自動化成本高、執行時間長、脆弱，一味把所有功能測試自動化並不現實，即使花重金實現了，今後也會面臨執行週期長、維護成本高和測試結果不穩定等問題，應該只精選少量核心的測試用例進行自動化。

—

測試金字塔

其實關於自動化測試，業內早就總結出了測試金字塔原理。不同類型的自動化測試的執行速度和投入成本是不一樣的。

從上往下，最上層的UI測試，速度慢，容易因UI變動需要變更，只適合少量的測試用例。

大部分現代系統的設計都遵循MVC模型，也就是大部分的業務邏輯應該構建在後端，因此中間的服務層測試應該能覆蓋主要功能，而且服務層測試應該是通過調用接口來實現（調用Controller或API），測試速度遠比UI測試快，穩定性較UI測試高，接口變動頻率通常不太高，測試維護成本也比UI測試低。

最下層的單元測試成本最低，執行最快，應該高築牆、廣積糧。

然而我想強調的是，即使你按照測試金字塔構造了三層測試框架，你依然無法得到充分的測試覆蓋率。

“覆蓋率”最高的單元測試，雖然可以任由開發人員發揮，不斷增加邊界測試以覆蓋各種極端場景，但其針對的是代碼中的某個或某些方法，無法反映與用戶需求和功能直接相關的覆蓋關係。也就是說，高代碼覆蓋率的單元測試並不等同於系統整體的測試覆蓋情況。

服務層測試也無法模擬用戶真正使用系統時的場景。而且由於它的自動化投資相對單元測試高，執行速度較慢，對測試環境、環境數據也有要求，是比較重的測試過程。測試用例越多，投入越高，執行時間越長。我們投入測試自動化的原始目的，是爲了能夠得到快速反饋，如果反饋週期過長，就無法滿足這個目的。因此，服務層測試勢必只能選擇主要功能的測試用例。不可能也不應該做全覆蓋。

UI測試，前面已經說過，自動化成本高、執行時間長、脆弱，對測試環境、數據也是有嚴格要求，只能精選最核心幾個測試用例作爲冒煙測試。功能覆蓋率必然要低。

—

自動化測試只能是必要條件

綜上所述，我們對自動化測試的合理定位應該是，它只能是必要非充分條件，也就是說，自動化測試的結果只能反映這麼一個事實：測試失敗代表系統一定有問題，測試全部通過不能代表系統沒有問題。

只有理解和認可這樣的定位，才能對自動化測試做出合理的投資回報預期。要在這種限制條件下在測試用例選擇上做減法，選擇最重要的測試用例。

在自動化測試的基礎上，手工測試的補位依然不可或缺，兩者是互補的關係，而不是相互替代的關係。

因此，我的建議是：