介面測試是專案測試的一部分，正如其名，它測試的主要物件是介面，是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與所測系統之間以及內部各系統之間的互動點。測試的重點是檢查資料互動、傳遞、和控制管理過程以及系統間的相互依賴關係等。
和所有的測試一樣，介面測試出發點是你要證明所測的程式是錯誤的。以這個出發點為導向，你的設計行為就會盡量朝這個方向發展，更易發現問題，不會出現大方向的偏差。
其次，選擇好測試物件。
對於一個系統做介面測試選擇好的測試物件是介面測試關鍵。一個系統有無數的介面，每個介面如果分別測試，那將是很痛苦的一件事情，不光繁瑣浪費，而且任何一個內部介面的變動，都將導致我們用例的不可用。這裡推薦把整個系統作為一個整體，選擇整個系統提供給外部使用、互動的最外層介面作為你的測試物件，以此為測試物件的用例將有很好的健壯性，並且更高效。另外，根據資料的流向，又可將這些最外層的介面分為兩類：一類是資料進入系統的介面；一類是資料流出系統的介面。進入系統的介面實際是我們用例的執行呼叫的介面。可透過變化引數對這些介面進行呼叫，模擬外部的使用；而流出的介面則是我們用例真正該驗證的點。資料從哪裡流出，流出時的狀態如何，此時系統又是什麼狀態都是我們所應該驗證的。
然後，確認完整的測試物件的功能
最後當出發點、物件、功能都確定了，就可以真正設計用例了
介面測試用例設計和其他測試用例設計一樣，都應該本著儘可能的發現bug的目標。用例設計的內容應該包括：主要測試功能點、測試環境、測試資料、執行操作以及預期結果。
1）介面測試環境
分為兩種:一種是程式內部的環境；一種是程式的所呼叫外部介面的環境。用例在設計環境上有一個原則即：
設計真實而危險的環境，不忽視偶發環境。
真實
危險
，即在這種環境下系統出問題的機率會很大。在設計用例環境時，如果兩種環境都能達到你本用例的要求，更推薦選擇更危險的環境。所謂偶發
，即這種環境出現的機率很小。不要因為這種環境很少出現就無視它，開發很可能也是這種想法，此處很有可能隱藏著問題。
2）介面測試測試資料分為介面引數資料和用例執行所需系統資料
。資料的設計學問大，不要在設計、準備測試用例的資料上偷懶。要透過好的測試資料使用例查錯的功能充分發揮。介面引數資料需對每個引數根據測試介面的實際的功能進行分析，在符合業務邏輯的情況下進行邏輯組合排列，不要遺漏了某些邊界值和錯誤點的資料。每個用例執行所需系統資料和介面引數資料儘可能的採用不一樣的資料，使用例更容易發現問題。
3）測試功能點
如果一個介面功能複雜時推薦對介面用例進行結構劃分，這樣子用例具有更好的可讀性和維護性。
介面劃分原則為以介面提供的功能點的不同進行合適粒度的劃分
。同一功能點的用例又可根據測試環境的不同、資料的不同進行用例的填充。
4）介面測試用例執行操作非常簡單，就是所測介面的呼叫。
5）預期結果驗證
這也是介面用例設計的很關鍵的一步，應該細而不冗餘
。所謂細，用例中應詳細列出應該驗證的點。每個用例均需驗證，不要因為前幾個用例有驗證就認為全部是正確的。避免一個用例中重複做相同的驗證，提高測試用例的效率。
介面測試是專案測試的一部分，正如其名，它測試的主要物件是介面，是測試系統元件間介面的一種測試。介面測試主要用於檢測外部系統與所測系統之間以及內部各系統之間的互動點。測試的重點是檢查資料互動、傳遞、和控制管理過程以及系統間的相互依賴關係等。
和所有的測試一樣，介面測試出發點是你要證明所測的程式是錯誤的。以這個出發點為導向，你的設計行為就會盡量朝這個方向發展，更易發現問題，不會出現大方向的偏差。
其次，選擇好測試物件。
對於一個系統做介面測試選擇好的測試物件是介面測試關鍵。一個系統有無數的介面，每個介面如果分別測試，那將是很痛苦的一件事情，不光繁瑣浪費，而且任何一個內部介面的變動，都將導致我們用例的不可用。這裡推薦把整個系統作為一個整體，選擇整個系統提供給外部使用、互動的最外層介面作為你的測試物件，以此為測試物件的用例將有很好的健壯性，並且更高效。另外，根據資料的流向，又可將這些最外層的介面分為兩類：一類是資料進入系統的介面；一類是資料流出系統的介面。進入系統的介面實際是我們用例的執行呼叫的介面。可透過變化引數對這些介面進行呼叫，模擬外部的使用；而流出的介面則是我們用例真正該驗證的點。資料從哪裡流出，流出時的狀態如何，此時系統又是什麼狀態都是我們所應該驗證的。
然後，確認完整的測試物件的功能
最後當出發點、物件、功能都確定了，就可以真正設計用例了
介面測試用例設計和其他測試用例設計一樣，都應該本著儘可能的發現bug的目標。用例設計的內容應該包括：主要測試功能點、測試環境、測試資料、執行操作以及預期結果。
1）介面測試環境
分為兩種:一種是程式內部的環境；一種是程式的所呼叫外部介面的環境。用例在設計環境上有一個原則即：
設計真實而危險的環境，不忽視偶發環境。
真實
危險
，即在這種環境下系統出問題的機率會很大。在設計用例環境時，如果兩種環境都能達到你本用例的要求，更推薦選擇更危險的環境。所謂偶發
，即這種環境出現的機率很小。不要因為這種環境很少出現就無視它，開發很可能也是這種想法，此處很有可能隱藏著問題。
2）介面測試測試資料分為介面引數資料和用例執行所需系統資料
。資料的設計學問大，不要在設計、準備測試用例的資料上偷懶。要透過好的測試資料使用例查錯的功能充分發揮。介面引數資料需對每個引數根據測試介面的實際的功能進行分析，在符合業務邏輯的情況下進行邏輯組合排列，不要遺漏了某些邊界值和錯誤點的資料。每個用例執行所需系統資料和介面引數資料儘可能的採用不一樣的資料，使用例更容易發現問題。
3）測試功能點
如果一個介面功能複雜時推薦對介面用例進行結構劃分，這樣子用例具有更好的可讀性和維護性。
介面劃分原則為以介面提供的功能點的不同進行合適粒度的劃分
。同一功能點的用例又可根據測試環境的不同、資料的不同進行用例的填充。
4）介面測試用例執行操作非常簡單，就是所測介面的呼叫。
5）預期結果驗證
這也是介面用例設計的很關鍵的一步，應該細而不冗餘
。所謂細，用例中應詳細列出應該驗證的點。每個用例均需驗證，不要因為前幾個用例有驗證就認為全部是正確的。避免一個用例中重複做相同的驗證，提高測試用例的效率。