https://www.tuicool.com/articles/E3m2Mn6

導語

隨著測試分析和分層測試的深化，“介面測試”出現在我們視野的頻次越來越高。那麼介面測的用例設計常用哪些方法呢？本文將詳細描述。

1  介面測試   

1.1  介面測試

介面：主要是子模組或者子系統間互動並相互作用的部分。

這裡說的介面是廣義的，客戶端與後臺服務間的協議；外掛間通訊的介面；模組間的介面；再小到一個類提供的方法；都可以理解為介面。

介面測試：是指標對模組或系統間介面進行的測試。

1.2  介面測試發現的典型問題

介面測試經常遇到的bug和問題，如下：

（1）傳入引數處理不當，導致程式crash； 

（2）型別溢位，導致資料讀出和寫入不一致；

（3）因物件許可權未進行校驗，可以訪問其他使用者敏感資訊；

（4）狀態處理不當，導致邏輯出現錯亂；

（5）邏輯校驗不完善，可利用漏洞獲取非正當利益等。

2  介面測試用例設計

上圖為一個典型的介面。一個介面通常是有輸入輸出的，輸入就是我們常見的入參，輸出有時有，有時沒有。呼叫相關介面，介面會執行相關處理邏輯。

介面測試的用例設計，主要從輸入和介面處理兩方面考慮：

1）針對輸入，可按照引數型別進行設計；

2）針對介面處理，可按照邏輯進行用例設計；

3）針對輸出，可根據結果進行分析設計。

2.1  針對輸入設計

對於介面來說，輸入就是入參。常見引數型別有:

