【51CTO.com快譯】從基本概念上說，API的作用是：通過任何形式的通信手段，促進兩種不同應用程序之間實現交互。例如，在Web應用上所使用到的API，我們往往稱之為“Web服務”。如今，隨著應用技術的進步和種類的增多，API已經成為了編程代碼中的重要組成部分。在開發各種應用項目時，編程人員往往會通過使用API來與數據庫或其他的模塊進行通信。這就是為什么作為測試人員的我們，必須通過測試API，以求獲得最大的測試覆蓋率(test coverage)的原因。

而作為集成測試的一部分，API自動化可以協助加速測試的進程并提高效率。由于目前大多數公司都在業務層面上使用到了RESTful微服務和API，因此對于API的測試已經成為了任何發布測試計劃中的關鍵環節之一。

簡單來說，API實際是一種服務，它可以幫助兩種不同的應用程序實現順暢的相互通信。大多數API被用于抽象各種業務邏輯，并引導到應用程序訪問其對應的數據庫。

從邏輯上講，我們可以將整個軟件系統分為三個層次：

1. 表示層 - 這是展示給最終用戶的某個用戶界面(GUI)。質量保證人員(Quality Assurance，QA)對于該層次進行功能測試。

2. 業務層 - 這是通過編寫邏輯代碼，來實現各種應用的用戶接口。就實現技​​術而言，各類代碼和算法屬于在這個層面上。當然API也處于這個層次。

3. 數據庫層 - 存儲的是應用程序的各種數據信息。

換句話說，API是軟件互聯世界的中樞神經。它通過運用各種工具、協議、標準和代碼集，將數字世界“粘合”在一起。由于API不但動態靈活，而且功能強大，因此它讓各種軟件產品更為簡便、更具有移動性，不同組件能夠以一種無縫集成的方式進行協同運作。那么，針對API的測試則可以從服務級別和集成級別兩個方面進行展開。

API的測試策略

就不同人員的關注點而言，開發人員一般傾向于只測試他們正在開發的軟件功能;一般測試人員則只負責做功能性的單元測試、以及端到端的協同測試。然而在如今DevOps的持續開發與測試環節中，測試人員更應該專注于在軟件使用過程中所進行的各種API調用，以便觀察和記錄在系統做出響應之前所接收的不同輸出。而且，其中最重要的是：應測試API在不同條件下是否能返回正確的響應或輸出值。一般而言，此類輸出可以被分為如下三類：

• 通過(成功)或失敗狀態
• 數據或信息
• 調用另一個API

當然，也可能根本沒有任何輸出、或發生了完全不可預測的結果。因此，測試人員就要在整個應用程序的開發過程中起到關鍵性的作用，他們需要通過數據驅動型測試，來提高整體測試的覆蓋率和準確性。

API測試的類型

正如我們通常需要根據目標產品具有哪些功能，提前設定好進行何種類型的測試一樣，測試人員往往也需要首先確定好將在API上執行哪種類型的測試。如下是常見的API測試種類：

• 單元測試 - 測試單個操作的功能。例如，Google地圖通過提供地理編碼類型的API，以獲取任意位置的經度和緯度。其后臺實際上是將地址信息作為輸入，并返回緯度和經度的數值。那么在針對該API的單元測試中，測試人員可以通過輸入不同的位置信息來驗證其各種輸出結果。
• 功能測試 - 此類測試主要關注于API的本身功能，即：通過各種測試用例，來驗證HTTP響應的程序代碼、響應的準確性、API可能返回的任何錯誤代碼等方面。
• 負載測試 – 在有多個用戶同時使用某個應用程序，并引發了API需要處理大量數據的情況下，此類測試是必需的。它通過增加API的調用頻率，以暴露可能出現的崩潰、或無法“承壓”等狀況。
• 安全測試 - 由于API會被用于在兩個不同的應用程序之間創建連接，而使用API​​的核心目的就是為了將某個應用程序的數據庫相對于另一個進行抽象或隱藏，因此安全測試尤為重要。測試用例一般包括：授權檢查、會話管理等方面。
• 互操作性測試 – 此類測試的目的是保證API能夠被應用程序按需訪問到，例如SOAP API就屬于此類。
• WS(Web Service)合規性測試 – 在對于API的測試過程中，我們應當確保諸如：WS-Addressing、WS-Discovery、WS-Federation、WS-Policy、WS-Security和WS-Trust等標準能夠被正確地采用和實施。
• 滲透測試 - 這是從外部攻擊源來查找API的漏洞。

