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

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

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

什么是API，如何使用？

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

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

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

當用戶與應用程序（即移動應用程序）的前端進行交互時，該前端對后端系統進行API調用，從而通過兩種主要方式簡化了開發過程：

• 開發人員不必擔心為每個移動設備或瀏覽器制作定制的應用程序。

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

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

標準API使用的一個很好的例子

亞馬遜購物服務的文檔化API使開發人員可以在創建應用程序時與亞馬遜購物進行交互。開發人員可以在其用戶體驗的適當時間使用Amazon API，以創建無縫的客戶旅程。

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

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

……但是如果很大的話。

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

什么是API測試？

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

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

如何進行API測試？

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

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

這些測試策略是互補的。在應用程序的較低層進行更早的測試，可以幫助您“快速失敗并盡早失敗”，盡早在源頭而不是在SDLC中發現缺陷。單元測試很重要，但是目前我們專注于API測試。您如何測試APIS？可以進行哪些測試？他們為什么重要？如何進行API測試？

您如何使用API？

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

協議測試

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

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

• 服務協議是按照規范寫的

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

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

• 服務協議沒有改變

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

組件測試

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

創建組件測試的最簡單方法是消耗服務協定，并讓它創建客戶端。然后，您可以使用正負數據對每個單獨的測試用例進行數據驅動，以驗證返回的響應具有以下特征：

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

• 響應有效載荷格式正確（模式驗證）

• 響應狀態符合預期（200 OK，返回了SQL結果集，如果您要這樣做，甚至出現錯誤）

• 響應錯誤有效負載包含正確的錯誤消息

• 響應與預期的基線匹配。這可以采取兩種形式：

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

• 服務在預期的時間內響應

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

場景測試

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

獲取序列有兩種很棒的技術：

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

• 練習UI并捕獲對基礎API的流量。

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

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

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

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

性能測試

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

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

安全測試

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

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

全渠道測試

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

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

管理變更

更改是應用程序風險的最重要指標之一。變更可以多種形式發生，包括：

• 服務的協議消息格式更改

• 從API添加或刪除的元素

• 底層代碼更改會影響返回的數據格式

• 重新架構服務以將其分解為多個部分（隨著組織轉向微服務，這種情況極為普遍）

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

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

總結

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

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