（1）數值型(int,long,float,double等）

（2）字串型別

（3）陣列或連結串列

（4）結構體

結構體(struct)是一些元素的結合，元素實際也是數值型，字串型，陣列或連結串列。

下面詳細說明數值型、字串型、陣列或連結串列三種引數型別用例設計。

2.1.1  數值型

數值型的引數主要考慮以下幾個方面設計：

如果引數規定了值的範圍，則需要考慮等價類取值範圍內、取值範圍外，取值的邊界，如有需要，可能會遍歷取值範圍內的各個值。

例如檢查許可權的介面：TaskChecker.checkTask(int taskID) taskID的取值範圍是1-35，那麼設計時考慮：

• 1-35範圍內和範圍外的值；

• 1-35的邊界：0，1,35,36；

• 型別的特殊值：-1,0

• 資料型別的邊界值：int的最小值最大值；

• 因為1-35程式碼的許可權ID不同，可能需要遍歷1-35的每個值。

常見問題和風險：

• 特殊值處理不當導致程式異常退出；

• 型別邊界溢位

• 取值範圍外值未返回正確的錯誤資訊等

2.1.2  字串型

字串型的引數，主要考慮字串的長度和內容：

例如介面轉換設定鬧鐘的介面DateUtil.getDayOfDDHH(String ddhh)，用例可以考慮：

• 長度為4位，比4位少，比4位多；

• 邊界值：String的最大長度；

• 特殊值：空字元；

• 字串內容可考慮型別：數字，非數字；

• 特殊字元。

• 如果是輸入使用者輸入且其他使用者可見的內容，則還需要考慮敏感字是否被正常過濾。

可能出現的問題和風險：

• 傳入非特定型別程式異常退出

• 超長字元未進行處理，導致儲存、顯示等異常

• 其他使用者可見設定的敏感字

2.1.3  陣列或連結串列型別

引數型別為陣列或連結串列時，用例可以考慮：

例如批量提交任務的介面submitTask(int[] taskID)，引數用例設計考慮：

• 正常取值：1-5個許可權，範圍外：6個許可權；

• 邊界值：1-35的邊界值，請求允許最大最小值；

• 特殊值：0個；

• 合法ID和不合法的；

• 重複的ID等。

可能存在的問題和風險：

• 0個item時程式異常退出；

• 重複的item處理時未去重導致結果異常等。

2.2  針對邏輯設計

介面需要進行一些邏輯處理的，那麼按邏輯設計用例可以從以下幾個角度分析。

2.2.1  約束條件分析

（1）數值限制：分數限制、金幣限制、等級限制等等。

例如：兌換Q幣活動要求積分>50才可參與。

（2）狀態限制：登入狀態等。

例如：同步使用者資訊需要先登入賬號。

（3）關係限制：繫結的關係，好友關係等。

例如：幫家人防騙功能只能查詢繫結家人的來電資訊。

（4）許可權限制：管理員等。

約束條件的測試在功能測試中經常遇到，在介面測試中更為重要。它的意義在於：使用者進行操作時，在該操作的前端可以已經進行了約束條件的限制，故使用者無法直接觸發請求該介面。但是實際上，如果有其他手段：例如UI有bug或者通過技術手段直接呼叫介面，那麼介面是否針對這些條件進行了限制就尤為重要。

例如常見的例子： 要兌換5Q幣需要200積分，但是我積分不足，所以兌換按鈕是灰色無法點選的狀態：

正常使用者是無法操作的，但是兌換其實是調後臺的一個介面，如果繞過頁面按鈕的限制，直接呼叫後臺介面兌換呢？是否可以兌換？預期當然是不能兌換的。因此積分這個數值限制就需要針對介面進行測試，並且非常重要。

其他約束條件類似：

• 時間約束：22：00之前；

• 數值約束：積分200；限量5個；

• 狀態約束：登入手機管家；

• 等等約束條件類似。

常見的問題和風險：

• 約束條件判斷不足，導致使用者可通過特殊手段獲取利益

2.2.2  操作物件分析

操作通常是針對物件的，例如使用者繫結電話號碼，電話號碼就是操作物件，而這個電話號碼的話費、流量也是物件。

物件分析主要是針對合法和不合法物件進行操作。例如下述用例子:

• 使用者A查詢電話P1話費：

• 使用者A查詢電話P1流量；

• 使用者A查詢電話P2話費；

• 使用者A查詢電話P2流量。

後臺的邏輯處理，如果一個電話已經被繫結過，從後臺的角度是可以查詢到該電話的話費和流量的。但是在使用者側，應該是A綁定了的電話，才能讓A查詢到該電話的話費。故類似物件的測試也必不可少。

常見的問題和風險：

• 使用者可訪問非許可權內的其他使用者資訊、敏感資訊，從而利用這些資訊謀取利益。

2.2.3 狀態轉換分析

被測邏輯可以抽象成狀態機，各個狀態之間根據功能邏輯從一個狀態切換到另一個狀態。如果我們打亂了這個次序，從一個狀態切換到另一個不在它下一狀態集中的狀態，那麼邏輯將會打亂，就會出現邏輯問題。

如上圖所示，從某狀態改變到新的狀態，依賴於轉換介面。而對於某轉換介面，其輸入狀態是確定的，比如Fun23, 這個函式只能把狀態2轉換為狀態3，而不能把狀態1轉換為狀態3。那麼測試點就可以是：

（1）狀態為狀態2，呼叫介面Fun23（），狀態切換到狀態23；

（2） 狀態為1,3等，呼叫介面Fun23（），狀態不能切換。

例如在做任務的時候，任務有三種狀態：未領取，已領取未提交，已完成三種狀態。

那麼可以這樣設計：

（1）正常的狀態切換：未領取狀態，領取任務後變為已領取狀態；已領取滿足任務條件提交後，變成已完成狀態；完成後可以再次領取任務。

（2） 非正常的狀態切換：未領取任務滿足任務條件直接提交任務；已領取時再次領取任務等等。

常見的問題和風險：

可通過特殊手段達到原本不能的狀態，從而謀取利益。

2.2.4  時序分析

在一些複雜的活動中，一個活動是由一系列動作按照指定順序進行的，這些動作形成一個動作流，只有按照這個順序依次執行，才能得到預期結果。

在正常的流程裡，這些動作是根據程式呼叫依次進行的，並不會打亂，在介面測試時，需要考慮如果不安裝時序執行，是否會出現問題。

例如，客戶端資料同步是由客戶端觸發進行的，期間的同步使用者無法干預。功能測試的時候可見的就是是否能正常進行同步，而進一步分析，同步流程實際涉及了一組動作：

從時序圖可以看出，後臺有3個介面：登陸獲取使用者ID，上報本地資料，上報本地衝突。三個介面需要依次呼叫執行，才能完成同步。那麼在介面測試就可以考慮打亂上述介面的執行順序去執行，會有怎樣的結果，是否會出現異常。例如：獲取使用者ID後不上報本地資料而直接上報本地衝突。 

常見的問題和風險：

• 非順序執行後，資料出現異常，可能還會出現程式其他異常

• 通過打亂順序獲取利益

2.3  針對輸出設計

針對輸出設計其實是針對介面返回的結果進行分析。

2.3.1  針對輸出結果

介面處理正確的結果可能只有一個，但是錯誤異常返回結果有很多情況很多值。如果知道返回結果有很多種，就可以針對不同結果設計用例。例如提交積分任務的時候我們通常能想到的是返回正確和錯誤，錯誤可能想到：無效任務，無效登入態，但是不一定能否完全覆蓋所有錯誤碼，而介面返回定義的返回碼可以設計更多用例：

覆蓋返回碼也是用例設計的一種思路。

常見問題和風險：

（1）錯誤前端處理不足，導致前端異常；

（2）錯誤提示處理不當，導致使用者看到晦澀的錯誤碼；

（3）錯誤提示不當，導致使用者不知道哪裡出了問題，如何解決。

2.3.2  介面超時

介面正常情況下是有返回的，那麼如果介面不返回呢？也就是說介面超時後的處理也是測試需要考慮的部分。如果超時處理不當，可能會引起以下問題：

（1）未進行超時處理，導致整個流程阻塞

（2）超時後又收到介面返回，導致邏輯出現錯亂

2.4  其他測試設計

2.4.1  已廢棄介面測試

已廢棄協議，是指之前有定義，但是因為需求變更或其他原因，目前版本不用。這些介面雖然不再使用，但有可能程式碼並沒有及時刪除。如果利用技術手段呼叫這些介面，可能獲取額外利益。

例如，任務之前有個清理任務，在一個版本需求裡將清理任務替換為下載任務。在新版本客戶端已不再呼叫完成清理任務的介面；但是如果該介面未關閉，使用者就可以繼續請求submitTask(int taskID)介面完成清理任務獲得積分。

因此新版本在考慮相容舊版本的同時，還應做好相關廢棄介面的檢查，避免使用者獲得額外利益。

2.4.2  介面設計合理性分析

介面定義是否合理可以從以下幾個方面分析：

（1）介面欄位是否冗餘；

（2）介面是否冗餘；

（3）介面是否返回了呼叫方期望得到的資訊；

（4）介面定義是否可滿足所有呼叫需求；

（5）介面定義呼叫是否方便。

2.5  一個完整的例子 

下面舉一個完整例子，通過上述方法來分析如何對介面進行用例設計。

某模組提供了一個介面給其他模組，使用者請求任務，介面定義如下：

2.5.1  針對輸入設計

dialogDetailText（dialogButtonText類似）

長度

1）正常：請安裝提示進行操作； 

2）邊界：一個字：請；長度非常長：無懸浮窗許可權，可能影響XX功能無法使用，請開始懸浮窗許可權，以便獲得更好的使用者體驗；甚至更長；

3）特殊：空字串。

內容

1）特定型別：中文，英文，數字等；

2）特殊字元：/n/r/t ,.><?*$&^%~"ஜღ℡♬€✎等；

3）敏感字元：非使用者設定，不涉及。

taskID（requestType類似）

等價類

取值範圍內：1,5,10等；

取值範圍外：0，99。

邊界法

取值範圍邊界：0,1,38,39,40

資料型別邊界：-2147483648 ,2147483648

特殊值 ：0,-1等。

遍歷法 ：1,2,3,4,5…38,39對應每種不同ID。

2.5.2  針對邏輯設計

（1）約束條件分析

去引導某功能需要：未完成過任務，任務有任務資料。

那麼用例可以是：以下情況下調requestTask：

1）未使用過有任務資料時；

2）未使用無任務資料時；

3）使用過有任務資料時；

4）使用過無任務資料時。

如果有其他約束條件類似設計。

（2）操作物件分析

呼叫請求介面後，會顯根據任務資料，引導對應的任務。任務資料，任務操作方式，任務功能都可以是物件。

1）任務資料

• 資料型別：本地，雲端 等

• 資料有效性：正確資料，錯誤資料

2）操作方式

方式：安裝，下載，開啟等等 。

3）任務功能 

功能：使用者操作了該功能，未正常操作該功能；什麼都不操作；完成一個任務功能；完成多個任務功能；任務功能使用順序等等。

物件：還需要關注，會不會操作到不合法的物件，例如任務資料和功能不對應等問題。

（3）狀態轉換分析

功能是有4個狀態的：完成，未完成，未知。狀態圖如下：這裡是產品裡涉及的狀態轉換：

針對該狀態：

1）正常狀態轉換：未完成狀態請求並完成任務後是否可變成完成狀態；未完成狀態請求但不完成，還是未完成狀態。

2）走不到的狀態路徑：未知和完成狀態請求任務，不能進行進行該任務。

2.4  時序分析

從時序的角度分析，呼叫請求介面前需要以下2步動作：

1）拉取任務資料；

2）判斷任務狀態。

相關推薦