Web服務與API協議

上面我們提到了Web服務，它主要是由兩種類型的服務(或稱為協議)所組成：

REST(Representational State Transfer) - 是一種輕量級的協議，它使用URL來獲取所有需要的信息。與下面將要介紹的SOAP相比，它不但更新了、而且克服了SOAP上存在的所有問題。REST使用如下四種HTTP方法來執行各項任務：

1. Get - 獲取信息。例如，在位置映射的API中獲取經度和緯度的信息。

2. Post - 在資源中插入一些數據。

3. Put - 更新目標資源。

4. Delete - 從資源中進行刪除。

由于其架構簡單且輕巧，因此REST如今已被廣為使用。

SOAP(Simple Object Access Protocol) API - 它使用XML來進行消息交換。而執行該任務所需的所有信息，都是由Web服務描述語言(Web Service Description Language，WSDL)所給定的。SOAP的擴展性和與XML相關的標準性，造成了SOAP相對來說比較“重”。而它相比REST的優勢在于：它具有內置的錯誤處理功能，并且可以與其他協議(如SMTP)協同使用。

API的測試步驟

市面上有許多針對API的測試工具。在測試人員接手API之初，他們應當先參考其相應的文檔，以判定目標是屬于REST、還是SOAP API、或者它根本就不是基于Web的API，這些詳細的信息都應當被記錄在配套的文檔之中。因此，API的測試基本流程為：

1. 參考文檔(上面已經提及)

2. 先編寫功能性、或服務級別的相關用例

3. 編寫各種集成測試

4. 在API足夠穩定、且完成了上述的測試步驟之后，我們可以開始進行安全、性能和負載類型的測試。

具體說來，我們可以按照如下的順序進行：

1. 典型的API文檔一般會包含與API相關的所有信息，其中包括：請求的格式、響應的類型、錯誤的代碼、用到的資源、必需的參數、可選的參數、headers等方面。而對于這類文檔，我們則可以使用諸如開源的swagger、Dapperdox和ReDoc等工具來進行日常維護。

2. 之后我們就可以著手為API編寫服務級別的測試用例了。例如，如果某個API使用了n個參數來獲取響應，其中m是必要參數，而其他都是可選參數，那么其對應的測試用例應該去嘗試不同的參數組合，以驗證各種響應結果。而另一種測試用例則可能需要驗證headers;和在不啟用身份驗證的情況下運行API，以檢驗其產生的錯誤代碼。

3. 接下來便是集成測試的步驟了。您需要測試目標API的所有依賴項、及其功能。同時，我們還可能需要測試該API的各種響應，從其他API、或方法處預計返回的數據，以及該API在失效時的各種狀態與輸出信息。

4. 一旦目標API的表現穩定、并完成了所有功能性的測試，那么測試人員就可以開始進行與負載、安全和性能相關的各種深度測試了。

API自動化測試工具

如今隨著DevOps的盛行，我們通常在每次進行發布之前，都可能需要對一些測試用例，如回歸用例，執行重復性的測試。因此，這就需要測試人員實現一些自動化的任務。

市面上有許多針對API自動化的工具，我們在此列舉幾個典型的：

