資料結構
網路
關係型資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理
化學
生物
數學
英語
經濟學
心理學
社會學
時尚研究
法律研究API 測試教程 - 初學者指南
什麼是 API？
API（應用程式程式設計介面）是允許兩個不同的軟體系統進行通訊和共享資料的計算機介面。執行 API 的軟體系統具有許多功能/子程式，這些功能/子程式可以由另一個軟體系統執行。在兩個軟體系統之間，API 描述了可以發出的請求型別、如何發出請求、可以使用的資料格式等等。
左移測試
左移測試是現在 API 測試面試中最常見的問題之一。幾乎每個遵循敏捷方法的專案都包含這種形式的測試。
在引入左移測試之前，軟體測試僅在開發完成後並向測試人員提供程式碼後才進行。這種策略導致了最後一刻的匆忙以趕上截止日期，以及產品質量的顯著下降。
除此之外，所需的工作（當在生產前的最後階段發現錯誤時）是巨大的，因為開發人員必須重複設計和編碼階段。
API 測試包括什麼？
API 測試是一種軟體測試，它驗證應用程式程式設計介面 (API)。API 測試的目的是確保程式設計介面的功能、可靠性、速度和安全性。API 測試使用軟體來發出 API 呼叫、獲取輸出並記錄系統的響應，而不是使用典型的人工輸入（鍵盤）和輸出。API 測試不同於 GUI 測試，因為它不關注應用程式的外觀和感覺。它主要關注軟體架構的業務邏輯層。
API 自動化是指需要使用啟用 API 的應用程式的測試。要測試 API，您需要執行以下操作。
使用測試工具來驅動 API。
編寫自己的程式碼來測試 API。
您將在本 API 測試課程中瞭解有關以下內容的更多資訊。
API 測試環境設定
API 輸出的不同型別
API 測試用例是一組用於測試 API 的場景。
API 測試方法
API 測試和單元測試之間存在區別。
如何執行 API 測試
API 測試最佳實踐
透過 API 測試檢測到的錯誤型別
如何自動化 API 測試
API 測試挑戰
API 測試環境設定
API 測試與其他軟體測試方法的不同之處在於沒有 GUI，但您必須構建一個初始環境，該環境使用一組指定的引數執行 API，然後檢查測試結果。
因此，為 API 自動化測試設定測試環境似乎有點困難。
應設定資料庫和伺服器以滿足應用程式的需求。
安裝完成後，應使用 API 函式驗證 API 是否正常執行。
API 輸出的不同型別
API 輸出可能是 -
任何型別的資訊
當前狀態（例如透過或失敗）
呼叫另一個 API 函式。
在本 API 測試課程中，我們將檢視上述每種型別的示例。
任何型別的資訊
例如，有一個 API 方法可以新增兩個整數。
Long add(int a, int b)
必須將數字作為輸入引數輸入。最終結果應為兩個整數值的總和。必須將此輸出與預期結果進行比較。
需要進行以下呼叫，例如
add (1234, 5656)
如果數字超過整數限制，則必須處理異常。
當前狀態（例如透過或失敗）
檢視下面的 API 方法 -
Lock()
Unlock()
Delete()
它們可以返回任何結果作為輸出，例如 True（成功時）或 False（失敗時）。更精確的測試用例是在任何指令碼中執行函式，然後檢查資料庫或應用程式 GUI 中的變化。
正在呼叫另一個 API/事件。
在這種情況下，呼叫了其中一個 API 函式，然後該函式又呼叫了另一個函式。
例如，第一個 API 方法可用於從表中刪除特定記錄，然後此函式呼叫另一個函式來重新整理資料庫。
API 測試用例
API 測試用例基於
根據輸入條件返回的值：這很容易測試，因為可以描述輸入並驗證結果。
不提供任何資訊：當沒有返回值時，必須檢查系統的 API 行為。
啟用另一個 API/事件/中斷：如果 API 的輸出導致事件或中斷，則應監視事件和中斷偵聽器。
更新資料結構：更新資料結構將對系統產生影響或後果，應予以驗證。
修改特定資源：如果 API 請求更改了特定資源，則應透過訪問這些資源來檢查。
API 測試方法
API 測試方法是在構建完成後 QA 團隊將用於執行 API 測試的預定方法或技術。此測試不包括原始碼。API 測試方法有助於更好地理解功能、測試方法、輸入引數和測試用例執行。
以下幾點將幫助使用者實施 API 測試策略 -
瞭解 API 程式的功能並準確定義程式的範圍
使用等價類、邊界值分析和錯誤猜測等測試方法為 API 編寫測試用例。
必須仔細考慮和描述 API 的輸入引數。
執行測試場景並將預期結果與實際結果進行比較。
API 測試與單元測試
下表重點介紹了 API 測試和單元測試之間的主要區別 -
| 單元測試 | API 測試 |
|---|---|
| 由開發人員執行。 | 由測試人員執行。 |
| 對不同的函式進行測試。 | 從頭到尾測試功能。 |
| 開發人員可以訪問原始碼。 | 測試人員無法訪問原始碼。 |
| UI 測試也是流程的一部分。 | 僅對 API 函式進行測試。 |
| 僅測試最基本的功能。 | 徹底檢查所有功能問題。 |
| 範圍有限。 | 更廣泛的範圍 |
| 通常在簽入之前執行。 | 構建完成後執行。 |
如何執行 API 測試？
除了標準的 SDLC 流程之外，API 自動化測試還應至少包含以下測試方法。
**發現測試** - 測試組應手動執行 API 中定義的一組呼叫，例如確認 API 可訪問的給定資源可以根據需要列出、建立和銷燬。
**可用性測試** - 可用性測試確保 API 既實用又友好。以及 API 與其他平臺的互動效率如何？
**安全測試** - 安全測試涉及確定需要哪種形式的身份驗證以及敏感資料是否透過 HTTP 或兩者都加密。
**自動化測試** - API 測試應導致建立一組指令碼或工具，可用於定期執行 API。
**文件** - 測試團隊必須確保文件完整且足以與 API 互動。最終輸出應包括文件。
API 測試最佳實踐
API 測試用例應分類組織。
每個測試的頂部都應包含被呼叫的 API 的宣告。
測試用例中應明確說明引數的選擇。
對 API 函式呼叫進行優先順序排序，以便測試人員可以輕鬆地對其進行測試。
每個測試用例應儘可能獨立，並且沒有依賴項。
在您的開發中，避免“測試鏈”。
在使用一次性呼叫函式（如 Delete、CloseWindow 等）時，需要更加小心。
應執行並精心計劃呼叫順序。
為 API 的所有可能輸入組合建立 API 測試用例，以確保全面測試覆蓋率。
透過 API 測試檢測到的錯誤型別
無法優雅地處理錯誤情況
從未使用過的標誌
缺少或重複的功能
可靠性問題 連線到 API 並接收響應很困難。
安全問題
多執行緒問題
效能問題。API 響應時間非常長。
向呼叫方傳送不正確的錯誤/警告
錯誤處理有效的引數值
響應中的資料組織不正確（JSON 或 XML）
如何自動化 API 測試
後續課程提供逐步指南以實現 API 測試自動化。
REST Assured API 測試
如何使用 Postman 測試 API
如何使用 UFT 測試 API？
API 測試挑戰
API 測試有許多缺點，包括 -
引數組合、引數選擇和呼叫順序是 Web API 測試中的三個主要問題。
該程式沒有圖形使用者介面 (GUI) 用於測試，因此無法提供輸入資料。
測試人員在獨立的系統上驗證和確認結果比較困難。
測試人員必須瞭解引數選擇和分類。
需要測試異常處理方法。
測試人員需要具備編碼技能。
結論
業務邏輯層由 API 中的一組類、函式和方法表示。如果 API 未經充分測試，可能會在 API 應用程式和呼叫應用程式中都產生問題。在軟體工程中，測試是必不可少的。
8K+ 瀏覽量
