介面測試入門介紹
從使用微信登入到滴滴平臺來打車，幾乎所有應用程式都依賴第三方 API 來實現某些功能。介面測試可能是軟體和質量檢查測試中最具挑戰性的部分之一，因為介面可能很複雜，它們通常基於協議和標準，而在其他型別的測試中我們通常不會遇到。
注：下面我會使用 API 來表示介面，是一個意思。
這篇文章將教你所有需要了解的有關 API 測試的資訊：
- 什麼是API測試及其重要性
- API測試型別
- 如何做API測試
- API 自動化
- API 測試工具
1.什麼是API測試及其重要性
API 是 應用程式程式設計介面的縮寫。它使開發人員可以將其他應用程式的功能整合到自己的產品中，而不必從頭開始構建它們。這意味著使用者可以通過微信登入到你的其他應用，比如在滴滴上打車去到他們想要的地方，並通過微信支付服務付款。所有這些都無需離開你的應用程式。
在傳統的三層體系結構中，API 代表應用程式的中間層。它們控制業務邏輯並連線其他兩層（GUI 和資料庫）。
過去，測試主要在 GUI 層進行，通過使用該應用程式的介面，測試人員可以發現其業務邏輯中的錯誤。但是要開始測試，他們必須等待開發人員完成 UI（也就是前端頁面）。這減慢了測試過程，並增加了修復錯誤的成本。
敏捷的開發和測試自動化使得這種方法越來越過時了。API 測試是在最關鍵的層上進行的：業務，在業務層中執行業務邏輯處理，並且在使用者介面和資料庫層之間進行所有事務，是一種軟體測試實踐，可以直接測試 API（從功能，可靠性，效能到安全性）。
綜上所述，API 測試的主要好處是：
1.早期測試
通過 API 測試，一旦設計了邏輯，就可以構建測試以驗證響應和資料的正確性。我們不必等待各個團隊完成工作或構建完整的應用程式-測試用例已隔離並且可以立即構建。
2.簡化測試維護
頁面會根據需求不斷的變更而 API 更改可以受到更多的控制且不經常發生，也方便測試迴歸。
3.提高測試效率
300個 UI 測試可能需要 30 個小時才能完成，而 3 分鐘內可以執行 300 個 API 測試。這意味著我們將在更短的時間內發現更多錯誤，同時也將立即修復它們，極大地提高整體測試策略的效率
4.更快的釋出
當 API 測試失敗時，我們確切地知道我們的系統在哪裡損壞以及在哪裡可以找到缺陷。這有助於減少構建，更快交付。
2.API 測試型別
根據測試範圍，我們可能需要執行各種測試。除了功能測試外，還可能需要執行安全性，迴歸，可靠性，異常和整合測試，這裡列舉常見的型別：
2.1 功能測試
功能測試可確保 API 正常執行，並且可以輕鬆整合到其他系統中。在功能測試中，你必須從使用者角度來檢查是否滿足要求，目的是確保系統可以正常處理所有可能的情況和錯誤。有一點：要記住新增斷言（例如，API應該返回正確的響應程式碼）。
正向流程測試之後，可以繼續進行反向流程或異常測試，目的是測試 API 如何響應錯誤的使用者輸入，並確保正確處理所有錯誤。
功能測試可以有：
2.1.1 元件測試（Component tests）
驗證 API 中可用的每種方法：
- 請求和響應的結構是否合理；
- API 返回適當的響應程式碼；
- 響應正文中包含的錯誤訊息是正確的；
- 輸出達到預期；
- API符合預期的響應時間。
元件測試也許是測試 API 的最重要部分，因為它們可以為所有後續測試奠定基礎。
2.1.2 場景測試（Scenario tests）
結合使用者使用場景，將各個元件組合到各種方案中，瞭解在每種特定情況下發出了哪些 API 請求。釋出 API 後，使用者可能會以意想不到的方式開始使用它，這可能會導致錯誤。因此，重要的是要測試 API 呼叫的組合。
如果有新功能，可以重新寫單個元件測試。
2.2 安全測試
測試安全性對於任何產品的成功都是至關重要的，因為被利用的漏洞很容易破壞產品的聲譽。為了保護你的應用程式安全，必須驗證訪問控制，使用者授權，敏感資料加密和其他安全要求。你可以使用現有的測試方案來發現攻擊媒介，並在滲透測試中模擬黑客攻擊。例如，可以將方案測試與 SQL 注入嘗試或引數模糊化結合起來。
3. 如何做API測試
API 測試流程非常簡單，只需三個主要步驟：
- 傳送帶有必要輸入資料的請求
- 獲取具有輸出資料的響應
- 驗證響應是否按要求返回
在開始測試 API 之前，你應該知道它們可以發出什麼樣的請求以及限制條件。這些在介面文件裡都可以找到，你也可以直接問開發人員，向他們詢問可用的端點，HTTP 方法及授權限制，必填欄位及其驗證限制，失敗/通過的請求的響應程式碼以及失敗的請求顯示的錯誤訊息。
現在，你可以設定一個環境，進行 API 呼叫並驗證響應。由於 API 沒有 GUI，因此必須在訊息傳遞級別進行測試。你可以直接傳送請求，但是有許多優秀的工具可以使 API 測試變得更加容易（稍後會詳細介紹）。輸入所需的 API 引數並配置資料庫和伺服器後，通過呼叫 API 檢查是否能調通。之後，就可以開始 API 測試了。
要了解 API 是否符合預期，必須編寫測試用例，其中包括：
- 輸入引數；
- 預期結果；
- 最長響應時間；
- 解析輸入；
- 錯誤處理；
- 正確格式化響應；
- 將每個測試用例新增到測試指令碼中，並在構建後執行。
4. 介面自動化
現在，比較少的團隊進行 API 測試的原因之一是根本沒有時間。隨著敏捷開發的發展，始終存在著加快交付產品的壓力。你可以花足夠的時間進行深度 API 測試的唯一方法是進行自動化，只需要編寫一次測試指令碼，然後在開發人員每次更改程式碼時自動執行它們。
自動化測試過程可以消除重複的任務，加快測試速度並增加覆蓋範圍。API 測試是自動化最有價值的領域之一。
但是，100％ 的 介面測試自動化並不具有成本效益。在測試自動化方面，並非系統的所有部分都具有同等的優先順序，知道哪些適合做介面自動化，哪些不適合做很重要。
下面是常見用來自動化的型別：
- 迴歸測試;
- 功能測試；
- 效能測試;
- 資料驅動的測試
當然，我們仍然需要手工測試，比如用在可用性測試、探索性測試等等。
5. API測試工具
有很多工具可以幫助你測試 API：
- Postman：谷歌提供的開源介面測試工具，支援 Http 介面的呼叫和驗證
- Jmeter：Apache 提供的開源介面測試工具，除了支援 Http 介面還有很多擴充套件功能(Mysql，Redis，RabbitMQ....)
- Fiddler：抓包工具，常用於介面分析
- HttpComponents：Apache提供的開源包，可以基於它實現介面程式碼的編碼
這裡簡單介紹一下 Postman：
Postman 是用於除錯和探索性測試的最受歡迎的工具之一，有超過500萬測試人員定期使用它。其實，開發人員用的更多。因為測試人員做介面測試會有更多選擇，例如 Jmeter、soapUI 等。
它是一個簡單的 REST 客戶端，以Chrome擴充套件程式和適用於 Windows，Linux 或 Mac 的桌面應用程式的形式提供。你可以免費下載它們或訂閱專業版。
與大多數類似工具不同，Postman 具有出色的 UI，對於那些不想陷入編碼困境的測試人員來說，這是一個絕佳的選擇。
你可以使用 Postman 的請求構建器獨立執行 API 測試，也可以建立多個測試的集合。Postman 支援簡單的知識共享和協作，也可以將 Postman 例項與 Jenkins 無縫整合，以建立自己的 CI / CD管道，也可以將其作為構建步驟新增到現有管道中。
結語
之後，我也會詳細介紹一些常用的介面測試工具，今天希望大家可以理解什麼是 API 以及什麼是 API 測試。如果沒有正確測試 API，可能會導致 API 應用程式出現問題，還會導致呼叫應用程式出現問題。它是軟體工程中必不可少的測試。