1、接口測試的測試點以及優先級
無論是app測試還是web測試，又或者是純服務端測試，接口測試都是必須要掌握的。接口無處不在，無論你測試時看到的界面是什么，其內涵都是要靠接口進行連通。
1.1、什么是接口
百度百科的專業解釋：
接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換、傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
簡單來說，接口就是定義了標准的規則（輸入參數和輸出結果）
1.2、接口的場景分類
（1）獨立系統A與獨立系統B之間的數據交換過程
如：微信、微博所提供的第三方登錄接口，是不同公司之間系統接口的調用
（2）一個系統之間的不同層
常見的java-web項目都是分為：web層、dao數據層以及service服務層，這三層之間就是通過接口進行數據交互的
（3）系統內，服務與服務之間的調用
也就是各個模塊之間的相互調用
1.3、測試接口前的准備工作
明白了什么是接口，也明白了哪些場景下需要展開接口測試工作，我們就要准備接口測試工具，要想選擇出合適的測試工具，必須清楚的知道負責測試的接口采用的協議是什么，因為只有知道接口采用的協議是什么，才能明白它采用的協議是否屬於應用層。應用層代表的協議http，只有http的協議，才能采用常見的測試工具如postman、jmeter等去測試。
如果接口采用的協議並不屬於應用層，例如阿里巴巴的dubbo，此時你就不能直接采用postman、jmeter去測試。
總之接口測試前最重要的准備工作就在於了解接口采用的協議是哪個。
1.4、接口測試分層模型
針對接口，將接口測試抽象成四層模型，具體如下：
（1）接口文檔測試
（2）內部業務邏輯測試
（3）數據庫存儲測試
（4）其他異常流測試
展開來說：
1.4.1、基礎接口文檔的驗證
對於接口測試來說，接口文檔是雙方接口得以聯通的基礎，也是數據能否正常傳輸的依賴標准，完成接口文檔的測試，可以說接口測試就已經完成了大半。
從接口文檔中我們應該提煉出以下測試點：
（1）首先明確請求的數據類型是什么，目前主流是json串，那么就要清晰的識別出接口文檔中哪些是key-value鍵值對，哪些是內嵌的json數組，哪些是內嵌的json對象，只有這樣你才能組織出有效的測試數據。
（2）對接口文檔中定義的必錄項一一進行測試，看某必錄項缺失時，作為接收的一方是否有合理提示。
（3）對於文檔中定義的非必錄項一一進行測試，看某非必錄項缺失時，作為接收的一方是否可以正常接收信息。
（4）對於特殊字段的測試。
例如日期，需要明確以下測試點：
①需要的日期類型是Date類型還是String類型。
②需要的日期格式是時間戳還是YYYYMMDD或者YYYYMMDDHHMMSS的格式。
（5）對於有效數字保留進行測試。
一般接口文檔要求保留最多兩位小數，此時要驗證整數、保留一位小數、保留兩位小數、保留三位小數時接收方的響應。（即邊界值方法測試）
（6）對於常見的身份證號、手機號、座機號等特殊標的信息要進行長度、有效性、容錯性測試。
①針對身份證號：要注意最多支持18位，且必須保證身份證號正常，且注意以 X 結尾的身份證號系統是否支持。
②針對座機號：要注意支持的格式包含哪些，一般要支持：010-6656667、 0106656667、 0314-8876551、 03148876551、 (010)6656667等多個格式。
（7）對於枚舉值，要一一進行測試。（運用等價類划分的方法）
（8）針對特殊定義類型的測試。
例如：有些接口中定義的字段類型為 int，且是必輸，此時就有陷阱在里面，因為當不傳數據時，java 默認的 int 類型就是 0，此時不傳與傳 0 就是同樣的現象。
1.4.2、內部業務邏輯測試
此模塊要求我們基於各種業務場景，測試其接口的內部邏輯。因為針對業務不同，具體邏輯也五花八門，我只概括的進行總結，然后根據自己測試的接口展開擴展。
（1）遇到時間，要確認各種業務場景下是否有因為時間而影響的場景。
舉例一：我們遇到身份證號，判定其滿足身份證生成規則，還要看這個證件是否在有效范圍內；
舉例二：我們遇到類似還款的場景，是否發起還款的時間已經逾期。
（2）遇到金額想到是否存在等式和不等式的關系。
舉例：支付寶的花唄還款，應該注意以下場景：
①當前還款總金額=當前還款本金+當期還款利息（等式成立）
②提前還款總金額必錄且大於0（不等式成立）的金額，不能還負數
（3）遇到運維階段的需求改動，一定要想到歷史數據的處理。
舉例：銀行借款：銀行答應借款人的借款期限是3個月，后來業務收縮，決定縮小期限變為2個月.那么已經按照3個月借款的借款人怎么辦？肯定還是按照3個月期限進行還款。此時就需要我們的程序一定要兼容歷史數據也要適用於新數據。測試時必須考慮這一點。
（4）獨立存在的邏輯場景。
這個需要切實根據自己測試的功能進行總結，建議可以將這部分建立自己的質量地圖，后期維護時肯定會事半功倍。
（5）地域划分邏輯。
許多接口需要采集信息，是否對港澳台等特殊地區有特殊要求。
（6）不同業務接口見的數據枚舉轉化。
舉例：在自己的接口文檔中，性別使用M、F來代表男、女。但是和合作方的接口中，卻用數字1、2表示，此時我們設計用例要覆蓋轉化關系。
總的來說，如果說“基礎接口文檔的驗證”依賴的是接口文檔，那么此層級的測試則更關注與需求和業務。
1.4.3、數據庫相關測試
針對接口測試，最終還要確保數據正確落庫，主要需要關注如下測試點：
（1）接口完成會插入哪些業務表
（2）接口完成會更新哪些表的哪些字段
1.4.4、其他異常流測試
前三部分可以說測試用例都是圍繞正常流展開的，本層級需要重點關注異常流，具體需要從如下方面進行測試用例的設計展開。
（1）密等性測試
主要針對如下場景：A調用B，此時發生超時或者斷網等異常，此時B已經接收但是卻沒有返回給A，A再次調用此時B的處理邏輯。
（2）流程節點測試
例如：本來程序的正常流轉應該是 A->B->C，此時我們跳過B節點，直接從 A 流轉到 C 程序是否有良好的校驗。
（3）數據庫事務性測試
有些重要的業務流程，可能涉及操作多個數據庫中的表，當中間執行失敗時，數據庫是否可以回滾以保持數據的准確。
異常測試還有很多，上述列舉出來的屬於最經典的部分。
1.5、測試優先級
上述的四個層面都屬於重點測試模塊，優先級高，針對一個接口應該將上面的四個層級都覆蓋掉才能保證接口測試的完備。