以有意義的方式了解API測試可以釋放創(chuàng)建真正有效的測試策略的能力。在本指南中，了解什么是API測試，包括許多不同類型的API測試，以確保您知道如何有效地進行API測試。

在最近的部署中，當(dāng)我被問到“什么是API測試？”時，我正與客戶一起制定API測試策略。那時我意識到，描述API測試令人驚訝地具有挑戰(zhàn)性，即使您確實描述了它，也往往聽起來很無聊和復(fù)雜。

好吧，我在這里告訴您API測試并不乏味或復(fù)雜。它實際上非常有趣且功能強大，以有意義的方式理解它可以釋放創(chuàng)建真正有效的測試策略的能力。要真正了解如何進行API測試，請繼續(xù)閱讀。

什么是API，如何使用？

在服務(wù)開發(fā)中，應(yīng)用程序接口（API）是各種應(yīng)用程序使用通常由協(xié)議定義的通用語言相互通信的一種方式。這些示例是用于RESTful服務(wù)的Swagger文檔或用于SOAP服務(wù)的WSDL。甚至數(shù)據(jù)庫都有接口語言，即SQL。

API就像UI允許人類與應(yīng)用程序交互的方式一樣，使機器之間能夠高效地進行通信。

API之所以出色，是因為它們代表了構(gòu)建塊，開發(fā)人員可以使用它們輕松地組裝各種交互，而不必在每次需要機器進行通信時都重寫接口。另外，由于API具有協(xié)議，因此只要彼此之間按照API協(xié)議進行通信，就可以以完全不同的方式構(gòu)建希望相互通信的應(yīng)用程序。這使來自世界各地的不同組織的不同開發(fā)人員可以創(chuàng)建高度分布的應(yīng)用程序，同時可以重復(fù)使用相同的API。

當(dāng)用戶與應(yīng)用程序（即移動應(yīng)用程序）的前端進行交互時，該前端對后端系統(tǒng)進行API調(diào)用，從而通過兩種主要方式簡化了開發(fā)過程：

• 開發(fā)人員不必擔(dān)心為每個移動設(shè)備或瀏覽器制作定制的應(yīng)用程序。

• 可以更新或修改不同的后端系統(tǒng)，而不必每次都重新部署整個應(yīng)用程序。

結(jié)果，開發(fā)人員可以通過將單個服務(wù)集中于完成離散任務(wù)來節(jié)省時間，而不必花費時間將邏輯寫入其應(yīng)用程序。

標(biāo)準(zhǔn)API使用的一個很好的例子

亞馬遜購物服務(wù)的文檔化API使開發(fā)人員可以在創(chuàng)建應(yīng)用程序時與亞馬遜購物進行交互。開發(fā)人員可以在其用戶體驗的適當(dāng)時間使用Amazon API，以創(chuàng)建無縫的客戶旅程。

例如，這可能看起來像這樣：

用戶與用戶界面進行交互，而應(yīng)用程序與開發(fā)人員定義的后端Amazon API進行交互。只要基礎(chǔ)API的行為符合預(yù)期，一切就可以很好地工作。

……但是如果很大的話。

因此，我們得出了測試這些API的重要性。

什么是API測試？

那么如何執(zhí)行API測試？這意味著什么？如何進行API測試？與僅在UI級別與應(yīng)用程序進行交互的用戶不同，開發(fā)人員/測試人員必須確保任何和所有基礎(chǔ)API的可靠性。如果不對API本身進行測試，則開發(fā)人員和測試人員將被困于手動測試，就像用戶在UI級別上對應(yīng)用程序進行測試一樣，等到整個應(yīng)用程序堆棧都已構(gòu)建之后才能開始測試。

相反，您可以通過在API級別上測試應(yīng)用程序，設(shè)計與基礎(chǔ)API直接交互的測試用例并獲得眾多優(yōu)勢（包括在易于自動化的層中測試業(yè)務(wù)邏輯的能力）來執(zhí)行自動化API測試。穩(wěn)定的態(tài)度。與手動測試（僅限于驗證特定的用戶體驗）不同，API測試使您能夠針對未知情況對應(yīng)用程序進行防彈。

如何進行API測試？

不同類型的API測試-位置，原因和方式

進行API測試的最佳方法是從下至上構(gòu)建可靠的測試實踐。為此，一種設(shè)計測試策略的好方法是遵循Martin Fowler的測試金字塔。金字塔方法建議您在具有UI測試的單元測試的堅實基礎(chǔ)之上，構(gòu)建各種API測試（例如，協(xié)議、方案、性能等）。API測試允許您在單元測試無法達到的水平上測試應(yīng)用程序邏輯。

這些測試策略是互補的。在應(yīng)用程序的較低層進行更早的測試，可以幫助您“快速失敗并盡早失敗”，盡早在源頭而不是在SDLC中發(fā)現(xiàn)缺陷。單元測試很重要，但是目前我們專注于API測試。您如何測試APIS？可以進行哪些測試？他們?yōu)槭裁粗匾咳绾芜M行API測試？

您如何使用API？

