接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
基本介紹
- 中文名：接口測試
- 外文名：Interface Testing
- 領域：軟體工程
- 有關術語：接口
- 方法：邊界值法，等價類法
- 定義：測試系統組件間接口
簡介,接口測試的用例設計,自動化測試的基本理論,使用範圍,
簡介
接口測試是測試系統組件間接口的一種測試，主要用於測試系統與外部其他系統之間的接口，以及系統內部各個子模組之間的接口。測試的重點是要檢查接口參數傳遞的正確性，接口功能實現的正確性，輸出結果的正確性，以及對各種異常情況的容錯處理的完整性和合理性。針對軟體接口的分類一般有如下幾種情況：
1)系統與系統之間的調用，如微信向用戶提供統一的對外接口，程式設計師調用接口完成基於微信的小程式等；
2)同一系統內部上層服務對下層服務的調用，如一個軟體程式一般分為表示層，業務層和數據層，表示層調用業務層的接口來完成自己的工作，而業務層又會調用數據層的接口來實現相應的業務等。
其以保證系統的正確和穩定為核心，重要性主要體現為以下幾個方面：
（1）能夠提早發現 bug，符合質量控制前移的理念。
（2）接口測試低成本高效益，因為接口測試可以自動化並且是持續集成的。
（3）接口測試從用戶的角度對系統接口進行全面檢測。實際項目中，接口測試會覆蓋一定程度的業務邏輯。
接口測試的用例設計
接口測試的用例設計與單元測試有相似之處。都需要用到如：邊界值法，等價類法等基本測試方法。
首先，設計接口測試用例的出發點是要驗證接口實現的功能與性能指標與接口設計文檔的一致性，同時測試接口具有良好的容錯機制，能在接收到各種異常輸入數據時做到：返回對錯誤定位具有良好參考意義的錯誤碼，禁止底層錯誤信息，同時接口測試用例需要暴露接口代碼更多的代碼缺陷，以這個出發點為導向。
其次，選擇合適的測試對象。對一個系統做接口測試，識別出合理的測試對象才能保證接口測試達到預期效果，甚至能達到事半功倍的效果。一個系統可能有很多的層次結構，也就有了不同層級的許多接口，如果對每個接口分別進行測試，時間和人力消耗較大，且用例數量大，用例的維護成本很大。分析出系統的關鍵模組和核心接口，並對其進行完整的測試，能以最小的測試投入，達到最好的測試效果。接口測試用例的內容應該包括：
輸入參數組合、預期結果、實際運行結果以及備註的其他相關信息，如：測試功能點說明，測試環境說明等。其中，預期結果包括接口返回值以及接口的輸出參數的內容。輸入參數的組合應遵循等價類法和邊界值法等常用用例設計方法，以最少的用例數量覆蓋所有典型參數組合，做到每條用例覆蓋不同的測試點，且每條用例都不可被取代。另外，接口測試用例設計時，需要注意的是以下幾點：
(1)每一條用例需要有完善的初始化操作和結束操作。在每條用例開始時，由於不確定上一條用例的執行結果對測試環境的影響，因此需要把涉及到此條用例的相關數據進行初始化，比如：測試創建檔案的接口，需要把已存在的檔案全部刪除，然後在用例中創建相應數量的檔案，才能準確的在驗證點中寫明，調用創建檔案接口以後，設備上存在幾個檔案，如果不進行初始化操作，有可能上一條用例產生的檔案依然存在，那驗證點中寫明的檔案個數就與實際情況不符，該條用例運行結果就是失敗，但這個結果實際上是因為沒有進行用例數據初始化造成的。同樣接口的結束操作也是為了儘可能不影響後續用例的測試環境和執行結果，比如：該條用例創建的資料夾和檔案，分配的記憶體空間等等，都需要在用例執行結束時將其刪除或釋放空間。我們知道，不管是記憶體，還是磁碟空間或者是其他資源都不是無限的，如果不在使用完畢後及時釋放，就會出現意想不到的測試結果，比如相關資源被耗盡導致接口調用失敗，檔案數達到上限，記憶體被耗盡等，尤其是在 API 接口的性能測試和穩定性測試中出現此類問題，會嚴重影響測試結果的正確性，由於需要排查到底是接口本身的 bug還是測試腳本或用例的 bug 引發的不通過的測試結果，增大了測試難度，也增加了測試的時間成本。
(2)接口的初始化操作和結束操作通常是通過調用其他接口來完成的，部分初始化操作和結束操作的接口調用時，不用判斷其接口調用返回值就可以直接往下執行。原因有兩點，一是用於初始化和結束操作的接口往往是比較簡單的或是基礎性的接口，這類接口往往是最先被測試並已通過測試的，因此我們假定這些接口都是被正確實現了，不需要通過判定其返回值來確認該操作是否成功，二是此類接口的調用結果往往既可能成功也可能失敗，但就算失敗了，也不影響接口測試本身，因此不需要判定其返回值。舉個例子，如果我在調用創建檔案接口前，為了初始化測試環境調用了刪除檔案接口，那么它的執行結果有兩個，成功或失敗。如果執行成功，則證明之前的測試環境中殘留有其他用例創建的檔案，刪除操作有效，如果執行失敗，則確認了該測試環境中已無影響測試的其他數據，可以順利進行下一步接口調用，因此無論初始化接口調用結果為成功或失敗，都確保了測試環境與預期一致，不需要對初始化接口進行調用結果判斷。不需要對結束清理接口進行結果判斷的原因類似，被測接口創建檔案的執行結果可能為成功或失敗，兩種結果會導致測試環境中數據的不同變化，因此統一調用刪除檔案操作並不判斷其調用返回值是簡單有效的清理數據的方法。
因為接口測試的依據往往是需求規格說明書等軟體設計文檔，測試手段是把接口內的程式邏輯看作一個黑盒，只根據接口定義來編寫測試代碼，相當於把一個接口當作一個函式來進行測試，為了確保測試的覆蓋率，可能會使用到單元測試的用例設計方法。具體的測試用例設計描述如下：
(1)正常用例的設計方法。
具體是指根據該接口實現的功能分析出該接口的正常用例包括哪幾種輸入參數的組合，從而在用例中構造相應的參數組合來覆蓋所有的正常分支。輸入參數分為兩種類型，一種是可以直接賦值的，這種參數直接賦值即可，另一種參數是其他接口調用的輸出參數，無法直接給出，這種參數就需要在調用被測接口前先調用其他接口，將其輸出參數作為被測接口所需要的輸入參數傳入，或者事先將所需要的參數數據寫入檔案中，通過讀取檔案的方式獲取輸入參數的數據。對接口輸入參數的組合，一是需要根據自然邏輯進行排列組合，排除無效的組合，以及將可以劃分等價類的組合進行合併同類項，控制用例總數，避免冗餘重複的用例耗費測試資源。
同時還應從業務上分析有沒有特殊的組合是沒有考慮到的，此類用例往往不止涉及單一接口，而是涉及到根據某個特定業務流程而產生的接口調用流程，通過接口調用的方式模擬關鍵業務流程，可以在不用搭建輔助測試環境的情況下單純的測試被測接口，去除測試環境複雜性對測試結果的影響，極大提升測試效率。比如，要測試該接口涉及到的某個特定關鍵業務流程，有兩種方式覆蓋測試，第一種方式是搭建真實的測試環境，將該業務流程涉及到的所有模組，設備，軟體全部準備到位，然後進行業務流程測試，此種測試的優點是最大程度還原了用戶真實業務使用場景，缺點是出現異常極難定位問題原因到底是出在被測接口上，還是其他陪測設備或軟體上，或者是幾者之間的銜接出了問題。第二種方式則是剛才提到的通過調用接口模擬業務流程來覆蓋業務測試的方式，這種方式不需要額外搭建測試環境，只需要通過編寫腳本的方式進行接口調用，來測試業務流程即可，雖然會花費一些人力成本編寫腳本代碼，但測試結果直觀，出現問題後便於定位解決。
還有一種情況會明顯體現出這種業務測試方法的優勢，就是不同型號的設備或軟體都有類似業務流程，測試該接口只需保證接口的業務流程測試通過，就可判斷如果實際業務流程出問題，多半是出在其他產品或者產品之間的銜接上，錯誤定位成本可控。一個完整的用例，除了輸入參數的組合，還包括接口執行結果的預期值，預期值也包括兩部分，一個是接口調用本身的返回值，該返回值反映了該接口調用結果是成功還是失敗，一般來說，結果為0表示執行成功，非0則表示執行失敗。非 0 的值一般是事先定義好的錯誤碼，提示接口調用失敗的原因，便於用戶進行故障診斷。大部分接口的參數除了輸入參數外，還包括輸出參數，對於正常用例的輸出參數也需要在用例中明確寫出預期值，作為用例是否成功執行的依據。
(2)異常用例的設計方法。
異常用例的設計一般採用以下方法。選取一條正常用例的數據作為基礎數據，然後遍歷所有的輸入參數，針對每一個輸入參數，分別使用等價類法，邊界值法等用例設計方法枚舉出該參數的所有異常值，該用例除了該參數為異常外，其餘參數均保持正常值不變，以保證測試結果僅由異常的那一個參數導致。當所有輸入參數都使用上述方法設計了對應的異常用例之後，進一步補充不方便在用例檔案中輸入的異常參數到測試腳本中，通過 switch 分支判斷，在測試腳本中將無法通過檔案讀取的異常輸入值（如：錯誤指針等），直接賦值給接口的輸入參數，測試某些指針類型的數據錯誤是否被及時捕獲並返回正確無歧義的錯誤碼。
異常用例的設計需要注意的是以下幾點：
首先，接口應在任何時候都返回錯誤碼，而不能存在未經處理，直接導致調用接口的程式異常退出，或者將底層錯誤信息直接返回給上一層調用程式。調用程式異常退出會給用戶非常不好的用戶體驗，同時，無法進行故障診斷和錯誤定位，而未經處理的底層錯誤信息直接返回給調用程式，有可能將不應被用戶知曉的數據信息返回給用戶，比如資料庫相關信息，造成可能被攻擊的漏洞或安全隱患。
其次，錯誤碼的準確性很重要。錯誤碼的準確性對接口調用失敗原因的定位有非常重要的意義，將極大降低後續維護成本，錯誤碼的設定應當準確，無歧義，一種錯誤類型一個錯誤碼，儘量將錯誤碼編得更細，更有利於錯誤排查。比如：參數長度錯誤和參數類型錯誤應當為不同的錯誤碼，而不應該是統一的參數錯誤的錯誤碼。同時，錯誤碼應當在接口設計文檔中有明確定義，並且在不同接口中保持一致。
一個很好的測試用例設計過程應該是建立在前期深入的需求分析和文檔設計的基礎之上。需求分析得越深入全面、文檔描述越詳細清晰，則設計的接口測試用例就會越全面，越能暴露出接口的缺陷，從而提供出高質量的服務接口。並且在後續接口維護過程中，有詳盡的接口設計文檔作為支撐，也可以降低維護成本。
自動化測試的基本理論
由於產品的不斷版本疊代，針對同一產品的不同時期版本測試時，由於核心功能保持相對穩定的狀態，因此對核心功能驗證的大部分工作都是重複的工作，通過電腦程式來完成這類工作既高效又可靠。軟體自動化測試通常是通過開發所需的軟體測試工具以實現自動化。理想的自動化水平應該達到一種程度，就是它能夠根據時間和成本的需求選取最適用於該系統的自動化測試方案。以此為指導思想實現的自動化程度越高，測試過程就越有效，越高效。因此只要選擇的測試自動化工具是適合的，並且被正確地實現，自動化測試就能極大的發揮作用，提高測試效率，改進測試質量。自動化測試的目的是將測試人員從重複繁瑣的手工操作中解放出來，把精力和時間投入到測試需求分析，測試用例設計和測試結果分析上，提高測試效率和質量。可以實施自動化測試場景有如下幾類：
(1)回歸測試
回歸測試是在軟體產品發布新版本時，在舊版本已經測試完畢的情況下，在新版本中執行和舊版本一樣的測試用例，用於確認代碼缺陷是否已經成功被修復，並且沒有因此引入其他代碼缺陷。我們知道，只要有代碼的修改，就有可能引入新的缺陷，哪怕出現新缺陷的功能點與此次修改內容看似無關。因此，確認 bug已被正確的修復，並且沒有因此引入新的bug，是保證版本質量的關鍵，由此可見回歸測試的重要性。但由於回歸測試需要對該版本的產品功能進行比較全面的覆蓋，而產品開發周期時間有限，如果依靠手工來進行回歸測試，效率低下且容易出錯，產品質量得不到保證。引入自動化測試代替手工的回歸測試則可以很好的解決上述問題，既提高測試效率，又能保證測試的可靠性，避免因為人為因素導致的測試結果不準確。
(2)非功能性測試
對於一些非功能性的測試來說，手工測試很難做到，比如容量測試，壓力測試、並發測試等。在使用自動化測試工具之前，手工測試很難模擬各種性能測試的場景，也很難達到理想的測試效果。自動化測試可以在無需專人干預的非工作時間進行，比如晚上或周末進行，充分利用時間和有限的資源，縮短測試過程中回歸測試的周期，從而縮短項目整體研發周期。同時，由於自動化測試的用例已經固化，且測試執行是由自動化測試工具來執行，排除了人為因素，使測試結果更可靠，套用在版本疊代頻繁的產品上，能高效的發現新版本的問題，保證產品質量，在回歸測試中也能更高效的完成任務，大大節省人力和時間，提高測試效率。
(3)增量開發，持續集成的項目。
此類項目一般具有自動編譯，自動發布的特點，且GUI 風格變化較小，使用自動化測試代替手工測試能顯著提高測試效率和質量。一個規範的軟體測試流程包括以下基本步驟：
1、測試計畫擬制；
2、測試方案編寫；
3、測試用例設計；
4、測試執行；
5、生成軟體問題報告。
要想充分利用自動化測試來改進測試質量，提高測試效率，必須有效地利用科學規範的測試流程將自動化測試的優點發揮到極致。總的來說，是否需要進行自動化測試，以下準則可以參考：
1、項目在時間安排上比較充裕；
2、具有明確的測試計畫和內容且不會頻繁變更需求，你從很早以前就知道要測試的具體內容，且在你進行自動化測試實踐過程中，測試內容不會頻繁變更；
3、多平台環境需要被測試，手工重複工作量大；雖然自動化測試在導入前期的人力和時間投資比較大，但一旦自動化測試平台搭建起來，測試效率的提升是相當明顯的，對於一個需求變化不大的長線產品來說，更是如此。一般，自動化測試有以下優點：
1、測試人員有更多的時間和精力進行深入測試，進行更加深入全面的測試需求分析，測試用例設計，更多時間進行創造性的手工測試，覆蓋更多的測試類型，從而提高測試的質量；
2、測試結果更加可靠:使用機器和程式來重複執行人的手工操作，比由人來手工執行，執行出錯的幾率大大降低，測試結果的可信度更高，而且省時省力；
3、提升測試效率：測試能夠在多個平台上同時運行，且執行速度相對於手工測試大大提高，在需求變化不大的情況下，用例和腳本復用率高，大大提升測試效率；
4、更好的測試評估，對測試進度和使用的時間有更精準的把控；關於自動化測試，有以下兩點認識需要明確；
自動化測試不能代替手工測試。自動化測試只能執行測試人員手工設計的測試用例，只能發現手工測試發現過的缺陷，不能指望自動化測試發現手工測試沒有發現過的新問題，測試專家 James Bach總結：
八成以上的代碼缺陷靠手工測試發現，而自動化測試只能發現剩下不到兩成的代碼缺陷。因為程式是人寫的，程式本身沒有創造力，程式不能代替人腦的思考。因此，自動化測試大量套用於產品回歸測試這種重複性的測試過程，保證經過測試人員手工測試過的功能點不因為代碼改動而引入新的缺陷；
自動化測試的可行性分析很重要。測試自動化不會減輕工作負擔，相反，推進自動化測試需要投入大量的人力和時間，因此需要結合多方面因素權衡，根據投入產出比判斷是否有必要進行自動化測試，應該對哪些被測對象進行自動化測試。同時，推行自動化測試可能會遇很多阻力和困難，如組織不夠重視導致的資源和時間分配不足、當前技術水平或產品本身的特點達不到自動化測試的要求，產品不具有延續性，長期投入可能性不大等等問題都必須考慮，因此，進行自動化測試前，進行充分全面的可行性分析是關係到自動化測試能否成功的關鍵。
使用範圍
接口測試一般會用於多系統間互動開發，或者擁有多個子系統的套用系統開發的測試。接口測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的接口，驗證其正確性和穩定性。接口測試同樣適用於一個上層系統中的服務層接口，越往上層，其測試的難度越大。接口測試在淘寶的套用是一個自下而上的發展過程。
接口測試實施在多系統多平台的構架下，有著極為高效的成本收益比，接口測試天生為高複雜性的平台帶來高效的缺陷監測和質量監督能力。平台越複雜，系統越龐大，接口測試的效果越明顯。
接口測試的目的是測試接口，尤其是那些與系統相關聯的外部接口，測試的重點是要檢查數據的交換，傳遞和控制管理過程，還包括處理的次數。外部接口測試一般是作為系統測試來看待的。
不是所有的團隊都可以在一個隔離的測試環境中進行測試工作的，因此使得對外部接口的測試顯得困難。我們應該確保較早地與相關的組織協調好並確定進行外部接口測試的方案。有時候相關的組織只是人工的靜態的審閱一次數據而並不真正的用這些數據來測試。等等這些都增加了實際測試執行中遇到的風險，但有些時候是可以避免的。
