通過測試程式或工具模擬客戶端向伺服器傳送請求報文，伺服器接收請求報文後對相應的報文做出處理然後再把應答報文傳送給客戶端，客戶端接收應答報文這一過程（request→response）
介面測試常用工具：postman，jmeter （現在主流的兩個測試介面工具）
1.更早地發現問題： 測試應該更早地介入到專案開發中，因為越早地發現bug，修復的成本越低。然而功能測試必須等到系統提供可測試的介面才能對系統進行測試。而介面測試可以在功能介面開發出來之前對系統進行測試。系統介面是上層功能的基礎，介面測試可以更早更低成本地發現和解決問題。
2.縮短產品研發週期： 對於產品研發週期來說，如果將所有測試工作都集中在功能測試階段，那麼測試的問題和修復週期就會變長。因為測試可以更早地介入產品開發中，所以，可以有效地控制功能階段bug的數量；從而有效地縮短產品開發周期。
3.發現更底層的問題： 系統的有些底層邏輯是在ui功能測試中不太容易觸發的，那麼這些邏輯可能會存在問題。介面測試可以更容易更全面的測試到這些底層的邏輯。
4.檢查伺服器的異常處理能力： 我們通常把前端的驗證稱為弱驗證，因為它很容易被繞過，這個時候如果只站在功能的層面進行測試，就很難發現一些安全的問題。
介面分類 ：
把介面分為兩類：程式介面和協議介面。
1.程式介面，也可以看作是程式模組介面，具體到程式中一般就是提供了輸入輸出的類、方法或函式。 對於程式介面的測試，一般需要使用與開發程式介面相同的程式語言，通過不同的傳入不同的引數，來驗證 程式介面的功能。
2.協議介面，一般指系統通過不同的協議來提供的介面，例如 http/soap 協議等。這種型別介面對 底層**做了封裝，通過協議的方式對外提供呼叫。因為不涉及到程式層面，所以，不受程式語言的限制； 我們可以通過其它程式語言或工具對其進行測試。
了解系統及內部各個元件之間的業務邏輯互動；
了解介面的i/o（input/output：輸入輸出）；
了解協議的基本內容，包括：通訊原理、三次握手、常用的協議型別、報文構成、資料傳輸方式、常見的狀態碼、url構成等；
常用的介面測試工具，比如：jmeter、loadrunner、postman、soapui等；
資料庫基礎操作命令（檢查資料入庫、提取測試資料等）；
常見的字元型別，比如：char、varchar、text、int、float、datatime等；
介面測試的資料準備，可以從下面幾個方面去考慮：
1、如果是只測試一次的介面，可以使用硬編碼的方式準備測試資料，在寫測試**的時候，使用到什麼資料就寫什麼資料，為了避免資料重複，可能比較多的會用到隨機字元或隨機數
2、可以直接通過呼叫其他api的方式準備測試資料，這種情況在測試最上層服務的時候比較有用，比如測試**購買服務，就需要準備要購買的**資料，購買**的使用者資料，這個時候，可以直接呼叫生產**的api和生成使用者的api直接生成測試資料
3、使用excel或xml準備測試資料，這種準備測試資料的方式，主要針對物件資料的準備，比如可以將一條**資料對應excel中的一條資料，因為一般開發都會使用pojo對映，而在準備測試資料的時候，這些pojo物件屬性的設定往往是重複和大工作量的，用excel或xml方式準備，則可以減少在**當中重複去準備這些資料。
4、也可以使用工具方法的形式去準備測試資料，通過在**中寫工具方法去實現資料生成，而在測試**中呼叫
工具方法去得到所需資料介面測試的著眼點：
1、檢查介面返回的資料是否與預期的結果一致。
2、檢查介面的容錯性，假如傳遞資料的型別錯誤時是否可以處理。例如上面的例子是支援整數，傳遞的是小數或字串呢？
3、介面引數的邊界值。例如，傳遞的引數足夠大或為負數時，介面是否可以正常處理。
4、介面的效能，介面處理資料的時間也是測試的乙個方面。牽扯到內部就是演算法與**的優化。
5、介面的安全性，如果是外部介面的話，這點尤為重要。
介面測試用例設計：
介面測試用例的設計方法其實和功能測試用例的設計方法是類似的，因為介面是需要滿足需求的，而介面測試所依賴的也是需求說明書，但是，因為介面測試畢竟是通過**去測試**，所以，為了保證覆蓋率，可能會使用到單元測試的方法，具體的測試用例設計如下：輸入引數測試：
1、針對輸入的引數進行測試，也可以說是假定介面引數的不正確性進行的測試，確保介面對任意型別的輸入都做了相應的處理：輸入引數合法，輸入引數不合法，輸入引數為空，輸入引數為null，輸入引數超長；
3、邏輯測試：邏輯測試嚴格講應為單元測試，單元測試應保持內部邏輯的正確性，可單元測試和介面測試界限並不是那麼清楚，所以我們也可以從給出的設計文件中考慮內部邏輯錯誤的分支情況和異常；
4、異常情況測試：介面實現是否對異常情況都進行了處理，介面輸入引數雖然合法，但是在介面實現中，也會出現異常，因為內部的異常不一定是輸入的資料造成的，而有可能是其他邏輯造成的，程式需要對任何的異常都進行處理。
(1) 開發提供需求文件（介面文件應該包括完整的功能介面、介面請求方式、介面請求url、介面請求引數、介面返回資料）
(2) 需求分析與評審
(3) 編寫測試用例
(4) 搭建環境
(5) 執行測試用例
(6) bug提交與跟蹤
(7) 回歸測試
(8) 編寫測試報告
(1) 必需引數覆蓋。對於介面的引數，介面文件一般都會說明哪些兒是必需的，哪兒是非必需的。對於必需的引數，一定要測試傳引數和不傳引數介面是否報錯？
(2) 必需的引數各種情況覆蓋。傳非法的字元，特殊的字元，空值，超過邊界的引數是否報錯？錯誤資訊是否正確？
(3) 非必需引數覆蓋。一般介面對於非必需引數都不會做非正常性傳值的判斷，所以要測試合法的引數值 ，介面返回的內容是否正確。如果有介面文件說明對非必需引數做了非正常的驗證的話，也要對其進行驗證。
(4) 引數的組合覆蓋。有些兒引數需要相互配合著才起作用，如"offset"和"count"組合起來進行翻頁，這個時候要組合起來進行測試。
(5) 業務邏輯相關的覆蓋。有些兒介面與業務邏輯關聯密切，單獨從介面角度測試，可能會遺漏掉一些兒因業務邏輯而產生的bug。所以如果和業務邏輯相關，也要考慮到業務邏輯相關的測試用例。
介面測試 介面文件規範
介面測試的依據，往往不是需求文件，而是介面文件。介面文件不管以什麼形式存在，需要包含的內容有 介面名稱 介面型別 輸入引數 每個引數名 每個引數型別 每個引數業務含義 每個是否可空 每個字段長度 可選，一般需要提供，有嚴格要求的字段需特別註明 每個引數的單位 可選，金額類字段需註明 d.輸出結果 每...
SPI介面詳細介紹
1.概述 spi serial peripheral inte ce，是序列外圍裝置介面，是一種高速，全雙工，同步的通訊匯流排。常規只占用四根線，節約了晶元管腳，pcb的布局省空間。現在越來越多的晶元整合了這種通訊協議，常見的有eeprom flash ad轉換器等。支援全雙工，push pull的...
介面文件生成詳細教程
介面文件是乙個專案開發中必需的說明文件，但時介面文件編寫起來比較費事費力。本文為大家推薦一款特別好用的介面文件生成工具 apipost apipost是一款國產的介面測試和介面文件生成的工具。其中它介面文件生成的功能特別強大。開啟apipost編寫乙個登入的介面請求 它這裡有兩個功能，成功響應示例及...