下一節(jié)將介紹不同類型的API測試，包括在何處/為什么/如何使用它們。

協(xié)議測試

API表示2個或更多應(yīng)用程序之間的協(xié)議。協(xié)議描述了如何與接口交互，可用的服務(wù)以及如何調(diào)用它們。該協(xié)議很重要，因為它是溝通的基礎(chǔ)。如果協(xié)議有問題，那么別的什么都沒有。

API測試的第一個也是最基本的類型是協(xié)議測試，它測試服務(wù)協(xié)議本身（Swagger，PACT，WSDL或RAML）。這種類型的測試可以驗證協(xié)議是否正確編寫，并且可以由客戶使用。該測試通過創(chuàng)建一系列可以拉入?yún)f(xié)議并驗證以下條件的測試來工作：

• 服務(wù)協(xié)議是按照規(guī)范寫的

• 消息請求和響應(yīng)在語義上是正確的（模式驗證）

• 端點有效（HTTP，MQ / JMS主題/隊列等）

• 服務(wù)協(xié)議沒有改變

我認為這些是您的第一個“煙霧測試”。如果這些測試失敗，則實際上沒有理由繼續(xù)測試該特定服務(wù)。如果這些測試通過，則可以繼續(xù)測試API的實際功能。

組件測試

組件測試就像API的單元測試一樣-您想采用API中可用的各個方法，并分別測試其中的每個方法。通過對服務(wù)協(xié)議中可用的每種方法或資源執(zhí)行測試步驟來創(chuàng)建這些測試。

創(chuàng)建組件測試的最簡單方法是消耗服務(wù)協(xié)定，并讓它創(chuàng)建客戶端。然后，您可以使用正負數(shù)據(jù)對每個單獨的測試用例進行數(shù)據(jù)驅(qū)動，以驗證返回的響應(yīng)具有以下特征：

• 請求有效載荷格式正確（模式驗證）

• 響應(yīng)有效載荷格式正確（模式驗證）

• 響應(yīng)狀態(tài)符合預(yù)期（200 OK，返回了SQL結(jié)果集，如果您要這樣做，甚至出現(xiàn)錯誤）

• 響應(yīng)錯誤有效負載包含正確的錯誤消息

• 響應(yīng)與預(yù)期的基線匹配。這可以采取兩種形式：

• 回歸/差異–響應(yīng)有效負載在每次調(diào)用之間看起來完全相同（自上而下的方法，實際上是您捕獲響應(yīng)的快照并每次都對其進行驗證）。這也可能是識別API更改的重要催化劑（稍后會詳細介紹）。
  斷言–響應(yīng)中的各個元素都符合您的期望（這是針對響應(yīng)中特定值的更外科，自下而上的方法）。

• 服務(wù)在預(yù)期的時間內(nèi)響應(yīng)

這些單獨的API測試是您可以構(gòu)建的最重要的測試，因為它們將在所有后續(xù)測試技術(shù)中得到利用。當(dāng)您可以在以后所有不同類型的測試中簡單地引用這些單獨的API調(diào)用時，為什么還要重建測試用例？這不僅提高了一致性，而且簡化了進行API測試的過程。

場景測試

大多數(shù)人在考慮API測試時都會想到場景測試。在這種測試技術(shù)中，您將各個組件測試組裝成一個序列，就像我上面為Amazon服務(wù)描述的示例一樣。

獲取序列有兩種很棒的技術(shù)：

• 查看用戶故事，以識別正在進行的各個API調(diào)用。

• 練習(xí)UI并捕獲對基礎(chǔ)API的流量。

通過場景測試，您可以了解是否可能通過將不同的數(shù)據(jù)點組合在一起而引入缺陷。

與客戶合作時，我遇到了一個非常有趣的示例。他們采用了一系列服務(wù)來呼叫客戶的財務(wù)資料，可用帳戶，信用卡和最近的交易。這些API調(diào)用中的每個調(diào)用都是單獨工作的，但是當(dāng)您按順序將它們放在一起時，它們就會開始失敗。造成這種情況的原因是一個簡單的時間戳，從一個API調(diào)用返回時，它的格式與后續(xù)請求中期望的格式不同。他們在進行單元測試或冒煙測試時沒有意識到這一點，因為他們斷言返回時間戳?xí)r未指定格式。直到測試整個場景后，才可以清楚地發(fā)現(xiàn)，將時間戳從一個呼叫轉(zhuǎn)移到另一個呼叫會導(dǎo)致故障。

場景測試的另一個好處是，當(dāng)您以未預(yù)期的方式使用API時，可以驗證預(yù)期的行為。發(fā)布API時，您將向世界提供一系列構(gòu)建模塊。您可能具有將這些塊組合在一起的規(guī)定技術(shù)，但是客戶可能會有無法預(yù)料的需求，并且意外地將API組合在一起以暴露應(yīng)用程序中的缺陷。為了防止這種情況，您想使用API的不同組合創(chuàng)建許多方案測試，以使應(yīng)用程序免受重大故障的影響。

