4.3　運用綜合手段保證質量和安全

我們前面講過，源代碼改動發生后的軟件交付過程，主要包括三類事情：一是各種類型的檢查、測試和反饋，以保證質量和安全；二是改動的合并匯聚；三是軟件形態的轉換，即將源代碼編譯構建為安裝包，經過部署，轉換為軟件系統運行起來。若論所需的時間和精力，其中第一類事情是最大頭。接下來就圍繞著第一類事情來講“運用綜合手段保證質量和安全”這個策略。

4.3.1　各種各樣的測試

為方便起見，我們把代碼改動發生后進行的各種類型的檢查、測試和反饋，統稱為“測試”。各種各樣的測試，用來發現軟件中的缺陷，以及穩定性、可靠性、安全性等方面的問題，也用來發現軟件與產品設計不相符的情況，并探測用戶是不是喜歡。下面我們來看看這個廣義的測試具體包括哪些測試方法。

首先，它包括我們平常說的測試，也就是程序運行起來的測試，比如單元測試、集成測試、系統測試等。同時它也包括無須程序運行，直接對源代碼或安裝包進行的靜態檢查，比如代碼掃描、代碼評審等。

其次，它既包括人工測試，比如人工的UI測試，也包括自動化測試，比如自動化接口測試。并且，測試不僅可以發生在測試環境下，也可以在生產環境中做測試，比如生產環境的全鏈路壓測、混沌工程、灰度發布、A/B測試等。

最后，雖然構建、部署活動不是以測試為主要目的的，但是從測試的角度來看，它們仍然屬于某種測試：測試程序能不能構建，測試程序能不能部署。此外，生產環境部署過程本身，可以采用灰度發布、藍綠部署等方式來降低風險。嚴格地講，這也屬于測試。

這么多種測試手段，我們該怎么選用呢？核心思路是，根據實際情況，綜合運用多種手段：一是在合適的時機做合適的測試，不能一味地強調測試左移或測試右移；二是并非所有的事情都應該分派給測試人員或者開發人員；三是自動化測試并不能完全取代人工測試。接下來我們進行詳細分析。

4.3.2　左移+右移

我們先來看在合適的時機做合適的測試。

有些測試很“便宜”，可以早早地做、反復做、經常做，所發現的問題可以很快得到修復。但這樣仍然會有不少漏網之魚。那些“貴”一些的測試，則可以進一步找出問題，當然，發現問題的代價和修復問題的代價都要大一些。還有些測試，必須搭一個測試環境來做，不僅太“貴”了，而且效果可能也不好，所以干脆到線上去做。

一會兒說測試左移，也就是盡量寫完代碼就測試；一會兒又說測試右移，跑到線上去做。其實它們并不矛盾，這正是體現了不同的測試手段都有相應的使用時機、場合和策略。

4.3.3　測試人員+開發人員

測試該由誰來做呢？對源代碼本身的檢查當然由開發人員來做，也就是代碼評審甚至結對編程。那把軟件運行起來之后做的測試呢？一般來說，越是專業能力的測試，就越是傾向于由測試人員來編寫和執行，比如探索性測試、安全方面的測試等。而越是與編程實現相關，對系統結構中某個組件甚至某個函數和類進行的測試，就越是傾向于由開發人員來編寫和執行，比如單元測試、對單個接口的自動化測試等。

4.3.4　人工測試+自動化測試

自動化測試并不能完全取代人工測試。一般認為單元測試、接口測試是可以完全自動化執行的。而自動化的代碼掃描盡管可以發現不少問題，但不能完全取代人工的代碼評審。人工的探索性測試也沒法自動化完成。一般來說，需要反復執行的、檢查判斷有明確標準和規則的測試適合自動化完成，然而并非所有的測試都是如此。

自動化測試要根據實際情況，逐步將自動化的比重和測試覆蓋率提高到一個合理的范圍內，還要按不同的測試類型，比如單元測試、對單個接口的自動化測試、接近端到端的自動化接口測試、自動化UI測試等分別考查，確定自動化的比重和測試覆蓋率多大，確定對于特定場景來說是否合理。

4.3.5　綜合運用

這么多種測試手段，不是必須要全部用上。流程設計得簡單點兒還是復雜點兒，每個活動要做得多么深入、全面，也需要根據系統/產品/模塊的具體情況來定。總體來說，越是對質量要求高的產品和服務、越是復雜的緊密耦合的系統，就越是需要步驟多一些的流程，流程中的每一件事情就越是需要嚴防死守，深入、全面地做。反之，就可以簡單點兒做，抓重點做。

應該為不同的測試手段各分配多少力氣，這個話題通常被稱為測試分層策略。測試分層策略有理想主義的金字塔模型、更務實的橄欖球模型等。而在整個開發、集成發布流程中，何時該做哪種測試、以什么頻率測試、如何進行質量卡點，則是集成發布策略的一部分。