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

而作為集成測試的一部分，API自動化可以協(xié)助加速測試的進(jìn)程并提高效率。由于目前大多數(shù)公司都在業(yè)務(wù)層面上使用到了RESTful微服務(wù)和API，因此對于API的測試已經(jīng)成為了任何發(fā)布測試計劃中的關(guān)鍵環(huán)節(jié)之一。

簡單來說，API實際是一種服務(wù)，它可以幫助兩種不同的應(yīng)用程序?qū)崿F(xiàn)順暢的相互通信。大多數(shù)API被用于抽象各種業(yè)務(wù)邏輯，并引導(dǎo)到應(yīng)用程序訪問其對應(yīng)的數(shù)據(jù)庫。

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

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

2. 業(yè)務(wù)層 - 這是通過編寫邏輯代碼，來實現(xiàn)各種應(yīng)用的用戶接口。就實現(xiàn)技​​術(shù)而言，各類代碼和算法屬于在這個層面上。當(dāng)然API也處于這個層次。

3. 數(shù)據(jù)庫層 - 存儲的是應(yīng)用程序的各種數(shù)據(jù)信息。

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

API的測試策略

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

• 通過(成功)或失敗狀態(tài)
• 數(shù)據(jù)或信息
• 調(diào)用另一個API

當(dāng)然，也可能根本沒有任何輸出、或發(fā)生了完全不可預(yù)測的結(jié)果。因此，測試人員就要在整個應(yīng)用程序的開發(fā)過程中起到關(guān)鍵性的作用，他們需要通過數(shù)據(jù)驅(qū)動型測試，來提高整體測試的覆蓋率和準(zhǔn)確性。

API測試的類型

正如我們通常需要根據(jù)目標(biāo)產(chǎn)品具有哪些功能，提前設(shè)定好進(jìn)行何種類型的測試一樣，測試人員往往也需要首先確定好將在API上執(zhí)行哪種類型的測試。如下是常見的API測試種類：

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

Web服務(wù)與API協(xié)議

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

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

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

2. Post - 在資源中插入一些數(shù)據(jù)。

3. Put - 更新目標(biāo)資源。

4. Delete - 從資源中進(jìn)行刪除。

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

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

API的測試步驟

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

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

2. 先編寫功能性、或服務(wù)級別的相關(guān)用例

3. 編寫各種集成測試

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

具體說來，我們可以按照如下的順序進(jìn)行：

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

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

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

4. 一旦目標(biāo)API的表現(xiàn)穩(wěn)定、并完成了所有功能性的測試，那么測試人員就可以開始進(jìn)行與負(fù)載、安全和性能相關(guān)的各種深度測試了。

API自動化測試工具

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

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

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

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

步驟1

為了產(chǎn)生一個API請求，您首先需要選擇一種Method Type，并在此粘貼目標(biāo)API的URL。您既可以按下發(fā)送按鈕，將請求發(fā)送到給目標(biāo)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的請求信息：

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

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

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

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

添加斷言(Assertions)：

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

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

1. 選擇響應(yīng)類型

2. 選擇斷言的條件

3. 輸入需要檢查的值

4. 完成斷言的添加

變量：

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

1. 添加變量

2. 為變量命名，以便其他團(tuán)隊容易理解

3. 輸入來自響應(yīng)body并存儲著數(shù)值的JSON路徑

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

查看或執(zhí)行某個已保存的API請求：

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

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

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

原文標(biāo)題：The Know-Hows of API Testing，作者：Ruchira Shukla

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