在前面的文章中，我介紹了為什麽要做自動化測試，以及什麽樣的項目適合做自動化測試，那麽現在我來說說軟件開發生命周期的各個階段都有哪些類型的自動化測試技術。

說到自動化測試，你可能最為熟悉的就是 GUI 自動化測試了。比如，早年的 C/S 架構，通常就是用自動化測試腳本打開被測應用，然後在界面上以自動化的方式執行一系列的操作；再比如，現今的 Web 站點測試，也是用自動化測試腳本打開瀏覽器，然後輸入要訪問的網址，之後用自動化腳本識別定位頁面元素，並進行相應的操作。

因此，說到自動化測試時，你的第一反應很可能就是 GUI 自動化測試。然而，在軟件研發生命周期的各個階段都有自動化測試技術的存在，並且對提升測試效率有著至關重要的作用。

今天這篇文章，我將會以不同的軟件開發階段涉及的自動化測試技術為主線，帶你了解單元測試、代碼級集成測試、Web Service 測試和 GUI 測試階段的自動化技術，希望可以幫助你更深入地理解“自動化測試”的內涵以及外延。

單元測試的自動化技術
首先，你可能認為單元測試本身就是自動化的，因為它根據軟件詳細設計采用等價類劃分和邊界值分析方法設計測試用例，在測試代碼實現後再以自動化的方式統一執行。

這個觀點非常正確，但這僅僅是一部分，並沒有完整地描述單元測試“自動化”的內涵。從廣義上講，單元測試階段的“自動化”內涵不僅僅指測試用例執行的自動化，還應該包含以下五個方面：

用例框架代碼生成的自動化；
部分測試輸入數據的自動化生成；
自動樁代碼的生成；
被測代碼的自動化靜態分析；
測試覆蓋率的自動統計與分析。
你可能感覺這些內容有些陌生，不過沒關系，下面我就詳細地跟你說說每一條的具體含義。

第一，用例框架代碼生成的自動化

有些框架代碼應該由自動化工具生成，而不是由開發者手工完成。這樣一來，單元測試開發者可以把更多的精力放在測試邏輯的覆蓋和測試數據的選擇上，從而大幅提高單元測試用例的質量和開發效率。

TestNG 框架代碼應該由自動化工具生成

第二，部分測試輸入數據的自動化生成

這部分是指，自動化工具能夠根據不同變量類型自動生成測試輸入數據。自動化工具本身不可能明白代碼邏輯，你可能很難理解它是如何根據需要測試的代碼邏輯生成合適的輸入數據，並且去判斷預計的測試結果的。那我給你舉個例子，你就很容易明白了。

比如，某個被測函數的原型是 void fun（int* p, short b），那麽測試數據自動生成技術就會為輸入參數 int* p 自動生成“空”和“非空”的兩個指針 p，然後分別執行函數 void fun（int* p, short b），並觀察函數的執行情況。

如果函數內部沒有對空指針進行特殊處理，那麽函數 fun 的調用必定會拋出異常，從而發現函數的設計缺陷。同樣地，對於輸入參數 short b 會自動生成超出 short 範圍的 b，測試函數 fun 的行為。

第三，自動樁代碼的生成

簡單地說，樁代碼（stub code）是用來代替真實代碼的臨時代碼。 比如，某個函數 A 的內部實現中調用了一個尚未實現的函數 B，為了對函數 A 的邏輯進行測試，那麽就需要模擬一個函數 B，這個模擬的函數 B 實現就是所謂的樁代碼。

自動樁代碼的生成是指自動化工具可以對被測試代碼進行掃描分析，自動為被測函數內部調用的其他函數生成可編程的樁代碼，並提供基於測試用例的樁代碼管理機制。此時，單元測試開發者只需重點關註樁代碼內的具體邏輯實現，以及樁代碼的返回值。

必要的時候，自動化工具還需要實現 “抽樁”，以適應後續的代碼級集成測試的需求。

那什麽是“抽樁”呢？其實也很簡單，在單元測試階段，假如函數 A 內部調用的函數 B 是樁代碼，那麽在代碼級集成測試階段，我們希望函數 A 不再調用假的函數 B，而是調用真實的函數 B，這個用真實函數 B 代替原本樁代碼函數 B 的操作，就稱為“抽樁”。

