【收藏】什麼是API測試？這是我見過的最全的測試指南！

在最近的部署中，當我被問到「什麼是API測試？」時，我正與客戶一塊兒制定API測試策略。那時我忽然意識到，要描述API測試竟然是一件如此具備挑戰性的事情，即便你如實地描述了它，也每每聽起來很無聊和複雜。

好吧，容我在這裏告訴你，API測試並不乏味或複雜。它實際上很是有趣且功能強大，換一種思路和方式來理解它，能夠釋放你建立真正有效的測試策略的能力。要真正瞭解如何進行API測試，請繼續閱讀。

什麼是API，如何使用？

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

API就像UI容許人類與應用程序交互的方式同樣，使機器之間可以高效地進行通訊。

API之因此出色，是由於它們表明了構建塊，開發人員可使用它們輕鬆地組裝各類交互，而沒必要在每次須要機器進行通訊時都重寫接口。另外，因爲API具備協議，所以只要彼此之間按照API協議進行通訊，就能夠以徹底不一樣的方式構建但願相互通訊的應用程序。這使來自世界各地的不一樣組織的不一樣開發人員能夠建立高度分佈的應用程序，同時能夠重複使用相同的API。

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

1. 開發人員沒必要擔憂爲每一個移動設備或瀏覽器製做定製的應用程序。
2. 能夠更新或修改不一樣的後端系統，而沒必要每次都從新部署整個應用程序。

結果，開發人員能夠經過將單個服務集中於完成離散任務來節省時間，而沒必要花費時間將邏輯寫入其應用程序。

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

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

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

用戶體驗	對應的API調用
1.搜索優質的視頻遊戲	1. SearchItems
2.亞馬遜建議使用Minecraft	2. GetItems
3.將Minecraft添加到個人購物車	3. AddToCart

 

用戶與用戶界面進行交互，而應用程序與開發人員定義的後端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服務描述的示例同樣。

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

1. 查看用戶故事，以識別正在進行的各個API調用。
2. 練習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測試解決方案。