接口测试用例设计 - 实战篇

目录一．接口测试流程二．分析接口文档中哪些元素三．如何设计接口测试用例3.1 为什么要设计测试用例3.2 设计接口测试用例从哪些方面考虑四．常用的接口测试用例覆盖方法五．接口测试的接口优先级5.1 优先级--针对所有接口5.2 优先级--针对单个接口六．接口测试的设计思路分析七．接口测试返回结果的比较八．实践操作8.1接口样例8.2 接口测试用例设计8.3 个人对接口的认知一．接口测试流程1．需求

天上有时下牛

31649人浏览 · 2021-03-14 15:21:14

天上有时下牛 · 2021-03-14 15:21:14 发布

一．接口测试流程

1．需求讨论

2．需求评审

3．场景设计

4．数据准备

5．执行

二．分析接口文档中哪些元素

1．接口名称

2．接口地址

3．支持格式

4．请求方式

5．请求参数（参数名称、类型、是否必填、参数说明等）

6．返回参数（返回码、返回值信息、返回json串信息）

三．如何设计接口测试用例

3.1 为什么要设计测试用例

1．理清思路，避免漏测

2．提高测试效率

3．跟进测试进度

4．告诉领导做过

5．跟进重复性工作

3.2 设计接口测试用例从哪些方面考虑

1．功能

• 功能是否正常

• 功能是否按照接口文档实现

• 正常场景

• 异常场景

2．逻辑业务

是否依赖业务，比如是否登录成功

3．异常测试

（1）参数异常：

• 关键字参数、参数为空、多、少参数、错误参数

• 覆盖所有的必选参数，组合可选参数，参数有、无或为null，参数的顺序、个数、类型，

• 参数类型数值大小、输入的数值的范围，参数字串长短，参数包含特殊字符。

（2）数据异常：

• 关键字数据、数据为空、长度不一致、错误数据

4．安全

Cookie、header、唯一识别码

四．常用的接口测试用例覆盖方法

4.1 必需参数覆盖

对于接口的参数，接口文档一般都会说明哪些儿是必需的，哪儿是非必需的。对于必需的参数，一定要测试传参数和不传参数接口是否报错？

4.2 必需的参数各种情况覆盖

传非法的字符，特殊的字符，空值，超过边界的参数是否报错？错误信息是否正确？

4.3 非必需参数覆盖

一般接口对于非必需参数都不会做非正常性传值的判断，所以要测试合法的参数值，接口返回的内容是否正确。如果有接口文档说明对非必需参数做了非正常的验证的话，也要对其进行验证。

4.4 参数的组合覆盖

有些儿参数需要相互配合着才起作用，如“offset”和“count”组合起来进行翻页，这个时候要组合起来进行测试。

4.5 业务逻辑相关的覆盖

有些儿接口与业务逻辑关联密切，单独从接口角度测试，可能会遗漏掉一些儿因业务逻辑而产生的bug。所以如果和业务逻辑相关，也要考虑到业务逻辑相关的测试用例。

其实接口的测试用例差不多也就这些儿情况，也许有特殊的接口，到时候和产品，开发人员做好沟通，尽量先从接口层面保证质量。这样再从测试接口的应用层的时候，就可以少很多工作量，只注重样式和各个接口调用的配合就可以了。

五．接口测试的接口优先级

5.1 优先级--针对所有接口

1．暴露在外面的接口，因为通常该接口会给第三方调用

2．供系统内部调用的核心功能接口

3．供系统内部调用非核心功能接口

5.2 优先级--针对单个接口

1．正向用例优先测试,逆向用例次之(通常情况，非绝对)

2．是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制

六．接口测试的设计思路分析

6.1是否满足前提条件

有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。

逆向用例：

针对是否满足前置条件(假设为n个条件)，设计0~n条用例

6.2 是否携带默认值参数

正向用例：

带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例；

6.3 业务规则、功能需求

这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例

6.4 参数是否必填

逆向用例：

针对每个必填参数，都设计1条参数值为空的逆向用例

6.5 参数之间是否存在关联

有些参数彼此之间存在相互制约的关系

逆向用例：

根据实际情况，可能需要设计0~n条用例

6.6 参数数据类型限制

逆向用例：

针对每个参数都设计1条参数值类型不符的逆向用例

6.7 参数数据类型自身的数据范围值限制

正向用例：

针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例

逆向用例：

针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例

针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例

以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：

• 主流程测试用例：正常的主流程功能校验；

• 分支流测试用例：正常的分支流功能校验。

• 异常流测试用例：异常容错校验

七．接口测试返回结果的比较

对于接口返回值的校验问题，其目的一是验证代码正常，二是验证代码正确，个人总结：

1．首先比较返回码

2．然后比较返回值的完整性，即返回的key全不全

3．然后比较key的value数据类型(也就是jsonschema)

4．然后比较key对应的value值（也包括验证业务相关数据的value值）

然而，一般接口自动化，通常验证1、2两点即可，第3点根据公司测试周期来评估，而第4点，在功能测试中会验证value值的正确性。

注：jsonschema 是把返回的键和键的数据类型定义包，然后保存到文件中，然后和读取到的接口做键和值的类型做比较

八．实践操作

8.1接口样例

获取订单列表接口（多条件）

获取店铺指定期间的所有订单列表(多种条件组合)，默认根据日期倒序排序。

接口方向

客户端 -> 服务端

接口协议

接口地址：$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"

}

]

}

8.2 接口测试用例设计

用例	设计思路	传参
用例1	覆盖所有参数，正向用例	data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','orderStatus':'','orderTransactionType':'','payType':'','cashierId':'','billerId':'','pNo':'','pSize':''}
用例2	覆盖所有必填参数，正向用例	data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06'}
用例3	某一必填参数为空，逆向用例	data={'shopId':'','token':'bolixiyang','startDate':'2016-06-06'} data={'shopId':123,'token':'','startDate':'2016-06-06'} data={'shopId':123,'token':'bolixiyang','startDate':''}
用例4	多传一个参数、少传一个参数，逆向用例	data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','canshuduo':'123'} data={'shopId':123,'token':'bolixiyang'}
用例5	必填参数数据类型错误，数据值错误，逆向用例	data={'shopId':'123','token':'bolixiyang','startDate':'2016-06-06'} data={'shopId':666,'token':'bolixiyang','startDate':'2016-06-06'}
用例6	任意组合可选参数,正向用例	data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','cashierId':'','billerId':'','pNo':'','pSize':''}
用例7	参数数值的范围、参数默认值的范围、字符串的长度，逆向用例	data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','orderStatus':'0,1,2,10'}
用例8	与业务逻辑相关的，token为空或者错误，逆向用例	data={'shopId':123,'token':'','startDate':'2016-06-06'} data={'shopId':123,'token':'errorToken','startDate':'2016-06-06'}
用例9	字段的唯一性校验，如插入数据userName字段不能重复，发送两次请求，查看第二次返回结果	data={'userName':'bolixiyang'} data={'userName':'bolixiyang'}

8.3 个人对接口的认知

其实接口测试和其他测试一样，都是写用例，每次传递的参数发生不同的改变而已，我们真正的目的不是用接口测试去测试和覆盖所有内容，而是接口测试在实际工作中，可以在没有ui的情况下就可以直接介入测试，以及会使用接口测试。一般情况下，接口里不会做任何拦截，你传错了，可能也不会校验，校验一般都是在前端会加拦截器等内容，主要是接口能正常调起来就可以了。