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

創(chuàng)新互聯(lián)一直秉承“誠(chéng)信做人，踏實(shí)做事”的原則，不欺瞞客戶，是我們最起碼的底線！ 以服務(wù)為基礎(chǔ)，以質(zhì)量求生存，以技術(shù)求發(fā)展，成交一個(gè)客戶多一個(gè)朋友！為您提供成都網(wǎng)站制作、成都網(wǎng)站建設(shè)、成都網(wǎng)頁(yè)設(shè)計(jì)、小程序開發(fā)、成都網(wǎng)站開發(fā)、成都網(wǎng)站制作、成都軟件開發(fā)、重慶APP軟件開發(fā)是成都本地專業(yè)的網(wǎng)站建設(shè)和網(wǎng)站設(shè)計(jì)公司，等你一起來(lái)見(jiàn)證！

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

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

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

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

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

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

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

API的測(cè)試策略

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

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

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

API測(cè)試的類型

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

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

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

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

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

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

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

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

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

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

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

API的測(cè)試步驟

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

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

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

3. 編寫各種集成測(cè)試

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

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

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

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

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

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

API自動(dòng)化測(cè)試工具

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

市面上有許多針對(duì)API自動(dòng)化的工具，我們?cè)诖肆信e幾個(gè)典型的：

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

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

步驟1

為了產(chǎn)生一個(gè)API請(qǐng)求，您首先需要選擇一種Method Type，并在此粘貼目標(biāo)API的URL。您既可以按下發(fā)送按鈕，將請(qǐng)求發(fā)送到給目標(biāo)API;也可以按下Add API Test按鈕，以保存該請(qǐng)求：

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

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

第2步 - API的請(qǐng)求信息：

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

第3步 - 使用身份驗(yàn)證發(fā)送API請(qǐng)求：

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

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

添加斷言(Assertions)：

在自動(dòng)化過(guò)程中，使用斷言來(lái)驗(yàn)證各種輸出是非常重要的。如果您想在API Runner中添加斷言，那么請(qǐng)選擇Assertions選項(xiàng)卡。在此，您可以添加一到多個(gè)斷言。

下面是添加斷言的簡(jiǎn)單步驟：

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

2. 選擇斷言的條件

3. 輸入需要檢查的值

4. 完成斷言的添加

變量：

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

1. 添加變量

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

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

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

查看或執(zhí)行某個(gè)已保存的API請(qǐng)求：

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

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

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

分享名稱：API測(cè)試全接觸：策略、類型、步驟和自動(dòng)化測(cè)試工具
標(biāo)題來(lái)源：http://uogjgqi.cn/article/ccehsce.html