• SOAP UI - 這是一款非常流行的API測試工具。您可以使用SoapUI來對目標API執行功能性、負載性、安全性和合規性等測試。
• Katalon Studio - 建立在Selenium和Appium基礎之上的Katalon Studio，是一款免費的、且功能強大的自動化測試工具。它能夠被用于執行Web測試、API測試和移動測試。
• Postman - Postman是一款免費的工具。您可以使用它來高效地開發和測試目標API的所有功能。
• Jmeter - 雖然測試人員主要會將Jmeter用于性能和負載方面的測試，但它在很大程度上也是可以被用到API的功能測試環節中。
• RestAssured – RestAssured實際上是一個基于Java的庫，因此它可以被用于測試各種基于RESTful的Web服務。您可以將該庫包含在現有框架中，直接調用其對應的方法，以獲取JSON格式的響應，并最終執行各種所需的操作。

下面，我將通過一個實例來詮釋API功能測試所需要遵循的基本步驟。在該示例中，我使用的是由CloudQA所提供的一款較為新穎且流行的工具--TruAPI。

步驟1

為了產生一個API請求，您首先需要選擇一種Method Type，并在此粘貼目標API的URL。您既可以按下發送按鈕，將請求發送到給目標API;也可以按下Add API Test按鈕，以保存該請求：

為了方便看到效果，您可以試著使用如下Method Type和API URL：

• Method Type: GET
• API URL: https://um5fdww2pj.execute-api.us-east-1.amazonaws.com/dev/todos

第2步 - API的請求信息：

• 大多數API都需要一些額外的輸入，才能執行對應的請求。諸如：參數、Headers、Body(JSON)等。
• 因此，為了給請求添加各項參數，您可以選擇相應的Parameters選項卡，然后點擊“Add Parameter”按鈕，以添加所需的信息。

第3步 - 使用身份驗證發送API請求：

• 如果您的目標API需要身份驗證的話，您可以選擇Authorization選項卡，從下拉列表中選擇BasicAuth(其默認設置為Noauth)，然后輸入用戶名和密碼，那么您就可以發送帶有身份驗證的請求了。

• 相對應地，每個API的響應也都包含不同的值，例如：狀態代碼、body、headers、以及完成API請求的時間。下面，我們來對API的響應進行詳細討論。

添加斷言(Assertions)：

在自動化過程中，使用斷言來驗證各種輸出是非常重要的。如果您想在API Runner中添加斷言，那么請選擇Assertions選項卡。在此，您可以添加一到多個斷言。

下面是添加斷言的簡單步驟：

1. 選擇響應類型

2. 選擇斷言的條件

3. 輸入需要檢查的值

4. 完成斷言的添加

變量：

Variables選項卡可以被用于存儲那些根據API請求所產生的響應接收值。如果您想保存各種響應，請選擇Variables選項卡，然后按照以下步驟進行操作：

1. 添加變量

2. 為變量命名，以便其他團隊容易理解

3. 輸入來自響應body并存儲著數值的JSON路徑

4. 如果您想將變量中的存儲值用作預期的斷言，則可以在任何其他API的請求中使用變量：_name

查看或執行某個已保存的API請求：

• 您可以在API Runner頁面上，使用View Saved Tests按鈕，來查看各種已保存的測試。
• 選中一到多個已保存的API測試，并默認運行它們。這些測試會顯示上一次執行后的運行狀態信息。
• 而結果將顯示在API執行歷史的記錄中。

上面我們介紹的只是一個單獨的API執行與自動化。而在真實的場景中，我們經常需要創建包含所有回歸測試用例在內的API套件，并將其作為回歸測試的一部分來運行。在敏捷開發的理念中，準備好相應的套件是至關重要的，只有這樣才能更好地與持續集成/持續交付(CI/CD)進行整合。

另外，CloudQA附帶有豐富的說明文檔。而且CloudQA提供的所有工具都是與“無代碼自動化(Codeless automation)”的理念相一致的。這也就方便了那些手動測試人員的使用。詳細文檔，請參見：https://doc.cloudqa.io/TruAPI.html。

原文標題：The Know-Hows of API Testing，作者：Ruchira Shukla

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】