分層測試（三）：介面測試

分層測試系列文章

https://www.cnblogs.com/yuxiuyan/tag/分層測試/

1. 什麼是介面測試

介面測試是通過測試模組介面來檢測模組整體邏輯是否符合預期的測試方法。

介面測試主要用於檢測外部模組和模組介面資料交換、關鍵業務資料狀態變化。

測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及模組間的相互邏輯依賴關係等。

2. 介面測試的型別

在我們現在的業務中，主要包含了兩種型別的介面測試，分別是單模組介面測試和子系統介面測試。

2.1 單模組介面測試

介面測試程式碼與被測試的介面同源，在測試程式碼中將依賴的外部服務mock掉，資料庫不mock，測試程式碼與被測試程式碼在同一個程序。

2.2 子系統介面測試

介面測試程式碼與被測試的介面同源，測試程式碼與被測試程式碼在不同程序。

3. 介面測試的優點

介面測試以保證系統的正確穩定為目標，重要性主要體現在：

1. 簡化系統： 介面測試可以將複雜的系統關聯進行簡化，只要做好每個介面的測試就能較好地保證系統質量。
2. 驗證介面變更：單個系統的變更，是否會影響到其他系統對該系統的呼叫。常規的方法很難覆蓋相關係統，但是通過介面測試就可以驗證其他系統對該系統介面的呼叫。
3. 減少時間成本：介面功能比較單一，能夠比較好的進行測試覆蓋，也相對容易實現自動化持續整合，可以減少人工迴歸成本與時間，縮短測試周期。
4. 測試簡單：介面相對於介面功能，會更底層一些，測試覆蓋會更容易（如業務在呼叫介面時做了判斷，當不滿足條件時連結就不顯示，此時從介面無法測試相關功能是否做好判斷，通過介面就比較容易）
5. 使用者角度： 介面測試從使用者的角度對系統介面進行全面檢測。實際專案中，介面測試會覆蓋一定程度的業務邏輯 。

4. 介面測試的挑戰

1. 驗證場景有限：只能驗證預期範圍內的問題，介面測試是根據產品需求和後端架構而產生的，設計的所有用例均是介面設計人員所預期到的結果，無法測試出一些不可預見的問題。

2. 依賴測試分析： 介面測試效果對測試分析的依賴性極大。

5. 介面測試設計最佳實踐

介面測試的用例設計和單元測試有相似之處，都需要用到邊界值法、等價類法等基本測試方法。

5.1 出發點

設計介面測試用例的出發點是要驗證介面實現的功能和效能指標是否與介面檔案保持一致。

同時，測試介面需要具有良好的容錯機制，能在接收到各種異常輸入資料時做到錯誤定位。

5.2 選擇合適的測試物件

對一個系統做介面測試，識別出合理的測試物件才能保證介面測試達到預期效果，甚至能達到事半功倍的效果。

一個系統可能有很多的層次結構，也就有了不同層級的許多介面，如果對每個介面分別進行測試，時間和人力消耗較大，且用例數量大，用例的維護成本很大。

分析出系統的關鍵模組和核心介面，並對其進行完整的測試，能以最小的測試投入，達到最好的測試效果。

5.3 介面測試用例包括的內容

介面測試用例的內容包括：輸入引數組合、預期結果、實際執行結果以及備註的其他相關資訊，如：測試功能點說明，測試環境說明等。

預期結果包括介面返回值以及介面的輸出引數的內容。

輸入引數的組合應遵循等價類法和邊界值法等常用用例設計方法，以最少的用例數量覆蓋所有典型引數組合，做到每條用例覆蓋不同的測試點，且每條用例都不可被取代。

5.4 介面測試的設計方法

介面測試的依據往往是需求規格說明書等軟體設計檔案，測試手段是把介面內的程式邏輯看作一個黑盒，只根據介面定義來編寫測試程式碼，相當於把一個介面當作一個函數來進行測試，為了確保測試的覆蓋率，可能會使用到單元測試的用例設計方法。

5.4.1 設計正常場景用例

根據該介面實現的功能分析出該介面的正常用例包括哪幾種輸入引數的組合，從而在用例中構造相應的引數組合來覆蓋所有的正常分支。

輸入引數分為兩種型別：

1. 第1種是可以直接賦值的，這種引數直接賦值即可。
2. 第2種是其他介面呼叫的輸出引數，無法直接給出，這種引數就需要在呼叫被測介面前先呼叫其他介面，將其輸出引數作為被測介面所需要的輸入引數傳入，或者事先將所需要的引數資料寫入檔案中，通過讀取檔案的方式獲取輸入引數的資料。

對介面輸入引數的組合，需要考慮兩點：

1. 控制用例數: 需要根據自然邏輯進行排列組合，排除無效的組合，以及將可以劃分等價類的組合進行合併同類項，控制用例總數，避免冗餘重複的用例耗費測試資源。
2. 從業務分析特殊組合： 還應從業務上分析有沒有特殊的組合是沒有考慮到的，此類用例往往不止涉及單一介面，而是涉及到根據某個特定業務流程而產生的介面呼叫流程，通過介面呼叫的方式模擬關鍵業務流程，可以在不用搭建輔助測試環境的情況下單純的測試被測介面，去除測試環境複雜性對測試結果的影響，極大提升測試效率。

5.4.2 設計異常場景用例

選取一條正常用例的資料作為基礎資料，然後遍歷所有的輸入引數，針對每一個輸入引數，分別使用等價類法，邊界值法等用例設計方法列舉出該引數的所有異常值。
該用例除了該引數為異常外，其餘引數均保持正常值不變，以保證測試結果僅由異常的那一個引數導致。
當所有輸入引數都使用上述方法設計了對應的異常用例之後，進一步補充不方便在用例檔案中輸入的異常引數到測試指令碼中，通過 switch 分支判斷，在測試指令碼中將無法通過檔案讀取的異常輸入值（如：錯誤指標等），直接賦值給介面的輸入引數，測試某些指標型別的資料錯誤是否被及時捕獲並返回正確無歧義的錯誤碼。

5.5 錯誤碼

1. 注意錯誤碼返回

在介面設計中，任何時候都應該返回定義好的錯誤碼，絕不能讓程式異常退出，或者把未經任何處理的異常資訊直接丟擲。

程式的異常退出，會產生惡劣的使用者體驗，也無法進行錯誤排查。

把未經處理的異常資訊丟擲，有可能把不應該被使用者感知的資訊暴露出來，比如資料庫相關資訊，從而產生安全隱患。

2. 錯誤碼的準確性很重要

錯誤碼的準確性對介面呼叫失敗原因的定位有非常重要的意義，將極大降低後續維護成本，錯誤碼的設定應當準確，無歧義，一種錯誤型別一個錯誤碼，儘量將錯誤碼編得更細，更有利於錯誤排查。

3. 錯誤碼應該是明確含義的

錯誤碼應當在介面設計檔案中有明確定義，並且在不同介面中保持一致。