題記：關於接口測試的歸納總結的想法來源於去年的招聘，每次面試都會問關於接口測試的一些問題，可謂“一千個讀者眼中就有一千個哈姆雷特”，每一個測試人員眼中都有不同的對接口測試的理解，因為有了去年那一階段的招聘過程，我才陸陸續續的對服務端的接口測試要點和用例分析進行整理歸納，補充歸檔，也就有了這篇文檔，歡迎閱讀的朋友們提出建議。
服務端的接口測試我們一般從功能開始進行測試，比如請求參數和響應參數的校驗，業務邏輯或業務規則的校驗，數據庫操作的校驗。功能正常后會根據需要進行安全相關的檢查、性能測試以及系列擴展測試，比如與歷史版本的兼容性測試、接口的超時驗證以及設計合理性驗證等，用例設計也是從這幾個方面進行分析設計，下面的思維導圖是一個概要的測試關注方向：
詳細介紹如下：
針對輸入
輸入主要是指接口的入參，我們平常的測試中，會先考慮正常的入參，以及異常的入參，異常情況包括：參數異常和數據異常，用例設計這塊使用較多的是等價類划分和邊界值分析
A、正常的入參
正常的入參很好理解，就是根據接口設計文檔的入參標准，輸入正常的參數，響應按接口設計文檔的約定條件正常返回
B、參數異常
參數異常包括：參數為空，多參或少參，錯誤的參數
C、數據異常
數據異常：數據類型錯誤、非空參數為空，長度不符合設計，不在字典范圍內的數據，不合法的成員，特殊字符或敏感字符，存在關聯關系的參數數據異常等
針對處理邏輯
接口測試前一般研發會提供接口設計文檔或業務相關的設計圖、流程圖，針對業務流程的處理邏輯，我們可以從入參的限制條件、事件的操作對象、業務的狀態轉換
A、 限制條件分析
數值的限制：字典，等級，行業相關限制，金額限制，分數限制等
狀態的限制：有效|無效，在線|離線，拉黑|洗白等
關系的限制：存在或不存在，綁定或解綁等
權限的限制：管理員，普通用戶等
B、 對象分析
對象分析主要是對合法和不合法的對象進行操作，比如銀行卡用戶對卡進行充值，則可能存在：用戶A使用非用戶A的卡充值；用戶A使用自己的卡進行充值，卡已過有效期；用戶A使用自己的卡進行充值，卡為黑名單或掛失等。
C、 狀態轉換的分析
比如支付類業務，先支付成功，撤單后會退款，再次支付如果支付未成功，則是支付失敗，狀態之間的切換是否正常，未按正常業務順利進行操作時，狀態怎么顯示，是否可控，是否出現異常狀態，空狀態業務怎么處理等
D、 時序分析
一些復雜的活動中，一個活動是由一系列的動作按照指定順序進行，這些動作形成一個動作流，是有按照這個順序依次執行，才能等到預期的結果，那么在執行過程中發生的其他分支動作程序會作何處理
比如斑馬停車風控業務，如果在入站后車輛直接掉頭不駛入高速業務如何處理？
針對輸出
在考慮異常時，通常我們都會想到正常情況，無效的情況，但是不一定能覆蓋所有錯誤碼，而接口定義返回的錯誤碼可以幫助我們補充這一部分的用例，比如網絡異常，無效的規則，無效的參數，無效的業務ID，無效的任務，服務器異常等，把errorcode的值都補充上去可以設計更多的用例
這種根據輸出進行設計用例，可以發現前后端是否正常輸出結果，提示是否友好，提示是否出現敏感信息等
數據庫操作
A、對數據庫操作是否頻繁，是否會在寫庫過程中占用大量的CPU，寫庫完成后進程是否釋放
B、業務數據入庫是否正常，是否有重復數據入庫，是否出現亂碼；日志數據入庫是否正常
C、數據更新是否正常，尤其是時間類字段，時間是否為24小時制的格式
D、數據刪除、備份是否正常
安全性
敏感信息是否加密（如銀行賬號，密碼，轉賬金額）
性能相關
A、接口在什么情況下會出現並發，並發場景是什么，什么情況下的並發會導致問題
B、最大並發，響應時間，吞吐量，資源消耗情況
接口超時
接口正常情況下是有返回的，那么如果接口不返回呢？所以接口超時后的處理也是測試需要考慮的部分，如果超時處理不當，可能會引起進程阻塞，或者超時后又接收到接口返回導致邏輯錯亂
與歷史版本的兼容性分析
已廢棄的協議或接口，代碼並未注釋，在某種特定的情況下可能會觸發歷史版本已廢棄的協議或接口，導致用戶使用或功能調用后出現意想不到的問題，損失
同一套系統，不同服務之間的接口相互調用時，新接口是否受歷史接口的影響，尤其是新舊接口都對某一個功能進行處理，是否存在業務不兼容的問題
這一點需要測試人員是長期的測試一個系統的，那么可能會想到這種場景，會清楚的知道什么時候哪個版本進行了重構，廢棄了那些接口，新增了那些接口，哪些場景會觸發歷史接口的某個規則
接口設計合理
接口字段是否冗余，接口是否返回了調用方期望得到的信息，接口定義是否滿足所有調用者的需求，接口調用是否方便，接口是否可擴展，接口參數使用是否方便，接口的業務規則是否都正確，接口都整個服務的使用會產生那些影響