第四，被測代碼的自動化靜態分析

靜態分析主要指代碼的靜態掃描，目的是識別出違反編碼規則或編碼風格的代碼行。通常這部分工作是結合項目具體的編碼規則和編碼風格，由自動化工具通過內建規則和用戶自定義規則自動化完成的。目前比較常用的代碼靜態分析工具有 Sonar 和 Coverity 等。

嚴格意義上講，靜態分析不屬於單元測試的範疇，但這部分工作一般是在單元測試階段通過自動化工具完成的，所以我也把它歸入到了單元測試自動化的範疇。

第五，測試覆蓋率的自動統計與分析

單元測試用例執行結束後，自動化工具可以自動統計各種測試覆蓋率，包括代碼行覆蓋率、分支覆蓋率、MC/DC 覆蓋率等。這些自動統計的指標，可以幫你衡量單元測試用例集合的充分性和完備性，並可以為你提供適當增補測試用例以提高測試覆蓋率的依據。

代碼級集成測試的自動化技術
通俗地講，代碼級集成測試是指將已經開發完成的軟件模塊放在一起測試。

從測試用例設計和測試代碼結構來看，代碼級集成測試和單元測試非常相似，它們都是對被測試函數以不同的輸入參數組合進行調用並驗證結果，只不過代碼級集成測試的關註點，更多的是軟件模塊之間的接口調用和數據傳遞。

代碼級集成測試與單元測試最大的區別只是，代碼級集成測試中被測函數內部調用的其他函數必須是真實的，不允許使用樁代碼代替，而單元測試中允許使用樁代碼來模擬內部調用的其他函數。

以上的這些異同點就決定了代碼級集成測試“自動化”的內涵與單元測試非常相似，尤其是在實際操作層面，比如測試用例的設計方法、測試用例的代碼結構以及數據驅動思想的應用等等。

但是，代碼級集成測試對測試框架的要求非常高，這個框架除了可以順利裝載自己的軟件模塊外，還必須能裝載其他相互依賴的模塊，做到被測軟件模塊可運行（Runnable）。

由於代碼級集成測試主要應用在早期非互聯網的傳統軟件企業，那時候的軟件以“單體”應用居多，一個軟件內部包含大量的功能，每一個軟件功能都是通過不同的內部模塊來實現的，那麽這些內部模塊在做集成的時候，就需要做代碼級集成測試。

現在的開發理念追求的是系統復雜性的解耦，會去盡量避免“大單體”應用，采用 Web Service 或者 RPC 調用的方式來協作完成各個軟件功能。所以現在的軟件企業，尤其是互聯網企業，基本不會去做代碼級集成測試，我在這裏也就不再進一步展開了。

Web Service 測試的自動化技術
Web Service 測試，主要是指 SOAP API 和 REST API 這兩類 API 測試，最典型的是采用 SoapUI 或 Postman 等類似的工具。但這類測試工具基本都是界面操作手動發起 Request 並驗證 Response，所以難以和 CI/CD 集成，於是就出現了 API 自動化測試框架。

如果采用 API 自動化測試框架來開發測試用例，那麽這些測試用例的表現形式就是代碼。為了讓你更直觀地理解基於代碼的 API 測試用例是什麽樣子的，我給你舉一個“創建用戶”API 的例子，你只需要看代碼的大致步驟就可以了，具體到每行代碼的含義，我會在後續文章中詳細講解。

基於 API 自動化測試框架的測試用例示例（測試 CreateUser API）

對於基於代碼的 API 測試用例，通常包含三大步驟：

準備 API 調用時需要的測試數據；
準備 API 的調用參數並發起 API 的調用；
驗證 API 調用的返回結果。
目前最流行的 API 自動測試框架是 REST Assured，它可以方便地發起 Restful API 調用並驗證返回結果。關於 REST Assured 的用法和優點，我會在後續文章中詳細介紹。

同樣地，Web Service 測試“自動化”的內涵不僅僅包括 API 測試用例執行的自動化，還包括以下四個方面：

