API（應用程序編程接口）測試是一種直接在API級別執行驗證的軟件測試。它是集成測試的一部分，它確認API是否滿足測試人員對功能、可靠性、性能和安全性的期望。與UI測試不同，API測試是在沒有GUI層執行操作的。
API測試技巧
Web API有兩大類Web服務：SOAP和REST。SOAP（簡單對象訪問協議）是W3C標准定義的一種標准協議，用於發送和接收Web服務請求和響應。REST（表示狀態傳輸）是使用HTTP的基於Web標准的體系結構。與基於SOAP的Web服務不同，沒有針對RESTful Web API的正式標准。
以下是API測試的10條基本技巧：
了解API要求
在測試API之前，需要回答以下問題以徹底了解API的要求：
- API的功能是什么？業務流程是什么？使用場景是什么？
通常，應用程序的API用於對資源進行操作。它們常用於讀取，創建，更新。了解API的用途將為輸入和輸出准備好測試數據奠定堅實的基礎。此步驟還可以幫助您定義驗證方法。例如，對於某些API，您將針對數據庫驗證響應。對於其他一些，最好根據其他API來驗證響應。
例如，“創建用戶” API的輸出將是“獲取用戶” API的輸入以進行驗證。“獲取用戶” API的輸出可以用作“更新用戶” API的輸入，依此類推。
指定API輸出狀態
您需要在API測試中驗證的最常見的API輸出是響應狀態代碼。
新API測試人員熟悉驗證響應代碼是否等於200以確定API測試是通過還是失敗。這不是錯誤的驗證。但是，它並不反映API的所有測試方案。
在通用標准中，所有API響應狀態代碼均分為五類。狀態碼的第一位數字定義響應的類別。后兩位沒有任何類別或分類作用。
第一位數有五個值：
- 1xx（信息性）：收到請求並繼續進行處理
- 2xx（成功）：成功接收，理解並接受了請求
- 3xx（重定向）：需要采取進一步的措施來完成請求
- 4xx（客戶端錯誤）：請求包含錯誤的語法或無法實現
- 5xx（服務器錯誤）：服務器無法滿足看似有效的請求
API的實際響應狀態代碼由構建API的開發團隊指定。
專注於小型功能性API
在測試項目中，總是有一些簡單的API，只有一個或兩個輸入，例如登錄API，獲取身份令牌API，運行狀況檢查API等。但是，這些API是必需的，被視為進入其他業務的“門API”。首先關注這些API，將確保API服務器，環境和身份驗證正常工作。
還應該避免在一個測試案例中測試多個API。如果發生錯誤，這是很痛苦的，因為您將不得不按順序調試API生成的測試數據。保持測試盡可能簡單。在某些情況下，如果需要調用一系列API來實現端到端測試流程，這些任務應該在所有API都經過單獨測試之后完成。
分類API
一個測試項目可能有幾個甚至數百個用於測試的API。強烈建議將它們分類，以更好地進行測試管理。它需要采取額外的步驟，但是將大大幫助您創建具有高覆蓋率和集成度的測試方案。
同一類別的API共享一些公共信息，例如資源類型，路徑等。以相同的結構組織測試將使您的測試在集成流程中可重復使用和擴展。
利用自動化功能進行API測試
盡可能早地利用自動化進行API測試。以下是自動化API測試的一些重要好處：
- 測試數據和執行歷史記錄可以與API信息一起保存。這使得以后重新運行測試變得更加容易。
- API測試穩定且較少更改。API反映了系統的業務規則。API的任何更改都需要明確的要求；因此，測試人員始終可以及時了解更改並進行調整。
- 與Web UI測試相比，測試執行速度要快得多
- API測試被視為灰盒測試，用戶可以在其中發送輸入數據並獲取輸出數據以進行驗證。數據驅動方法的自動化（即在同一測試場景中應用不同的數據集）可以幫助增加API測試覆蓋率
- 數據輸入和輸出遵循某些特定的模板或模型，因此您只能創建一次測試腳本。這些測試腳本也可以在整個測試項目中重復使用
- API測試可以在軟件開發生命周期的早期進行。具有模擬技術的自動化方法可以幫助在開發實際的API之前驗證API及其集成。因此，減少了團隊內部的依賴性。
選擇合適的自動化工具
利用API測試的自動化功能的另一步驟是從市場上的數百種選擇中選擇最合適的工具或一組合適的工具。選擇API自動測試工具時，應考慮以下一些標准：
- 該工具是否支持測試您的AUT（被測應用程序）正在使用的API / Web服務類型？如果您在AUT使用SOAP服務時所選的工具支持測試RESTful服務，則沒有任何意義。
- 該工具是否支持您的AUT服務所需的授權方法？以下是您的API可以使用的一些授權方法：No Auth、Bearer Token、Basic auth、Digest Auth、NTLM Authentication、OAuth 1.0、OAuth 2.0、Hawk Authentication、AWS Signature。這是一項必不可少的任務，因為你無法在未經授權的情況下開始測試API。
- 該工具是否支持從WSDL，Swagger，WADL和其他服務規范中導入API / Web服務端點？這是一項可選功能。但是，如果您要測試數百個API，這一點非常重要。
- 該工具是否支持數據驅動的方法？這也是一項可選功能。
- 最后但並非最不重要的一點是，除了API測試之外，您是否還需要執行其他類型的測試，例如WebUI或數據源？API測試在數據源和UI之間的業務層執行。所有這些層都必須進行測試是正常的。支持所有測試類型的工具將是理想的選擇，這樣您的測試對象和測試腳本可以在所有層之間共享。
選擇合適的驗證方法
當響應狀態代碼告訴請求狀態時，響應主體內容就是API通過給定輸入返回的內容。API響應內容因數據類型和大小而異。響應可以是純文本，JSON數據結構，XML文檔等。它們可以是簡單的幾個單詞的字符串（甚至為空），也可以是一百頁的JSON/XML文件。因此，必須為給定的API選擇合適的驗證方法。
通常，有一些驗證API響應正文內容的基本方法：
- 將整個響應正文內容與預期信息進行比較，此方法適用於具有靜態內容的簡單響應。日期時間，增加的ID等動態信息會在斷言中引起麻煩。
- 比較響應的每個屬性值，對於JSON或XML格式的響應，很容易獲得給定鍵或屬性的值。因此，此方法在驗證動態內容或單個值而不是整個內容時很有用。
- 比較匹配與正則表達式，與驗證單個屬性值一起，此方法用於驗證具有特定模式的數據響應以處理復雜的動態數據。
每種驗證方法都有其優點和缺點，並且沒有“一刀切”的選項，需要選擇最適合您的測試項目的解決方案。
創建正面和負面的測試
API測試需要正向測試和反向測試，以確保API正常運行。由於API測試被視為一種灰盒測試，因此兩種類型的測試均由輸入和輸出數據驅動。
正向測試
- 驗證API是否已接收輸入並按要求中指定的那樣返回預期的輸出。
- 驗證是否按要求指定返回了響應狀態代碼，無論它返回的是2xx還是錯誤代碼。
- 用最小的必填字段和最大的字段指定輸入。
反向測試
- 當預期的輸出不存在時，請驗證API是否返回了適當的響應。
- 執行異常輸入驗證測試。
- 使用不同的授權級別驗證API的行為。
現場測試流程
建議在測試過程中安排每天的API測試執行。由於API測試執行快速，穩定且足夠小，因此很容易以最小的風險將更多測試添加到當前測試過程中。這只有通過具有以下功能的自動API測試工具才能實現：
- 使用內置測試命令進行測試計划
- 與測試管理工具和缺陷跟蹤工具集成
- 與各種領先的CI工具進行持續集成
- 可視日志報告生成
測試過程完成后，每天都可以得到這些測試的結果。如果發生失敗的測試，則可以立即檢查輸出並驗證問題以找到適當的解決方案。
不要小看API自動化測試
API測試流程非常簡單，只需三個主要步驟：
- 發送帶有必要輸入數據的請求
- 獲取具有輸出數據的響應
- 驗證響應是否按要求返回
API測試最重要的部分既不是發送請求也不是接收響應。它們是測試數據管理和驗證。通常，測試一些第一個API（例如登錄，查詢一些資源等）非常簡單。因此，API測試任務很容易被低估。在常規手段方法無法達到你的目的時，使用編程技能可以極大拓展API測試的邊界。
- 鄭重聲明：文章首發於公眾號“FunTester”，禁止第三方（騰訊雲除外）轉載、發表。
技術類文章精選
- java一行代碼打印心形
- Linux性能監控軟件netdata中文漢化版
- 性能測試框架第二版
- 如何在Linux命令行界面愉快進行性能測試
- 圖解HTTP腦圖
- 將swagger文檔自動變成測試代碼
- 基於java的直線型接口測試框架初探
- Selenium 4.0 Alpha更新日志
- Selenium 4.0 Alpha更新實踐
- 如何統一接口測試的功能、自動化和性能測試用例