介面測試用例設計思路

2021-08-17 10:38:15 字數 1422 閱讀 6579

根據以往的工作經驗,介面用例設計主要從以下三個方面來進行設計:

1 輸入

輸入引數主要從以下幾各方面設計:

a 必填項校驗

介面文件中有是否必填的說明。參考介面文件即可。

b 引數長度校驗

參考介面文件即可。

c 引數值的有效性校驗

如:身份證號的校驗 ,設計的資料雖然符合身份證號的規則,但是並不是真實有效的身份證號;這種情況就要看身份證號的校驗規則是什麼樣了,一般都是用的現成的身份證號校驗器,但是有些是自己寫的校驗演算法,這個本人就遇到過這種問題---校驗演算法寫的不正確;

所以引數有效性的校驗就需要結合實際業務場景,判斷哪些資料是真實有效的資料,一定要確保所有真實有效的資料是可以驗證通過的。

d 引數組合校驗

不同的引數組合可能會存在不同的業務場景;

e 如果引數是列舉值,一定要各種列舉值都要測試,因為可能不同的列舉走的不同的業務流程;

f 引數值的預設值的校驗

參考介面文件。

g 某些引數具有特定的生成規則,要單獨針對生成規則設計用例,一定要保證真實有效的資料是可以驗證通過的。

如身份證號中間幾位 ******19860701****,本人就遇到過輸入******19861001****這種值校驗不正確;

2 介面邏輯

介面邏輯我用的設計方法是分支覆蓋--->路徑覆蓋--->場景覆蓋,同樣也是要結合實際業務場景,根本不發生的業務場景就是無效的測試用例。

a 第一步先把業務流程圖畫出來;

b 依據路程圖中的分支分別設計,不同分支不同的場景,這裡就要把異常的場景考慮進去;如介面超時,介面異常,介面請求成功或失敗,成功後怎麼處理,失敗後流程是否繼續執行,失敗後的資料怎麼處理;

以打款介面為例:

打款結果有打款成功或打款失敗,成功後怎麼處理,需要回寫打款成功狀態,失敗後怎麼處理,也需要回寫失敗狀態,失敗後的資料可以操作退回,也可以操作重新出款等等;如下

c 測試邏輯設計完成後要想一想不同的業務場景怎麼去測試,需要哪些人員協助,

如介面超時怎麼去測試,請求重複怎麼去測試,請求併發怎麼去測試

3 輸出

輸入結果:正常輸出和異常輸出,常用的方法有錯誤推斷法(列舉出程式中可能存在的錯誤或者異常,根據他們選擇測試用例)

4 以上都完成後,要結合實際的業務場景去掉冗餘的用例(即實際業務場景不存在的流程或者輸入資料);

5 如果業務流程涉及到狀態轉換,要單獨設計使用者---方法:狀態轉換圖;

6 涉及到多個不同金額或者手續費的計算,可能還會用到正交實驗法去設計用例;

7 另外,用例設計中還應當包含異常流程中產生的異常資料的處理流程;---通常所說的補償機制,這塊流程能大大的減輕人工運營的工作量,當然,這需要在做系統設計的時候就需要把這部分考慮進去;

介面測試用例設計思路 介面測試及用例設計

介面測試是測試系統元件間介面的一種測試。測試的重點是要檢查資料的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關係等。1 什麼是介面測試?介面測試是測試系統元件間介面的一種測試。測試的重點是要檢查資料的交換,傳遞和控制管理過程,以及系統間的相互邏輯依賴關係等。2 為什麼要做介面測試?介面測試主要...

介面測試用例設計

介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車,需要登入才能新增。也就是業務要求不支援遊客新增購物車功能,如果設計乙個沒有登入的使用者,然後去測試新增購物車介面,結果介面能新增到購物車,說明功能不正常,不符合需...

介面測試用例設計

主要是子模組或者子系統間互動並相互作用的部分。因此,可以分析,系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下,至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...