介面測試用例實際
設計思路
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) 實踐操作
介面樣例
獲取訂單列表介面（多條件）
獲取店鋪指定期間的所有訂單列表(多種條件組合)，預設根據日期倒序排序。
介面方向
客戶端 -> 服務端
介面協議
介面協議：json
http請求方式：get
訊息請求
字段列表如下：
欄位名資料型別
預設值必填項
備註shopid
int是
商鋪編號
token
string
條件裝置令牌。token鑑權方式必填
datetype
int1
否訂單查詢時間字段。
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=
&token=123411nmk515155&querydate=2015-10-10
訊息響應
字段元素如下：
欄位名資料型別
預設值必填項
備註ordertotalpricetotal
double
是實收金額合計（已完成的合計）
platformtotalincomepricetotal
double
是平台服務費合計
cashpaytotal
double
否現金支付（已完成的合計）
pospaytotal
double
否pos支付（已完成的合計）
onlinepaytotal
double
否線上支付（已完成的合計）
lstobject
是明細列表
明細列表物件字段元素定義：
欄位名資料型別
預設值必填項
備註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資料報：,]
}}用例設計
存在問題：
如上，還沒寫完就有40幾條用例了，要是介面引數再多點，介面數量再增加點，工作量可想而知，所以，問題來了，咋辦呢？
個人見解：
1、根據介面的使用物件(外部，系統內部)，有選擇的去、留部分用例
2、根據介面的是否核心介面，有選擇的去、留部分用例
3、根據引數說明，及實際情況，有選擇的去、留部分用例
例項：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 get 方法傳送請求,這種方式下請求引數需要包含在請求的 url 中。支援 http post 方法傳送請求,這種方式下請求引數需要包含在請求的 body 中。字元編碼 請求及返回結果都使用utf 8字符集進行編碼。公共引數 名稱 是否必須 描述signature...
介面測試用例
請求結構 請求方法 支援 http get 方法傳送請求,這種方式下請求引數需要包含在請求的 url 中。支援 http post 方法傳送請求,這種方式下請求引數需要包含在請求的 body 中。字元編碼 請求及返回結果都使用utf 8字符集進行編碼。公共引數 名稱 是否必須 描述signature...
測試用例 註冊介面測試用例點
使用者註冊 首先註冊頁面少不了各種輸入框，以及輸入框的各種格式，若只從使用者名稱與密碼的角度編寫用例，首先必須結合需求，若需求中明確規定了安全問題，郵箱，出生日期，位址，性別等等一系列輸入框的格式限制和字元要求的話，全部都要寫，主要以等價類劃分法，以及邊界值法來分析 1.各個輸入框的提示性文字是否存...