摘自：https://www.cnblogs.com/finer/p/7487336.html
設計思路
1)???優(yōu)先級--針對所有接口
1、暴露在外面的接口，因為通常該接口會給第三方調用；
2、供系統(tǒng)內(nèi)部調用的核心功能接口；
3、供系統(tǒng)內(nèi)部調用非核心功能接口；
2)???優(yōu)先級--針對單個接口
1、正向用例優(yōu)先測試,逆向用例次之(通常情況，非絕對)；
2、是否滿足前提條件?>?是否攜帶默認參值參數(shù)?>?參數(shù)是否必填?>?參數(shù)之間是否存在關聯(lián)?>?參數(shù)數(shù)據(jù)類型限制?>參數(shù)數(shù)據(jù)類型自身的數(shù)據(jù)范圍值限制
3)???設計分析
通常，設計接口測試用例需要考慮以下幾個方面：
1、是否滿足前提條件
有些接口需要滿足前置條件，才可成功獲取數(shù)據(jù)。常見的，需要登陸Token。
逆向用例：
針對是否滿足前置條件(假設為n個條件)，設計0~n條用例
2、是否攜帶默認值參數(shù)
正向用例：
帶默認值的參數(shù)都不填寫、不傳參，必填參數(shù)都填寫正確且存在的“常規(guī)”值，其它不填寫，設計1條用例；
3、業(yè)務規(guī)則、功能需求
這里根據(jù)實際情況，結合接口參數(shù)說明，可能需要設計n條正向用例和逆向用例
5、參數(shù)是否必填
逆向用例：
針對每個必填參數(shù)，都設計1條參數(shù)值為空的逆向用例
4、參數(shù)之間是否存在關聯(lián)
有些參數(shù)彼此之間存在相互制約的關系
逆向用例：
根據(jù)實際情況，可能需要設計0~n條用例
5、參數(shù)數(shù)據(jù)類型限制
逆向用例：
針對每個參數(shù)都設計1條參數(shù)值類型不符的逆向用例
6、參數(shù)數(shù)據(jù)類型自身的數(shù)據(jù)范圍值限制
正向用例：
針對所有參數(shù)，設計1條每個參數(shù)的參數(shù)值在數(shù)據(jù)范圍內(nèi)為最大值的正向用例
逆向用例：
針對每個參數(shù)(假設n個)，設計n條每個參數(shù)的參數(shù)值都超出數(shù)據(jù)范圍最大值的逆向用例
針對每個參數(shù)(假設n個)，設計n條每個參數(shù)的參數(shù)值都小于數(shù)據(jù)范圍最小值的逆向用例
以上幾個方面考慮全的話，基本可以做到如下幾個方面的覆蓋：
主流程測試用例：正常的主流程功能校驗；
分支流測試用例：正常的分支流功能校驗。
異常流測試用例：異常容錯校驗
4)???編寫描述
盡量邏輯化，這樣方便后續(xù)的維護
5)???實踐操作
接口樣例
獲取店鋪指定期間的所有訂單列表(多種條件組合)，默認根據(jù)日期倒序排序。
客戶端?->?服務端
接口地址：$xxx_Home/xxx/鑒權前綴/xxxxx/getAllOrderList
接口協(xié)議：JSON
HTTP請求方式：GET
字段列表如下：
字段名數(shù)據(jù)類型默認值必填項?備注
shopIdint?是商鋪編號
tokenstring?條件設備令牌。Token鑒權方式必填
dateTypeint1否訂單查詢時間字段。
1：下單時間（order_time）
2：訂單完成時間（order_finish_time）
3：結算時間（shop_settle_time）
startDatedate?是查詢?nèi)掌?/p>
endDateDate?否查詢結束日期。
orderStatusString?否訂單狀態(tài)。
不填表示所有狀態(tài)
多個狀態(tài)之間以英文逗號分割
0:已預定
1:已開單
2:派送中
3:已完成（原已結帳）
4:退單中
5:已退單
8:自助下單
9:待確認
orderTransactionTypeInt?否訂單交易狀態(tài)。
不填表示所有。
1:未完成，
2:已完成(3:已完成, 5:已退單)
payTypeint?否支付方式。
不填表示所有。
1:現(xiàn)金
2:POS
3:線上
cashierIdint?否收銀員
billerIdint?否導購員
pNoint?否頁碼,從第1頁開始，默認為1
pSizeint?否每頁記錄數(shù)，默認為10
消息請求樣例：
?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10
字段元素如下：
字段名數(shù)據(jù)類型默認值必填項?備注
orderTotalPriceTotaldouble?是實收金額合計（已完成的合計）
platformTotalIncomePriceTotaldouble?是平臺服務費合計
cashPayTotaldouble?否現(xiàn)金支付（已完成的合計）
posPayTotaldouble?否POS支付（已完成的合計）
onLinePayTotaldouble?否線上支付（已完成的合計）
lstobject?是明細列表
明細列表對象字段元素定義：
字段名數(shù)據(jù)類型默認值必填項?備注
orderIdstring?是訂單ID
orderTitlestring?是訂單標題
mobilestring?否會員賬號,如果是會員則顯示手機號，為空時表示“非會員”
settlePricedouble?是交易金額
orderTimedatetime?是下單時間
serviceAmountdouble?是平臺服務費
StatusInt?是訂單狀態(tài)。
0:已預定
1:已開單
2:派送中
3:已完成（原已結帳）
4:退單中
5:已退單
8:自助下單
9:待確認
cashPaydouble?否現(xiàn)金支付
posPaydouble?否POS支付
onLinePaydouble?否線上支付
成功時，返回JSON數(shù)據(jù)包：
{
????"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幾條用例了，要是接口參數(shù)再多點，接口數(shù)量再增加點，工作量可想而知，所以，問題來了，咋辦呢？
個人見解：
1、根據(jù)接口的使用對象(外部，系統(tǒng)內(nèi)部)，有選擇的去、留部分用例
2、根據(jù)接口的是否核心接口，有選擇的去、留部分用例
3、根據(jù)參數(shù)說明，及實際情況，有選擇的去、留部分用例
實例：
上例這個接口，是供app、商鋪后臺調用的，且為系統(tǒng)內(nèi)部調用，所以，以下用例可酌情略去：
test-E-按商鋪id查詢-商鋪id非int型
test-E-按設備token查詢-token非string類型
test-E-按訂單時間類型查詢-時間類型非int型
test-E-按起始日期查詢-時間類型非date型
test-E-按結束日期查詢-時間類型非date型
test-E-按訂單狀態(tài)查詢-訂單狀態(tài)非string類型
test-E-按交易狀態(tài)查詢-交易狀態(tài)非int型
test-E-按支付方式查詢-支付方式非int值
test-E-按收銀員查詢-收銀員id非int值
test-E-按導購員查詢-導購員id非int值
test-E-按頁碼查詢-頁碼非int值
理由：
這個接口是給其它開發(fā)于系統(tǒng)內(nèi)部調用的，開發(fā)過程中，開發(fā)者肯定需要調用這些接口，如果類型錯了，他們也就獲取不到預期的數(shù)據(jù)，這些錯誤，他們肯定可以發(fā)現(xiàn)，所以，他們傳遞的參數(shù)值一般能保證類型正確。
test-N-按參數(shù)類型最大值查詢????所有參數(shù)
test-E-按商鋪id查詢-商鋪id超過類型范圍值
test-E-按訂單狀態(tài)查詢-訂單狀態(tài)值超過類型最大值
test-E-按交易狀態(tài)查詢-交易狀態(tài)值超過int類型最大值
略去的用例部分（參數(shù)值超過類型最大值）
理由：
1、內(nèi)部調用，參數(shù)值不是外部手動輸入的，輸入數(shù)據(jù)長度、值大小可控，當然如果數(shù)據(jù)一直增長，那再大的類型可能都無法保證不超出，比如自動增長的商鋪id
2、部分參數(shù)的參數(shù)值是自定義的，比如?訂單時間類型，就那幾種，除非傳錯了，不然不可能超出范圍
最后簡化后的用例數(shù)差不多28條，如果是手工測試，對于正向用例，根據(jù)等價類原理，可以制造一條數(shù)據(jù)，覆蓋多條用例，當然，也可以冗余處理，即一條用例一條數(shù)據(jù)，這樣的好處就是每次的驗證點比較單一一點，比較有針對性。
問題
如果是自動化測試呢，這里是設計一個方法覆蓋多條用例呢(如上，一條數(shù)據(jù)，覆蓋多條用例)？還是一個方法覆蓋一條用例呢？
我個人的答案是一個方法一條用例，你的呢？
