介面測試是測試系統元件間介面的一種測試，主要用於測試系統與外部其他系統之間的介面，以及系統內部各個子模組之間的介面。測試的重點是要檢查介面引數傳遞的正確性，介面功能實現的正確性，輸出結果的正確性，以及對各種異常情況的容錯處理的完整性和合理性。針對軟體介面的分類一般有如下幾種情況：
2)同一系統內部上層服務對下層服務的呼叫，如乙個軟體程式一般分為表示層，業務層和資料層，表示層呼叫業務層的介面來完成自己的工作，而業務層又會呼叫資料層的介面來實現相應的業務等。
其以保證系統的正確和穩定為核心，重要性主要體現為以下幾個方面：
（1）能夠提早發現 bug，符合質量控制前移的理念。
（2）介面測試低成本高效益，因為介面測試可以自動化並且是持續整合的。
（3）介面測試從使用者的角度對系統介面進行全面檢測。實際專案中，介面測試會覆蓋一定程度的業務邏輯。
介面測試的用例設計與單元測試有相似之處。都需要用到如：邊界值法，等價類法等基本測試方法。
首先，設計介面測試用例的出發點是要驗證介面實現的功能與效能指標與介面設計文件的一致性，同時測試介面具有良好的容錯機制，能在接收到各種異常輸入資料時做到：返回對錯誤定位具有良好參考意義的錯誤碼，遮蔽底層錯誤資訊，同時介面測試用例需要暴露介面**更多的**缺陷，以這個出發點為導向。
其次，選擇合適的測試物件。對乙個系統做介面測試，識別出合理的測試物件才能保證介面測試達到預期效果，甚至能達到事半功倍的效果。乙個系統可能有很多的層次結構，也就有了不同層級的許多介面，如果對每個介面分別進行測試，時間和人力消耗較大，且用例數量大，用例的維護成本很大。分析出系統的關鍵模組和核心介面，並對其進行完整的測試，能以最小的測試投入，達到最好的測試效果。介面測試用例的內容應該包括：
輸入引數組合、預期結果、實際執行結果以及備註的其他相關資訊，如：測試功能點說明，測試環境說明等。其中，預期結果包括介面返回值以及介面的輸出引數的內容。輸入引數的組合應遵循等價類法和邊界值法等常用用例設計方法，以最少的用例數量覆蓋所有典型引數組合，做到每條用例覆蓋不同的測試點，且每條用例都不可被取代。另外，介面測試用例設計時，需要注意的是以下幾點：
(1)每一條用例需要有完善的初始化操作和結束操作。在每條用例開始時，由於不確定上一條用例的執行結果對測試環境的影響，因此需要把涉及到此條用例的相關資料進行初始化，比如：測試建立檔案的介面，需要把已存在的檔案全部刪除，然後在用例中建立相應數量的檔案，才能準確的在驗證點中寫明，呼叫建立檔案介面以後，裝置上存在幾個檔案，如果不進行初始化操作，有可能上一條用例產生的檔案依然存在，那驗證點中寫明的檔案個數就與實際情況不符，該條用例執行結果就是失敗，但這個結果實際上是因為沒有進行用例資料初始化造成的。同樣介面的結束操作也是為了盡可能不影響後續用例的測試環境和執行結果，比如：該條用例建立的資料夾和檔案，分配的記憶體空間等等，都需要在用例執行結束時將其刪除或釋放空間。我們知道，不管是記憶體，還是磁碟空間或者是其他資源都不是無限的，如果不在使用完畢後及時釋放，就會出現意想不到的測試結果，比如相關資源被耗盡導致介面呼叫失敗，檔案數達到上限，記憶體被耗盡等，尤其是在 api 介面的效能測試和穩定性測試**現此類問題，會嚴重影響測試結果的正確性，由於需要排查到底是介面本身的 bug還是測試指令碼或用例的 bug 引發的不通過的測試結果，增大了測試難度，也增加了測試的時間成本。
(2)介面的初始化操作和結束操作通常是通過呼叫其他介面來完成的，部分初始化操作和結束操作的介面呼叫時，不用判斷其介面呼叫返回值就可以直接往下執行。原因有兩點，一是用於初始化和結束操作的介面往往是比較簡單的或是基礎性的介面，這類介面往往是最先被測試並已通過測試的，因此我們假定這些介面都是被正確實現了，不需要通過判定其返回值來確認該操作是否成功，二是此類介面的呼叫結果往往既可能成功也可能失敗，但就算失敗了，也不影響介面測試本身，因此不需要判定其返回值。舉個例子，如果我在呼叫建立檔案界面前，為了初始化測試環境呼叫了刪除檔案介面，那麼它的執行結果有兩個，成功或失敗。如果執行成功，則證明之前的測試環境中殘留有其他用例建立的檔案，刪除操作有效，如果執行失敗，則確認了該測試環境中已無影響測試的其他資料，可以順利進行下一步介面呼叫，因此無論初始化介面呼叫結果為成功或失敗，都確保了測試環境與預期一致，不需要對初始化介面進行呼叫結果判斷。不需要對結束清理介面進行結果判斷的原因類似，被測介面建立檔案的執行結果可能為成功或失敗，兩種結果會導致測試環境中資料的不同變化，因此統一呼叫刪除檔案操作並不判斷其呼叫返回值是簡單有效的清理資料的方法。
因為介面測試的依據往往是需求規格說明書等軟體設計文件，測試手段是把介面內的程式邏輯看作乙個黑盒，只根據介面定義來編寫測試**，相當於把乙個介面當作乙個函式來進行測試，為了確保測試的覆蓋率，可能會使用到單元測試的用例設計方法。具體的測試用例設計描述如下：
(1)正常用例的設計方法。
具體是指根據該介面實現的功能分析出該介面的正常用例包括哪幾種輸入引數的組合，從而在用例中構造相應的引數組合來覆蓋所有的正常分支。輸入引數分為兩種型別，一種是可以直接賦值的，這種引數直接賦值即可，另一種引數是其他介面呼叫的輸出引數，無法直接給出，這種引數就需要在呼叫被測界面前先呼叫其他介面，將其輸出引數作為被測介面所需要的輸入引數傳入，或者事先將所需要的引數資料寫入檔案中，通過讀取檔案的方式獲取輸入引數的資料。對介面輸入引數的組合，一是需要根據自然邏輯進行排列組合，排除無效的組合，以及將可以劃分等價類的組合進行合併同類項，控制用例總數，避免冗餘重複的用例耗費測試資源。
同時還應從業務上分析有沒有特殊的組合是沒有考慮到的，此類用例往往不止涉及單一介面，而是涉及到根據某個特定業務流程而產生的介面呼叫流程，通過介面呼叫的方式模擬關鍵業務流程，可以在不用搭建輔助測試環境的情況下單純的測試被測介面，去除測試環境複雜性對測試結果的影響，極大提公升測試效率。比如，要測試該介面涉及到的某個特定關鍵業務流程，有兩種方式覆蓋測試，第一種方式是搭建真實的測試環境，將該業務流程涉及到的所有模組，裝置，軟體全部準備到位，然後進行業務流程測試，此種測試的優點是最大程度還原了使用者真實業務使用場景，缺點是出現異常極難定位問題原因到底是出在被測介面上，還是其他陪測裝置或軟體上，或者是幾者之間的銜接出了問題。第二種方式則是剛才提到的通過呼叫介面模擬業務流程來覆蓋業務測試的方式，這種方式不需要額外搭建測試環境，只需要通過編寫指令碼的方式進行介面呼叫，來測試業務流程即可，雖然會花費一些人力成本編寫指令碼**，但測試結果直觀，出現問題後便於定位解決。
還有一種情況會明顯體現出這種業務測試方法的優勢，就是不同型號的裝置或軟體都有類似業務流程，測試該介面只需保證介面的業務流程測試通過，就可判斷如果實際業務流程出問題，多半是出在其他產品或者產品之間的銜接上，錯誤定位成本可控。乙個完整的用例，除了輸入引數的組合，還包括介面執行結果的預期值，預期值也包括兩部分，乙個是介面呼叫本身的返回值，該返回值反映了該介面呼叫結果是成功還是失敗，一般來說，結果為0表示執行成功，非0則表示執行失敗。非 0 的值一般是事先定義好的錯誤碼，提示介面呼叫失敗的原因，便於使用者進行故障診斷。大部分介面的引數除了輸入引數外，還包括輸出引數，對於正常用例的輸出引數也需要在用例中明確寫出預期值，作為用例是否成功執行的依據。
(2)異常用例的設計方法。
異常用例的設計一般採用以下方法。選取一條正常用例的資料作為基礎資料，然後遍歷所有的輸入引數，針對每乙個輸入引數，分別使用等價類法，邊界值法等用例設計方法列舉出該引數的所有異常值，該用例除了該引數為異常外，其餘引數均保持正常值不變，以保證測試結果僅由異常的那乙個引數導致。當所有輸入引數都使用上述方法設計了對應的異常用例之後，進一步補充不方便在用例檔案中輸入的異常引數到測試指令碼中，通過 switch 分支判斷，在測試指令碼中將無法通過檔案讀取的異常輸入值（如：錯誤指標等），直接賦值給介面的輸入引數，測試某些指標型別的資料錯誤是否被及時捕獲並返回正確無歧義的錯誤碼。
異常用例的設計需要注意的是以下幾點：
首先，介面應在任何時候都返回錯誤碼，而不能存在未經處理，直接導致呼叫介面的程式異常退出，或者將底層錯誤資訊直接返回給上一層呼叫程式。呼叫程式異常退出會給使用者非常不好的使用者體驗，同時，無法進行故障診斷和錯誤定位，而未經處理的底層錯誤資訊直接返回給呼叫程式，有可能將不應被使用者知曉的資料資訊返回給使用者，比如資料庫相關資訊，造成可能被攻擊的漏洞或安全隱患。
其次，錯誤碼的準確性很重要。錯誤碼的準確性對介面呼叫失敗原因的定位有非常重要的意義，將極大降低後續維護成本，錯誤碼的設定應當準確，無歧義，一種錯誤型別乙個錯誤碼，盡量將錯誤碼編得更細，更有利於錯誤排查。比如：引數長度錯誤和引數型別錯誤應當為不同的錯誤碼，而不應該是統一的引數錯誤的錯誤碼。同時，錯誤碼應當在介面設計文件中有明確定義，並且在不同介面中保持一致。
乙個很好的測試用例設計過程應該是建立在前期深入的需求分析和文件設計的基礎之上。需求分析得越深入全面、文件描述越詳細清晰，則設計的介面測試用例就會越全面，越能暴露出介面的缺陷，從而提供出高質量的服務介面。並且在後續介面維護過程中，有詳盡的介面設計文件作為支撐，也可以降低維護成本。
介面測試用例設計
介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車，需要登入才能新增。也就是業務要求不支援遊客新增購物車功能，如果設計乙個沒有登入的使用者，然後去測試新增購物車介面，結果介面能新增到購物車，說明功能不正常，不符合需...
介面測試用例設計
主要是子模組或者子系統間互動並相互作用的部分。因此，可以分析，系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下，至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...
介面測試用例設計
輸入引數測試 引數必填 選填 合法輸入 非法輸入 邊界值 引數為空或null異常處理，基於業務場景的考慮。如 登陸狀態 許可權 依賴等設計到dao層呼叫的，考慮資料增刪改查的準確性。返回結果測試 與需求一直 返回碼及返回字段 每種錯誤要有單獨且明確的錯誤碼 功能測試 邏輯測試 兩個請求有嚴格的先後順...