什么是接口？
接口就是有特定輸入和特定輸出的一套邏輯處理單元，而它不用知道自身的內部實現邏輯，也可以叫做接口的黑盒處理邏輯
由於服務對象不同，接口又可以分為兩種
- 一種是系統或服務的內部接口
- 一種是外部依賴接口
內部接口
系統內部調用的接口
內部接口的實際場景
購物流程，從登錄系統，到加入購物車，再到支付訂單，這一長串的流程中，都是通過系統內部接口來完成的
外部接口
外部系統對外提供的接口
外部接口的實際場景
你在購物后點擊付款時，頁面會跳轉到支付系統，等你完成支付流程后，再跳轉回訂單頁，在這樣的流程中，都會涉及系統對外的接口，還比如說付款工程的支付接口、配送過程的物流接口等等
接口的本質
其實就是一種契約，遵循這樣一種形式：在開發前期，我們約定接口會接收什么數據；在處理完成后，它又會返回什么數據
什么是接口測試？
接口測試，其實就是驗證接口內部處理邏輯是否正確；我們既要保證單接口的正確性，也要保證接口的業務邏輯正確性，主要體現在兩方面：
- 輸入正確的測試數據，驗證接口正常處理后返回的結果是否正確（數據結構&數據內容）
- 輸入異常的測試數據，驗證接口能否正確處理異常數據並返回特定提示，是否合理，是否健壯
簡單來說
- 正確接受合法 Request 入參
- 正確拒絕非法 Request 入參
這兩種情況都是要驗證的，都屬於正向測試
反向測試
- 正向測試相對應的是反向測試
- 反向測試是指：測試流程的反向測試或者是功能的反向測試，這是一個在業務測試里的概念，例如：支付付款是正向測試，那么退款是反向測試
為什么說接口測試如此重要？
從它對項目的影響來說，接口測試直接測試后端服務，更加接近服務器上運行的代碼程序，也更能發現影響范圍廣泛的 Bug。
越接近底層的 Bug，影響用戶范圍越廣
隨着中台化、服務化的發展，一套服務支持多種終端，例如 Android 端、iOS 端、Web 端等，這些服務都是由一套后端服務支持的。
如果在Web端發現一個界面問題，影響的只是Web端用戶，倘若一個服務宕掉，影響的就不止是Web端，還有Android 端、iOS 端
目前流行的測試模型
分層測試可以看到現在流行的模型更多偏向於接口測試
在質量保障過程中，我們的測試工程師會不斷增大接口測試的測試深度和測試廣度，往下逐漸覆蓋一些公共接口的單元測試內容，往上則逐漸覆蓋應該由 UI 層保障的業務邏輯測試，這么做的主要目的，就是為了更好地完成質量保障工作，交付一個可靠的、高質量的項目。
所以，從接口測試這一環節開始，測試工程師就變成了質量保障工作的主要推動者，接口測試也變得愈發重要。
接口測試的優越性
- 接口測試更容易和其他自動化系統相結合；
- 相對於界面測試，接口測試可以更早開始，也可以測試一些界面測試無法測試的范圍，因此它使測試更早的投入這句話變成現實；
- 接口測試還可以保障系統的魯棒性，使得被測系統更健壯。
不同協議形式的測試
- HTTP 協議的接口
- RESTful 格式的接口
- WebService 的接口
- RPC 協議的接口
其實無論是哪一種形式的接口，它們都是通過某一種傳輸協議，在 Client 端和 Server 端之間來完成數據傳遞的。
假如測試的是 Web 端網站，那么 Client 端就是瀏覽器，Server 端就是 Web 服務，那么瀏覽器和 Web 服務之間，就是通過 HTTP 協議傳輸的；
測試的是移動端的app，那么 Client 端就是你的設備上安裝的極客時間應用，Server 端就是 RESTful 格式的接口服務，那么極客時間的應用和 RESTful 格式的接口服務，就是通過 JSON 格式的數據來傳遞的。
結論：接口測試其實就是模擬調用方，比如 Client 端，通過接口通信來檢測被測接口的正確性和容錯性
接口測試工作場景
單接口的測試
單接口測試的重點，其實就是保證該接口的正確性和健壯性。也就是說，你既要保證這個接口可以按照需求，正確處理傳入的參數，給出正確的返回；也可以按照需求，正確的拒絕傳入非正確的參數，給出正確的拒絕性返回。
總結：需要有足夠的用例保證接口能正確處理各種正常情況和異常情況
業務流程的接口測試（多接口測試）
主要是保障通過多個接口的串聯操作可以完成原來需求中提出的業務邏輯
總結：重點在於業務流程是否能跑通
拓展：我們更需要關心業務流和數據流的關系，並不需要再過度關心如何用業務流的方法覆蓋更多的代碼邏輯異常
多個接口串行分析
在大部分的測試場景中，我們都需要串行多個接口，才能完成一個完整的業務邏輯；多個接口之間並不是隨意組合的，而是按照業務邏輯、通過數據傳遞來完成的。所以要完成整體業務邏輯的接口測試，需要理清每個流程的數據流程，而數據流程驅動了業務流處理
工作實踐
分層測試中為什么在單元測試和界面測試之間要加入一層接口測試的主要原因之一。
- 通過單接口測試，可以更加接近於單元測試；
- 通過業務流的接口測試，可以更加接近於界面所承載的交互中的業務流驗證
這也是為什么現在很多人在提倡將測試模型由原來的金字塔形往菱形轉變的依據之一了。
接口測試總結
接口測試的執行方式、設計思維都和業務測試不完全一致，它們既有交集又有差異。
交集部分是它們都會涉及到業務邏輯測試，但是接口測試更加關注有數據流驅動的業務流程，而不再着眼於代碼異常、代碼邊界等，這些邊界問題在接口測試過程中已經由單接口測試完成了。
接口測試在單接口測試的設計思維上也更加貼近於代碼的單元測試，但它還是站在 Client 端的角度來完成測試；而接口測試的業務邏輯測試更加靠近手工業務測試，但卻更加聚焦於業務邏輯本身，不再將一些非法業務異常放到該部分進行測試。
在測試手段上，接口測試算是技術驅動和業務驅動雙管齊下的工作（界面測試卻是業務驅動為主的工作）
因此，你需要借助一定的工具來完成它。這個工具既有可能是成熟的工具，也有可能是你自己寫的代碼，因此，測試技術會在接口測試階段，變得和業務知識一樣重要。
關於接口測試中的Cookie
Cookie 中傳遞的參數很多都是用來確認用戶身份、鑒定角色權限等需要的參數。
Cookie 內容是完成接口測試必須要模擬並傳遞的一些信息，因此，我們必須要盡可能完善它，使它成為接口測試的必要輸入條件之一。
一般來說，當你測試一個接口的時候，你可以將接口的信息弄成一個表
被標注為白色背景的部分，是這次訪問的基本信息；
被標注為黃色背景的部分，是訪問的頭信息，同時也是我們已知的內容，因為字段&值都是統一的
被標注為紅色背景的部分，就是 Cookie 信息，是我們未知的內容（針對Cookie的各項參數我們需要向開發詢問他們的含義）
需要了解Cookie哪些信息？
參數的含義以及來源
要知道參數的含義是拿來干嘛的，也要知道這個參數的賦值是從哪里來的，是從其他頁面的返回值中得到的？還是 JS 生成的？如果是其他頁面或者接口返回的，那么，是哪一個接口返回的哪個字段？這樣，當你開始做接口測試的時候，你就知道去哪里拿到這個參數的賦值了。
參數的作用域
是指這個參數在這個接口中是做什么用的，它在哪一個訪問周期里是一直存在的，它是否導致了業務邏輯分支等。比如說，這個參數是用來驗證用戶權限嗎？它的驗證算法是什么？之所以要搞清楚這些內容，是為了你在做接口測試的時候，可以設計更小的參數組合來覆蓋更多的業務邏輯，這是測試用例去除冗余的一個很好的方法。
返回值的含義
針對接口返回的 JSON，你要搞清楚在返回值中，每一個 JSON 的 Key 所對應的含義，這樣，當你需要和這個接口產生交互的時候，就可以快速地拿到對應參數的含義，完成業務邏輯上下文的參數串聯了。