接口測試用例設計html
設計思路api
1) 優先級--針對全部接口app
一、暴露在外面的接口，由於一般該接口會給第三方調用；測試
二、供系統內部調用的核心功能接口；url
三、供系統內部調用非核心功能接口；spa
2) 優先級--針對單個接口.net
一、正向用例優先測試,逆向用例次之(一般狀況，非絕對)；設計
二、是否知足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 >參數數據類型自身的數據範圍值限制code
3) 設計分析orm
一般，設計接口測試用例須要考慮如下幾個方面：
一、是否知足前提條件
有些接口須要知足前置條件，纔可成功獲取數據。常見的，須要登錄Token。
逆向用例：
針對是否知足前置條件(假設爲n個條件)，設計0~n條用例
二、是否攜帶默認值參數
正向用例：
帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的「常規」值，其它不填寫，設計1條用例；
三、業務規則、功能需求
這裏根據實際狀況，結合接口參數說明，可能須要設計n條正向用例和逆向用例
五、參數是否必填
逆向用例：
針對每一個必填參數，都設計1條參數值爲空的逆向用例
四、參數之間是否存在關聯
有些參數彼此之間存在相互制約的關係
逆向用例：
根據實際狀況，可能須要設計0~n條用例
五、參數數據類型限制
逆向用例：
針對每一個參數都設計1條參數值類型不符的逆向用例
六、參數數據類型自身的數據範圍值限制
正向用例：
針對全部參數，設計1條每一個參數的參數值在數據範圍內爲最大值的正向用例
逆向用例：
針對每一個參數(假設n個)，設計n條每一個參數的參數值都超出數據範圍最大值的逆向用例
針對每一個參數(假設n個)，設計n條每一個參數的參數值都小於數據範圍最小值的逆向用例
以上幾個方面考慮全的話，基本能夠作到以下幾個方面的覆蓋：
主流程測試用例：正常的主流程功能校驗；
分支流測試用例：正常的分支流功能校驗。
異常流測試用例：異常容錯校驗
4) 編寫描述
儘可能邏輯化，這樣方便後續的維護
5) 實踐操做
接口樣例
獲取訂單列表接口（多條件）
獲取店鋪指按期間的全部訂單列表(多種條件組合)，默認根據日期倒序排序。
接口方向
客戶端 -> 服務端
接口協議
接口地址：$xxx_Home/xxx/鑑權前綴/xxxxx/getAllOrderList
接口協議：JSON
HTTP請求方式：GET
消息請求
字段列表以下：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備註 |
| shopId |
int |
|
是 |
商鋪編號 |
| token |
string |
|
條件 |
設備令牌。Token鑑權方式必填 |
| dateType |
int |
1 |
否 |
訂單查詢時間字段。 1：下單時間（order_time） 2：訂單完成時間（order_finish_time） 3：結算時間（shop_settle_time） |
| startDate |
date |
|
是 |
查詢日期 |
| endDate |
Date |
|
否 |
查詢結束日期。 |
| orderStatus |
String |
|
否 |
訂單狀態。 不填表示全部狀態 多個狀態之間以英文逗號分割 0:已預約 1:已開單 2:派送中 3:已完成（原已結賬） 4:退單中 5:已退單 8:自助下單 9:待確認 |
| orderTransactionType |
Int |
|
否 |
訂單交易狀態。 不填表示全部。 1:未完成， 2:已完成(3:已完成, 5:已退單) |
| payType |
int |
|
否 |
支付方式。 不填表示全部。 1:現金 2:POS 3:線上 |
| cashierId |
int |
|
否 |
收銀員 |
| billerId |
int |
|
否 |
導購員 |
| pNo |
int |
|
否 |
頁碼,從第1頁開始，默認爲1 |
| pSize |
int |
|
否 |
每頁記錄數，默認爲10 |
消息請求樣例：
?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10
消息響應
字段元素以下：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備註 |
| orderTotalPriceTotal |
double |
|
是 |
實收金額合計（已完成的合計） |
| platformTotalIncomePriceTotal |
double |
|
是 |
平臺服務費合計 |
| cashPayTotal |
double |
|
否 |
現金支付（已完成的合計） |
| posPayTotal |
double |
|
否 |
POS支付（已完成的合計） |
| onLinePayTotal |
double |
|
否 |
線上支付（已完成的合計） |
| lst |
object |
|
是 |
明細列表 |
明細列表對象字段元素定義：
| 字段名 |
數據類型 |
默認值 |
必填項 |
備註 |
| orderId |
string |
|
是 |
訂單ID |
| orderTitle |
string |
|
是 |
訂單標題 |
| mobile |
string |
|
否 |
會員帳號,若是是會員則顯示手機號，爲空時表示「非會員」 |
| settlePrice |
double |
|
是 |
交易金額 |
| orderTime |
datetime |
|
是 |
下單時間 |
| serviceAmount |
double |
|
是 |
平臺服務費 |
| Status |
Int |
|
是 |
訂單狀態。 0:已預約 1:已開單 2:派送中 3:已完成（原已結賬） 4:退單中 5:已退單 8:自助下單 9:待確認 |
| cashPay |
double |
|
否 |
現金支付 |
| posPay |
double |
|
否 |
POS支付 |
| onLinePay |
double |
|
否 |
線上支付 |
成功時，返回JSON數據包：
{
"code": 0,
"msg": "查詢訂單列表成功！",
"data": {
"pNo": 1,
"rCount": 5,
"orderTotalPriceTotal": 23.3,
"platformTotalIncomePriceTotal": 0,
"lst": [
{
"orderTitle": "kouxiangtang",
"settlePrice": 15.89,
"cashTotal": 15.89,
"posTotal": 0,
"onLineTotal": 0,
"orderTime": "2015-09-29 13:44:26",
"orderId": "12345679282015092913440268141",
"mobile": "13424183952"
},
{
"orderTitle": "紅塔山",
"settlePrice": 7.5,
"cashTotal": 7.5,
"posTotal": 0,
"onLineTotal": 0,
"orderTime": "2015-09-29 11:37:58",
"orderId": "12345679282015092911370588273"
}
]
}
}
用例設計
存在問題：
如上，還沒寫完就有40幾條用例了，要是接口參數再多點，接口數量再增長點，工做量可想而知，因此，問題來了，咋辦呢？
我的看法：
一、根據接口的使用對象(外部，系統內部)，有選擇的去、留部分用例
二、根據接口的是否核心接口，有選擇的去、留部分用例
三、根據參數說明，及實際狀況，有選擇的去、留部分用例
實例：
上例這個接口，是供app、商鋪後臺調用的，且爲系統內部調用，因此，如下用例可酌情略去：
test-E-按商鋪id查詢-商鋪id非int型
test-E-按設備token查詢-token非string類型
test-E-按訂單時間類型查詢-時間類型非int型
test-E-按起始日期查詢-時間類型非date型
test-E-按結束日期查詢-時間類型非date型
test-E-按訂單狀態查詢-訂單狀態非string類型
test-E-按交易狀態查詢-交易狀態非int型
test-E-按支付方式查詢-支付方式非int值
test-E-按收銀員查詢-收銀員id非int值
test-E-按導購員查詢-導購員id非int值
test-E-按頁碼查詢-頁碼非int值
理由：
這個接口是給其它開發於系統內部調用的，開發過程當中，開發者確定須要調用這些接口，若是類型錯了，他們也就獲取不到預期的數據，這些錯誤，他們確定能夠發現，因此，他們傳遞的參數值通常能保證類型正確。
test-N-按參數類型最大值查詢 全部參數
test-E-按商鋪id查詢-商鋪id超過類型範圍值
test-E-按訂單狀態查詢-訂單狀態值超過類型最大值
test-E-按交易狀態查詢-交易狀態值超過int類型最大值
略去的用例部分（參數值超過類型最大值）
理由：
一、內部調用，參數值不是外部手動輸入的，輸入數據長度、值大小可控，固然若是數據一直增加，那再大的類型可能都沒法保證不超出，好比自動增加的商鋪id
二、部分參數的參數值是自定義的，好比 訂單時間類型，就那幾種，除非傳錯了，否則不可能超出範圍
最後簡化後的用例數差很少28條，若是是手工測試，對於正向用例，根據等價類原理，能夠製造一條數據，覆蓋多條用例，固然，也能夠冗餘處理，即一條用例一條數據，這樣的好處就是每次的驗證點比較單一一點，比較有針對性。