設計思路
1) 優先級--針對所有接口
1、暴露在外面的接口，因為通常該接口會給第三方調用；
2、供系統內部調用的核心功能接口；
3、供系統內部調用非核心功能接口；
2) 優先級--針對單個接口
1、正向用例優先測試,逆向用例次之(通常情況，非絕對)；
2、是否滿足前提條件 > 是否攜帶默認參值參數 > 參數是否必填 > 參數之間是否存在關聯 > 參數數據類型限制 >參數數據類型自身的數據范圍值限制
3) 設計分析
通常，設計接口測試用例需要考慮以下幾個方面：
1、是否滿足前提條件
有些接口需要滿足前置條件，才可成功獲取數據。常見的，需要登陸Token。
逆向用例：
針對是否滿足前置條件(假設為n個條件)，設計0~n條用例
2、是否攜帶默認值參數
正向用例：
帶默認值的參數都不填寫、不傳參，必填參數都填寫正確且存在的“常規”值，其它不填寫，設計1條用例；
3、業務規則、功能需求
這里根據實際情況，結合接口參數說明，可能需要設計n條正向用例和逆向用例
5、參數是否必填
逆向用例：
針對每個必填參數，都設計1條參數值為空的逆向用例
4、參數之間是否存在關聯
有些參數彼此之間存在相互制約的關系
逆向用例：
根據實際情況，可能需要設計0~n條用例
5、參數數據類型限制
逆向用例：
針對每個參數都設計1條參數值類型不符的逆向用例
6、參數數據類型自身的數據范圍值限制
正向用例：
針對所有參數，設計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幾條用例了，要是接口參數再多點，接口數量再增加點，工作量可想而知，所以，問題來了，咋辦呢？
個人見解：
1、根據接口的使用對象(外部，系統內部)，有選擇的去、留部分用例
2、根據接口的是否核心接口，有選擇的去、留部分用例
3、根據參數說明，及實際情況，有選擇的去、留部分用例
實例：
上例這個接口，是供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類型最大值
略去的用例部分（參數值超過類型最大值）
理由：
1、內部調用，參數值不是外部手動輸入的，輸入數據長度、值大小可控，當然如果數據一直增長，那再大的類型可能都無法保證不超出，比如自動增長的商鋪id
2、部分參數的參數值是自定義的，比如 訂單時間類型，就那幾種，除非傳錯了，不然不可能超出范圍
最后簡化后的用例數差不多28條，如果是手工測試，對於正向用例，根據等價類原理，可以制造一條數據，覆蓋多條用例，當然，也可以冗余處理，即一條用例一條數據，這樣的好處就是每次的驗證點比較單一一點，比較有針對性。
問題
如果是自動化測試呢，這里是設計一個方法覆蓋多條用例呢(如上，一條數據，覆蓋多條用例)？還是一個方法覆蓋一條用例呢？
我個人的答案是一個方法一條用例，你的呢？
轉載：http://blog.sina.com.cn/s/blog_13cc013b50102w1ot.html
by:授客 QQ：1033553122