接口測試用例設計實踐總結

設計思路

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

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

支付方式。

1:現金

2:POS

3:線上

cashierId

收銀員

billerId

導購員

pNo

頁碼,從第1頁開始，預設為1

pSize

每頁記錄數，預設為10

消息請求樣例：

字段元素如下：

orderTotalPriceTotal

double

實收金額合計（已完成的合計）

platformTotalIncomePriceTotal

平台服務費合計

cashPayTotal

現金支付（已完成的合計）

posPayTotal

POS支付（已完成的合計）

onLinePayTotal

線上支付（已完成的合計）

lst

object

明細清單

明細清單對象字段元素定義：

orderId

訂單ID

orderTitle

訂單标題

mobile

會員賬号,如果是會員則顯示手機号，為空時表示“非會員”

settlePrice

交易金額

orderTime

datetime

下單時間

serviceAmount

平台服務費

Status

cashPay

現金支付

posPay

POS支付

onLinePay

線上支付

成功時，傳回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,

                "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