(轉)接口測試用例設計(詳細乾貨)

隨着測試分析和分層測試的深化,「接口測試」出如今咱們視野的頻次愈來愈高。那麼接口測的用例設計經常使用哪些方法呢?本文將詳細描述。前端

1  接口測試   

1.1  接口測試

接口:主要是子模塊或者子系統間交互並相互做用的部分。數組

這裏說的接口是廣義的,客戶端與後臺服務間的協議;插件間通訊的接口;模塊間的接口;再小到一個類提供的方法;均可以理解爲接口。函數

接口測試:是指針對模塊或系統間接口進行的測試。測試

1.2  接口測試發現的典型問題

接口測試常常遇到的bug和問題,以下:插件

(1)傳入參數處理不當,致使程序crash; 設計

(2)類型溢出,致使數據讀出和寫入不一致;指針

(3)因對象權限未進行校驗,能夠訪問其餘用戶敏感信息;對象

(4)狀態處理不當,致使邏輯出現錯亂;blog

(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)判斷任務狀態。

從時序獲得的用例有:

  1. 正常時序:按照正常時序請求1 2 3;

  2. 缺失的時序

    缺乏動做1調2 3;缺乏動做2調1 3;缺乏動做1和2直接調。

  3. 打亂的時序

    打亂的時序:2 1 3,還能夠有1 3 2,2 3 1,3 1 2,3 2 1。

針對處理邏輯的設計中,可能使用某一種或某幾種方式就能夠將用例覆蓋前,故實際使用中,可能不會所有使用,只要找到最合適的方式覆蓋用例便可。

2.5.3  針對輸出分析

請求任務接口返回的數據是任務完成結果,即返回完成,未完成兩種狀態(未知都做爲完成返回)。

從結果能夠考慮遍歷:

1)未完成

2)完成

3)完成-未知

從接口處理時間分析,考慮:請求後快速返回,很長時間才返回,甚至不返回結果的狀況。

3  小結

接口用例設計方法中,針對輸入、輸出的設計是通用的,接口設計時均可用到。對於接口邏輯的設計可能會應用比較適合的一種或幾種方法,在接口用例設計時,須要選取最合適的方法去覆蓋被測邏輯。

相關文章
相關標籤/搜索