軟體測試介面測試的測試案例類型

標籤：http   java   strong   資料   width   2014   

介面測試的目的是為了測試介面（聽起來怪怪的），尤其是那些與系統相關聯的外部介面，測試的重點是要檢查資料的交換，傳遞和控制管理過程，還包括處理的次數。本文主要介紹了介面測試案例類型，讓我們一起來看。

AD：WOT2014：使用者標籤系統與使用者資料化運營培訓專場

 

介面測試是項目測試的一部分，它測試的主要對象是介面，是測試系統組件間介面的一種測試。介面測試主要用於檢測外部系統與所測系統之間以及內部各系統之間的互動點。測試的重點是檢查資料互動、傳遞和控制管理過程預計系統見的相互依賴關係等。

最近測試了下Service層介面測試，總結了下介面測試案例類型，大致有三種測試類型：

1.介面邏輯測試

如果要保證介面測試的順利進行，開發人員JavaDoc的輸寫定不可少，如何測試 JavaDoc這裡並不講述，這裡主要講根據JavaDoc來編寫測試案例，一般情況下JavaDoc需要包含前提條件，商務邏輯，輸入參數，輸出值的描述，在介面邏輯測試中主要是根據所描述的商務邏輯，進行用例的設計，主要目標是測試在正常輸入的情況下能得出正確的結果，測試案例的設計方法跟黑箱測試差不多，主要運用等價類別，邊界值兩種方法。

2.出錯測試

介面邏輯的測試中主要測試的是正常邏輯，即對外提供的介面服務是能夠工作的，但是這是這些測試不能保證資料的安全，及程式在異常情況的邏輯正確性，因此需要測試出錯測試，主要包括以下幾個方面：

1）空值輸入，如當傳入一個對象參數時，需進行NULL值的參數

2）參數屬性的測試，如果輸入一個未賦值參數

3）異常的測試，製造一些異常的測試情境，測試的異常描述是否清晰

4）另外如參數個數，參數類型（如int型輸入String的參數）的出錯測試，由於IDE本身就會報編譯出錯的資訊，這裡可以不做測試案例的設計。

3.路徑測試

經過了上述處理後，單個的介面服務已經得到了保證，但是在業務流中是否滿足了業務需求其實還是沒有得到保證，路徑測試的目的就是設計儘可能少的用例，來保證各種業務情境下資料是安全可操作的。路徑測試案例例子如下：

這裡的測試案例有：

1.ABC

2.ABD

3.AE

4.AFG

如果考慮到A這條路徑不只一個測試介面可以操作，可在上述用例的基礎上再增加以下用例：

5.A’BC

6. A’BD

7. A’E

8. A’FG

如果C，D路徑等有多個介面可以實現，也可以根據這種方法增加用例，達到路徑的覆蓋，但是此種路徑的覆蓋組合會非常多，因此在實際的情況下需要根據實際業務情境進行設計，如A’BC這個路徑，在現實的商務邏輯中可能是不存在的，這裡就無需列出來了。

一個很好的webservice測試過程應該是建立在前期豐富的需求討論和文檔測試的基礎上。需求討論的越充分，後期介面架構的改動越小；文檔測試的越充分，介面的品質會更高。通過本文介紹，我們可以瞭解介面測試的幾種用例類型，希望能對你有所協助。