分層測試系列文章
https://www.cnblogs.com/yuxiuyan/tag/分層測試/
1. 什麼是接口測試
接口測試是通過測試模塊接口來檢測模塊整體邏輯是否符合預期的測試方法。
接口測試主要用於檢測外部模塊和模塊接口數據交換、關鍵業務數據狀態變化。
測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及模塊間的相互邏輯依賴關係等。
2. 接口測試的類型
在我們現在的業務中，主要包含了兩種類型的接口測試，分別是單模塊接口測試和子系統接口測試。
2.1 單模塊接口測試
接口測試代碼與被測試的接口同源，在測試代碼中將依賴的外部服務mock掉，數據庫不mock，測試代碼與被測試代碼在同一個進程。
2.2 子系統接口測試
接口測試代碼與被測試的接口同源，測試代碼與被測試代碼在不同進程。
3. 接口測試的優點
接口測試以保證系統的正確穩定爲目標，重要性主要體現在：
- 簡化系統： 接口測試可以將複雜的系統關聯進行簡化，只要做好每個接口的測試就能較好地保證系統質量。
- 驗證接口變更：單個系統的變更，是否會影響到其他系統對該系統的調用。常規的方法很難覆蓋相關係統，但是通過接口測試就可以驗證其他系統對該系統接口的調用。
- 減少時間成本：接口功能比較單一，能夠比較好的進行測試覆蓋，也相對容易實現自動化持續集成，可以減少人工迴歸成本與時間，縮短測試周期。
- 測試簡單：接口相對於界面功能，會更底層一些，測試覆蓋會更容易（如業務在調用接口時做了判斷，當不滿足條件時鏈接就不顯示，此時從界面無法測試相關功能是否做好判斷，通過接口就比較容易）
- 用戶角度： 接口測試從用戶的角度對系統接口進行全面檢測。實際項目中，接口測試會覆蓋一定程度的業務邏輯 。
4. 接口測試的挑戰
-
驗證場景有限：只能驗證預期範圍內的問題，接口測試是根據產品需求和後端架構而產生的，設計的所有用例均是接口設計人員所預期到的結果，無法測試出一些不可預見的問題。
-
依賴測試分析： 接口測試效果對測試分析的依賴性極大。
5. 接口測試設計最佳實踐
接口測試的用例設計和單元測試有相似之處，都需要用到邊界值法、等價類法等基本測試方法。
5.1 出發點
設計接口測試用例的出發點是要驗證接口實現的功能和性能指標是否與接口文檔保持一致。
同時，測試接口需要具有良好的容錯機制，能在接收到各種異常輸入數據時做到錯誤定位。
5.2 選擇合適的測試對象
對一個系統做接口測試，識別出合理的測試對象才能保證接口測試達到預期效果，甚至能達到事半功倍的效果。
一個系統可能有很多的層次結構，也就有了不同層級的許多接口，如果對每個接口分別進行測試，時間和人力消耗較大，且用例數量大，用例的維護成本很大。
分析出系統的關鍵模塊和核心接口，並對其進行完整的測試，能以最小的測試投入，達到最好的測試效果。
5.3 接口測試用例包括的內容
接口測試用例的內容包括：輸入參數組合、預期結果、實際運行結果以及備註的其他相關信息，如：測試功能點說明，測試環境說明等。
預期結果包括接口返回值以及接口的輸出參數的內容。
輸入參數的組合應遵循等價類法和邊界值法等常用用例設計方法，以最少的用例數量覆蓋所有典型參數組合，做到每條用例覆蓋不同的測試點，且每條用例都不可被取代。
5.4 接口測試的設計方法
接口測試的依據往往是需求規格說明書等軟件設計文檔，測試手段是把接口內的程序邏輯看作一個黑盒，只根據接口定義來編寫測試代碼，相當於把一個接口當作一個函數來進行測試，爲了確保測試的覆蓋率，可能會使用到單元測試的用例設計方法。
5.4.1 設計正常場景用例
根據該接口實現的功能分析出該接口的正常用例包括哪幾種輸入參數的組合，從而在用例中構造相應的參數組合來覆蓋所有的正常分支。
輸入參數分爲兩種類型：
- 第1種是可以直接賦值的，這種參數直接賦值即可。
- 第2種是其他接口調用的輸出參數，無法直接給出，這種參數就需要在調用被測接口前先調用其他接口，將其輸出參數作爲被測接口所需要的輸入參數傳入，或者事先將所需要的參數數據寫入文件中，通過讀取文件的方式獲取輸入參數的數據。
對接口輸入參數的組合，需要考慮兩點：
- 控制用例數: 需要根據自然邏輯進行排列組合，排除無效的組合，以及將可以劃分等價類的組合進行合併同類項，控制用例總數，避免冗餘重複的用例耗費測試資源。
- 從業務分析特殊組合： 還應從業務上分析有沒有特殊的組合是沒有考慮到的，此類用例往往不止涉及單一接口，而是涉及到根據某個特定業務流程而產生的接口調用流程，通過接口調用的方式模擬關鍵業務流程，可以在不用搭建輔助測試環境的情況下單純的測試被測接口，去除測試環境複雜性對測試結果的影響，極大提升測試效率。
5.4.2 設計異常場景用例
選取一條正常用例的數據作爲基礎數據，然後遍歷所有的輸入參數，針對每一個輸入參數，分別使用等價類法，邊界值法等用例設計方法枚舉出該參數的所有異常值。
該用例除了該參數爲異常外，其餘參數均保持正常值不變，以保證測試結果僅由異常的那一個參數導致。
當所有輸入參數都使用上述方法設計了對應的異常用例之後，進一步補充不方便在用例文件中輸入的異常參數到測試腳本中，通過 switch 分支判斷，在測試腳本中將無法通過文件讀取的異常輸入值（如：錯誤指針等），直接賦值給接口的輸入參數，測試某些指針類型的數據錯誤是否被及時捕獲並返回正確無歧義的錯誤碼。
5.5 錯誤碼
1. 注意錯誤碼返回
在接口設計中，任何時候都應該返回定義好的錯誤碼，絕不能讓程序異常退出，或者把未經任何處理的異常信息直接拋出。
程序的異常退出，會產生惡劣的用戶體驗，也無法進行錯誤排查。
把未經處理的異常信息拋出，有可能把不應該被使用者感知的信息暴露出來，比如數據庫相關信息，從而產生安全隱患。
2. 錯誤碼的準確性很重要
錯誤碼的準確性對接口調用失敗原因的定位有非常重要的意義，將極大降低後續維護成本，錯誤碼的設置應當準確，無歧義，一種錯誤類型一個錯誤碼，儘量將錯誤碼編得更細，更有利於錯誤排查。
3. 錯誤碼應該是明確含義的
錯誤碼應當在接口設計文檔中有明確定義，並且在不同接口中保持一致。