淺談接口測試用例設計

 

1、接口測試

接口測試，即對API進行測試。

接口測試過程容易出現的典型問題：

(1) 傳入參數處理不當，致使程序奔潰

(2) 類型溢出，致使數據讀出和寫入不一致

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

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

(5) 邏輯校驗不完善，可利用漏洞獲取非法正當權益

2、接口測試用例設計

接口測試過程當中，一般須要先編寫測試用例，保證測試的覆蓋性、準確性。

一份用例的好壞，決定着你測試接口的準確性和覆蓋程度。

接口測試的用例的設計，主要從接口輸入和輸出兩方面進行考慮：

1. 針對輸入，可按照參數類型進行設計
2. 針對接口處理，可按照邏輯進行設計
3. 針對輸出，可根據返回結果進行分析

 

一、針對輸入設計，輸入即入參，常見的參數類型有：

1. 數值型（int,long,float,double）
2. 字符串類型
3. 數組和鏈表
4. 結構體(結構體（struct）是一些元素的結合，元素實際也是數值型，字符串型，數組或者鏈表數值型、字符串型、數組或者鏈表三種參數類型用例設計)

 

補充：針對輸入設計，還須要覆蓋必填參數、選填參數。

 

數值型

若是參數規定了值的範圍，則須要考慮等價類取值範圍內，取值範圍外，取值的邊界，若有須要，可能會遍歷取值範圍內的各個值。

例如：檢查權限的接口：TaskID的取值範圍是1-35，那麼設計時需考慮：

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

l 1-35的邊界：0,1,35,36；

l 類型的特殊值：-1,0

l 數據類型的邊界值：int的最小值最大值

l 1-35代碼的權限ID不一樣，可能須要遍歷1-35的每一個值

 

常見問題和風險：

1. 特殊值處理不當致使程序異常退出；
2. 類型邊界溢出；
3. 取值範圍外值未返回正確的錯誤信息

 

字符串型：

l 字符串型的參數，主要考慮字符串的長度和內容

l 例如：接口轉換設置鬧鐘的接口string ddhh ，用例需考慮：

l 長度：長度爲4位，比4位少，比4位多

l 邊界值：string的最大長度

l 特殊值：空字符

l 字符串內容可考慮類型：數字、非數字；

l 特殊字符

l 若是用戶輸入切其餘用戶可見的內容，則須要考慮敏感字是否被正常過濾

 

常見問題和風險：

1. 傳入非特定的類型程序異常退出
2. 超長字符未進行處理、致使存儲、顯示等異常
3. 其餘用戶可見設置的敏感字

 

數組或鏈表類型

參數類型爲數組或鏈表時，用例能夠考慮：

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

l 正常取值：1-5個權限，範圍外：6個權限；

l 邊界值：1-35的 邊界值，請求容許最大最小值

l 特殊值：0個；

l 合法id和不合法的；

l 重複的id等

 

常見問題和風險：

1. 0個item是程序異常退出
2. 重複的item處理時未去重致使數據異常

 

 

二、針對邏輯設計

接口須要進行一些邏輯處理的，按照邏輯設計用例能夠從如下幾個角度分析

1. 約束條件分析
2. 關係限制分析
3. 權限限制分析
4. 操做對象分析
5. 狀態轉換分析
6. 時序分析分析

約束條件分析：

數值限制：分數限制、金幣限制、等級限制等

例如：Q幣兌換要求積分>50才能夠參加

狀態限制：登陸狀態等

例如：同步用戶信息須要先登陸帳戶

 

關係限制：

綁定的關係，好友關係等

例如：幫家人防騙功能只能查詢綁定家人的來電信息。

 

權限限制：

管理員等

約束條件的測試在功能測試中常常遇到，在接口測試中更爲重要。它的意義在於：用戶進行操做時，在該操做的前端能夠已經進行約束條件的限制，故用戶已經直接觸發請求該接口

可是實際上，若是有其餘手段，例如UI有bug或者經過技術手段直接調用手段，那麼接口是否針對這些條件進行了限制尤其重要。

例如：要兌換5Q幣須要200積分，可是個人積分不足，因此兌換按鈕是灰色沒法點擊的狀態。

