介面測試

介面測試是測試系統組件間介面的一種測試，主要用於測試系統與外部其他系統之間的介面，以及系統內部各個子模塊之間的介面。測試的重點是要檢查介面參數傳遞的正確性，介面功能實現的正確性，輸出結果的正確性，以及對各種異常情況的容錯處理的完整性和合理性。針對軟體介面的分類一般有如下幾種情況：

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總結：

八成以上的代碼缺陷靠手工測試發現，而自動化測試只能發現剩下不到兩成的代碼缺陷。因為程序是人寫的，程序本身沒有創造力，程序不能代替人腦的思考。因此，自動化測試大量應用於產品回歸測試這種重複性的測試過程，保證經過測試人員手工測試過的功能點不因為代碼改動而引入新的缺陷；

自動化測試的可行性分析很重要。測試自動化不會減輕工作負擔，相反，推進自動化測試需要投入大量的人力和時間，因此需要結合多方面因素權衡，根據投入產出比判斷是否有必要進行自動化測試，應該對哪些被測對象進行自動化測試。同時，推行自動化測試可能會遇很多阻力和困難，如組織不夠重視導致的資源和時間分配不足、當前技術水平或產品本身的特點達不到自動化測試的要求，產品不具有延續性，長期投入可能性不大等等問題都必須考慮，因此，進行自動化測試前，進行充分全面的可行性分析是關係到自動化測試能否成功的關鍵。

介面測試一般會用於多系統間交互開發，或者擁有多個子系統的應用系統開發的測試。介面測試適用於為其他系統提供服務的底層框架系統和中心服務系統，主要測試這些系統對外部提供的介面，驗證其正確性和穩定性。介面測試同樣適用於一個上層系統中的服務層介面，越往上層，其測試的難度越大。介面測試在淘寶的應用是一個自下而上的發展過程。

介面測試實施在多系統多平台的構架下，有著極為高效的成本收益比，介面測試天生為高複雜性的平台帶來高效的缺陷監測和質量監督能力。平台越複雜，系統越龐大，介面測試的效果越明顯。

介面測試的目的是測試介面，尤其是那些與系統相關聯的外部介面，測試的重點是要檢查數據的交換，傳遞和控制管理過程，還包括處理的次數。外部介面測試一般是作為系統測試來看待的。

不是所有的團隊都可以在一個隔離的測試環境中進行測試工作的，因此使得對外部介面的測試顯得困難。我們應該確保較早地與相關的組織協調好並確定進行外部介面測試的方案。有時候相關的組織只是人工的靜態的審閱一次數據而並不真正的用這些數據來測試。等等這些都增加了實際測試執行中遇到的風險，但有些時候是可以避免的。