由于組件測試構(gòu)成了場景測試的基礎(chǔ)，因此組織通常擁有大量的場景測試。它們是在引入新功能以模擬客戶使用新功能的旅程時構(gòu)建的。這樣一來，您確實可以減少測試時間，因為您只需要為新功能構(gòu)建測試，并且您知道自己擁有可靠的基礎(chǔ)測試庫來捕獲任何意外情況。

性能測試

在特定于性能的測試環(huán)境中，性能測試通常會降級到測試過程的結(jié)尾。這是因為性能測試解決方案往往很昂貴，需要專門的技能，并且需要特定的硬件和環(huán)境。這是一個大問題，因為API具有必須滿足的服務(wù)級別協(xié)議（SLA），才能發(fā)布應(yīng)用程序。如果您等到最后一刻進行性能測試，則無法滿足SLA可能會導(dǎo)致巨大的發(fā)布延遲。

在流程的早期進行性能測試，可以使您在運行完整的回歸周期之前發(fā)現(xiàn)與性能相關(guān)的問題。如果您到目前為止一直遵循測試過程，那么實際上將非常容易，因為您擁有執(zhí)行性能測試所需的所有基礎(chǔ)測試用例。您可以簡單地進行場景測試，將其加載到性能測試工具中，然后以更多的用戶數(shù)量運行它們。如果這些測試失敗，則可以將失敗的原因追溯到各個用戶，并更好地了解將受到的影響。然后，管理人員可以利用這種了解來決定是否發(fā)布應(yīng)用程序。

安全測試

安全測試對組織中的所有利益相關(guān)者都很重要。如果暴露并利用了安全漏洞，則可能導(dǎo)致嚴重的聲譽損失和財務(wù)損失。就像用戶會意外地使用您的API一樣，用戶也可能有意嘗試利用您的API。黑客可以掌握您的API，發(fā)現(xiàn)漏洞并加以利用。

為了防止此類行為，您需要構(gòu)建測試案例以嘗試執(zhí)行這些類型的惡意攻擊。您可以利用現(xiàn)有的測試用例來執(zhí)行此操作，因為方案測試可以將攻擊向量提供給應(yīng)用程序。然后，您可以重新使用此攻擊媒介來發(fā)起滲透攻擊。一個很好的例子是將不同類型的參數(shù)模糊測試或SQL注入攻擊與方案測試結(jié)合在一起。這樣，通過應(yīng)用程序傳播的任何更改都將由您的安全測試選擇。要了解有關(guān)API安全測試的更多信息，請查看同事的有用的博客文章。

全渠道測試

由于應(yīng)用程序與之交互的多個接口（移動，Web，API，數(shù)據(jù)庫等），如果單獨測試其中的任何一個，您將遇到測試覆蓋率的空白，而忽略了這些接口之間復(fù)雜的交互的精妙之處。

全渠道測試通過將API和數(shù)據(jù)庫測試交織到移動和Web UI交互的驗證中，全面覆蓋了應(yīng)用程序的許多界面，以確保徹底覆蓋測試范圍。這意味著要進行一個正在使用其中一個接口并與另一個接口進行協(xié)調(diào)的測試-執(zhí)行Web（Selenium）或Mobile（Appium）之類的UI測試，并將它們與您的API或數(shù)據(jù)庫測試中的任何一個交織在一起，從系統(tǒng)通過測試執(zhí)行。借助有效的全渠道測試，您可以創(chuàng)建穩(wěn)定、可重用的測試案例，這些案例可以輕松實現(xiàn)自動化。

管理變更

更改是應(yīng)用程序風(fēng)險的最重要指標(biāo)之一。變更可以多種形式發(fā)生，包括：

• 服務(wù)的協(xié)議消息格式更改

• 從API添加或刪除的元素

• 底層代碼更改會影響返回的數(shù)據(jù)格式

• 重新架構(gòu)服務(wù)以將其分解為多個部分（隨著組織轉(zhuǎn)向微服務(wù)，這種情況極為普遍）

發(fā)生更改時，您需要構(gòu)建測試用例以識別更改并提供補救計劃。使用提供分析以解決這些更改的影響的解決方案，將使您了解發(fā)生了什么更改并確定受影響的特定測試的目標(biāo)。

然后可以以模板的形式捕獲更改，以使用新功能更新任何基礎(chǔ)組件或方案測試。由于其余測試引用了這些測試，因此更改的影響將減少。

總結(jié)

建立可靠的自動化API測試策略是確保您的應(yīng)用程序“今天和昨天一樣工作”的最佳方法（不僅僅是一個容易理解的短語）。API測試允許您構(gòu)建一個可靠的框架來識別應(yīng)用程序多層中的缺陷。這些測試可以全部自動化并且可以連續(xù)運行，因此您可以確保應(yīng)用程序符合業(yè)務(wù)期望，同時功能也精確。由于API測試的工作水平遠低于UI測試的水平，因此您知道您將具有一致性，并且所構(gòu)建的測試將持續(xù)很長時間。

準(zhǔn)備開始API測試，但需要弄清楚要使用什么工具？前往我們的免費指南，了解如何為您的組織選擇最佳的API測試解決方案。