正經常使用戶是沒法操做的，可是兌換實際上是調後臺的一個接口，若是繞過頁面按鈕的限制，直接調用後臺接口兌換呢？是否能夠兌換？預期固然是不能兌換的，所以積分這個數值限制就須要針對接口進行測試，而且很是重要。

其餘約束條件相似：

時間約束：22:00以前；

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

狀態約束：登陸手機管家等等約束條件相似

 

常見問題和風險：

約束條件不足，致使用戶能夠經過特殊手段獲取利益。

 

操做對象分析：

操做一般針對對象的，例如用戶綁定電話號碼，電話號碼就是操做對象，而這個電話號碼的話費、流量也是對象

對象分析主要是針對合法和不合法對象進行操做。例如

用戶A查詢電話P1話費

用戶A查詢電話P1流量

用戶A查詢電話P2話費

用戶A查詢電話的P2流量

後臺的邏輯處理，若是一個電話已經被綁定過，從後臺的角度是能夠查詢到該電話的話費和流量的，可是在用戶側，應該是A綁定了的電話，才能讓A查詢到該電話的話費，故相似對象的測試也是必不可少的。

常見的問題和風險：

用戶可訪問非權限內的其餘用戶信息、敏感信息，從而利用這些信息謀取利益。

 

狀態轉換分析

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

如上圖所示，從某狀態改變到新的狀態，依賴於轉換接口。而對於某轉換接口，其輸入狀態是肯定的，好比Fun23，這個函數只能把狀態2轉換爲狀態3，而不能將狀態1轉換爲狀態3，那麼測試點就能夠是：

1. 狀態爲2，調用接口，狀態切換爲23
2. 狀態爲1,3等，調用接口，狀態不可切換

那麼能夠這樣設計

1. 正常的狀態切換：未領取狀態，領取任務後變爲已領取狀態；已領取知足任務條件提交後，變成已完成狀態；完成後能夠再次領取任務。
2. 非正常的狀態切換：未領取任務知足任務條件直接提交任務；已領取時再次領取任務等

常見的問題和風險：

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

 

時序分析:

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

在正常的流程裏，這些動做是根據程序調用依次進行的，並不會打亂，在接口測試時，須要考慮若是不按照時序進行，是否會出現問題。

 

例如：客戶端數據同步是由客戶端觸發進行的，期間的同步用戶沒法干預。功能測試的時候可見的就是是否能正常進行同步，而進一步分析，同步流暢實現涉及了一組動做：

從時序圖能夠看出，後臺又3個接口；登陸獲取用戶ID，上報本地數據庫，上報本地衝突。三個接口須要依次調用執行，才能完成同步。那麼在接口測試就能夠考慮打亂上訴接口的執行順序去進行執行，會有怎樣的接口，是否會出現異常。例如：獲取用戶ID後不上報本地數據而直接上報本地衝突。

 

常見問題和風險：

1. 非順序執行後，數據出現異常，可能還會出現程序其餘異常
2. 經過打亂順序獲取利益

 

三、針對輸出結果設計

接口處理正確的結果可能只有一個，可是錯誤異常返回接口有不少狀況不少值，若是知道返回結果有不少種，就能夠針對不一樣結果設計用例。

例如：提交積分任務的時候咱們一般能想到的是返回正確和錯誤，錯誤可能想到：無效任務、無效登陸態，可是不必定可否徹底覆蓋全部錯誤碼，而接口返回定義的返回碼能夠設計更多用例

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

 

常見問題和風險：

錯誤前端處理不足，致使前端異常

錯誤提示處理不當，致使用戶看到晦澀的錯誤碼

錯誤提示不當，致使用戶不知道哪裏出了問題，如何解決

 

接口超時狀況：

接口正常狀況下試有返回的，那麼若是接口不返回呢，也就是接口超時後的處理也是測試須要考慮的部分，若是超時處理不當，能夠會引出一下問題：

1. 未進行超時處理，致使整個流程阻塞
2. 超時後又收到接口返回，致使邏輯出現錯亂

 

文章轉載其餘人頁面，忘記是哪位好心人分享了，