測試腳手架代碼的自動化生成；
部分測試輸入數據的自動生成；
Response 驗證的自動化；
基於 SoapUI 或者 Postman 的自動化腳本生成。
接下來，我會依次為你解釋這 4 個方面代表什麽含義。

第一，測試腳手架代碼的自動化生成
和單元測試階段的用例框架代碼自動生成一個道理，你在開發 API 測試的過程中更關心的是，如何設計測試用例的輸入參數以及組合，以及在不同參數組合情況下 Response 的驗證，而你不希望將精力浪費在代碼層面如何組織測試用例、測試數據驅動如何實現等非測試業務上。

這時，測試腳手架代碼的自動生成技術就派上用場了。它生成的測試腳手架代碼，通常包含了被測試 API 的調用、測試數據與腳本的分離，以及 Response 驗證的空實現。

第二，部分測試輸入數據的自動生成

這一點和單元測試的測試輸入數據的自動化生成也很類似，唯一不同的是，單元測試針對的參數是函數輸入參數和函數內部輸入，而 API 測試對應的是 API 的參數以及 API 調用的 Payload。數據生成的原則同樣遵循邊界值原則。

第三，Response 驗證的自動化

對於 API 調用返回結果的驗證，通常關註的點是返回狀態碼（status code）、Scheme 結構以及具體的字段值。如果你寫過這種類型的測試用例，那你就會知道字段值的驗證相當麻煩，只有那些你明確寫了 assert 的字段才會被驗證，但是通常你不可能針對所有的字段都寫 assert，這時就需要 Response 驗證的自動化技術了。

Response 驗證自動化的核心思想是自動比較兩次相同 API 調用的返回結果，並自動識別出有差異的字段值，比較過程可以通過規則配置去掉諸如時間戳、會話 ID（Session ID）等動態值。 這部分內容，我會在後續文章中詳細講解。

第四，基於 SoapUI 或者 Postman 的自動化腳本生成

你在使用 SoapUI 或者 Postman 等工具進行 Web Service 測試時，已經在這些工具裏面積累了很多測試用例。那麽，在引入了基於代碼實現的 API 測試框架之後，就意味著需要把這些測試用例都用代碼的方式重寫一遍，而這額外的工作量是很難被接受的。

我的建議是，開發一個自動化代碼轉換生成工具。這個工具的輸入是 SoapUI 或者 Postman 的測試用例元數據（即測試用例的 JSON 元文件），輸出是符合 API 測試框架規範的基於代碼實現的測試用例。這樣一來，原本的測試用例積累可以直接轉換成在 CI/CD 上可以直接接入的自動化測試用例。

對於新的測試用例，還可以繼續用 SoapUI 或者 Postman 做初步的測試驗證，初步驗證沒有問題後，直接轉換成符合 API 測試框架規範的測試用例。對於復雜的測試用例，也可以直接基於代碼來實現，而且靈活性會更好。

GUI 測試的自動化技術
GUI 測試的自動化技術可能是你最熟悉的，也是發展時間最長、應用最廣的自動化測試技術。它的核心思想是，基於頁面元素識別技術，對頁面元素進行自動化操作，以模擬實際終端用戶的行為並驗證軟件功能的正確性。

目前，GUI 自動化測試主要分為兩大方向，傳統 Web 瀏覽器和移動端原生應用（Native App）的 GUI 自動化。雖然二者采用的具體技術差別很大，但是用例設計的思路類似。

對於傳統 Web 瀏覽器的 GUI 自動化測試，業內主流的開源方案采用 Selenium，商業方案采用 Micro Focus 的 UFT（前身是 HP 的 QTP）；
對於移動端原生應用，通常采用主流的 Appium，它對 iOS 環境集成了 XCUITest，對 Android 環境集成了 UIAutomator 和 Espresso。
這部分內容，我會在後續的文章中詳細展開。

總結
軟件研發生命周期各個階段的自動化測試技術，包括單元測試、代碼級集成測試、Web Service 測試和 GUI 測試的自動化技術，並歸納了每一類技術的核心方法和應用場景。

希望你通過這篇文章，可以先對自動化測試的全局有一個比較清晰的認識，然後在後續的文章中我還會針對這些技術展開討論，並給你分享一些相應的實際案例。

軟件開發階段涉及到的自動化測試技術---打卡第五天