．请求方式
posPayTotal
不填表示所有。
．跟进重复性工作
备注
int
Int
data={'shopId':'','token':'bolixiyang','startDate':'2016-06-06'}
．支持格式
设计接口测试用例从哪些方面考虑
否
逆向用例：
double
},
{
会员账号,如果是会员则显示手机号，为空时表示“非会员”
•覆盖所有的必选参数，组合可选参数，参数有、无或为null，参数的顺序、个数、类型，
'pNo':1,
onLinePay
'code':0,
billerId
根据实际情况，可能需要设计0~n条用例
业务逻辑相关的覆盖
•异常场景
data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','orderStatus':'','orderTransactionType':'','payType':'','cashierId':'','billerId':'','pNo':'','pSize':''}
与业务逻辑相关的，token为空或者错误，逆向用例
是
现金支付（已完成的合计）
1:已开单
．首先比较返回码
不填表示所有状态
．跟进测试进度
5:已退单
否
页码,从第1页开始，默认为1
double
data={'shopId':123,'token':'errorToken','startDate':'2016-06-06'}
参数数据类型自身的数据范围值限制
参数异常：
有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。
用例
用例8
是
正向用例：
．安全
订单查询时间字段。
有些儿参数需要相互配合着才起作用，如“offset”和“count”组合起来进行翻页，这个时候要组合起来进行测试。
'rCount':5,
否
．告诉领导做过
多传一个参数、少传一个参数，逆向用例
date
针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例
平台服务费合计
int
'posTotal':0,
有些儿接口与业务逻辑关联密切，单独从接口角度测试，可能会遗漏掉一些儿因业务逻辑而产生的bug。所以如果和业务逻辑相关，也要考虑到业务逻辑相关的测试用例。
数据类型
设备令牌。Token鉴权方式必填
是
是
正向用例：
数据异常：
．接口名称
double
．场景设计
接口协议：JSON
posPay
orderTitle
五．接口测试的接口优先级
．需求讨论
'orderTime':'2015-09-2913:44:26',
成功时，返回JSON数据包：
．返回参数
不填表示所有。
Cookie、header、唯一识别码
payType
．接口地址
任意组合可选参数,正向用例
4:退单中
．然后比较key的value数据类型(也就是jsonschem
是
条件
5:已退单
1:未完成，
cashPay
．请求参数
．是否满足前提条件>是否携带默认参值参数>参数是否必填>参数之间是否存在关联>参数数据类型限制>参数数据类型自身的数据范围值限制
HTTP请求方式：GET
double
接口样例
下单时间
datetime
POS支付（已完成的合计）
8:自助下单
•异常流测试用例：异常容错校验
•功能是否正常
覆盖所有参数，正向用例
platformTotalIncomePriceTotal
订单状态。
默认值
字段列表如下：
| string | ．然后比较返回值的完整性，即返回的key全不全 是否依赖业务，比如是否登录成功 string | 'data':{ 是 | 三．如何设计接口测试用例 逆向用例： 3:线上 | ||
| 是 | 4:退单中 shopId | ．执行 否 | 订单交易状态。 订单ID | ||
| endDate | 针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例 线上支付（已完成的合计） | ||||
| 接口方向 'orderTitle':'红塔山', •功能是否按照接口文档实现 对于接口返回值的校验问题，其目的一是验证代码正常，二是验证代码正确，个人总结： 多个状态之间以英文逗号分割 线上支付 |
data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','orderStatus':'0,1,2,10'}
字段名
接口测试用例设计
| POS支付 | |||||||||||||||
| { 2:派送中 ．理清思路，避免漏测 ．暴露在外面的接口，因为通常该接口会给第三方调用 查询日期 | |||||||||||||||
| 明细列表对象字段元素定义：
获取订单列表接口 •正常场景 1：下单时间（order_time） cashPayTotal | 参数之间是否存在关联 double | 消息响应 3:已完成（原已结帐） 针对是否满足前置条件(假设为n个条件)，设计0~n条用例 data={'shopId':123,'token':'bolixiyang','dataType':1,'startDate':'2016-06-06','endDate':'2016-06-07','cashierId':'','billerId':'','pNo':'','pSize':''} | |||||||||||||
| 参数的组合覆盖 2:POS 一般接口对于非必需参数都不会做非正常性传值的判断，所以要测试合法的参数值，接口返回的内容是否正确。如果有接口文档说明对非必需参数做了非正常的验证的话，也要对其进行验证。 传非法的字符，特殊的字符，空值，超过边界的参数是否报错？错误信息是否正确？ 为什么要设计测试用例 3：结算时间（shop_settle_time） | |||||||||||||||
| orderId | 二．分析接口文档中哪些元素 否 | Int | •主流程测试用例：正常的主流程功能校验； data={'shopId':123,'token':'bolixiyang','startDate':''} | ||||||||||||
| 用例2 | ．数据准备 针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例 数据类型 | data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06'} | |||||||||||||
| 收银员 | |||||||||||||||
| } •关键字参数、参数为空、多、少参数、错误参数 某一必填参数为空，逆向用例 | data={'shopId':123,'token':'bolixiyang'} | ||||||||||||||
| 是 | 用例3 | 必需参数覆盖 2:派送中 settlePrice | 带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计1条用例； 接口地址：$xxx_Home/xxx/鉴权前缀/xxxxx/getAllOrderList double | 3:已完成（原已结帐） 1:已开单 是 | 这里根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例 int | 必填项 | int | 商铺编号 | |||||||
| 否 | 优先级--针对单个接口 七．接口测试返回结果的比较 优先级--针对所有接口 逆向用例： 用例5 | 1:现金 是 | ．需求评审 1 | 针对每个参数都设计1条参数值类型不符的逆向用例 ．然后比较key对应的value值 { ．供系统内部调用非核心功能接口 明细列表 |
8:自助下单
orderStatus
查询结束日期。
客户端->服务端
用例4
对于接口的参数，接口文档一般都会说明哪些儿是必需的，哪儿是非必需的。对于必需的参数，一定要测试传参数和不传参数接口是否报错？
．异常测试
data={'shopId':'123','token':'bolixiyang','startDate':'2016-06-06'}
int
}
data={'shopId':123,'token':'','startDate':'2016-06-06'}
备注
．提高测试效率
用例9
是否携带默认值参数
lst
逆向用例：
交易金额
否
业务规则、功能需求
订单标题
'posTotal':0,
•关键字数据、数据为空、长度不一致、错误数据
然而，一般接口自动化，通常验证2两点即可，第3点根据公司测试周期来评估，而第4点，在功能测试中会验证value值的正确性。
备注
Status
每页记录数，默认为10
必需的参数各种情况覆盖
serviceAmount
•参数类型数值大小、输入的数值的范围，参数字串长短，参数包含特殊字符。
String
消息请求
mobile
订单状态。
字段名
默认值
orderTransactionType
data={'shopId':666,'token':'bolixiyang','startDate':'2016-06-06'}
dateType
．逻辑业务
否
默认值
string
否
设计思路
平台服务费
'orderTime':'2015-09-2911:37:58',
有些参数彼此之间存在相互制约的关系
消息请求样例：
cashierId
否
用例1
onLinePayTotal
double
startDate
传参
否
否
八．实践操作
以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：
int
9:待确认
double
是否满足前提条件
Date
object
四．常用的接口测试用例覆盖方法
double
获取店铺指定期间的所有订单列表(多种条件组合)，默认根据日期倒序排序。
数据类型
参数数据类型限制
double
其实接口测试和其他测试一样，都是写用例，每次传递的参数发生不同的改变而已，我们真正的目的不是用接口测试去测试和覆盖所有内容，而是接口测试在实际工作中，可以在没有ui的情况下就可以直接介入测试，以及会使用接口测试。一般情况下，接口里不会做任何拦截，你传错了，可能也不会校验，校验一般都是在前端会加拦截器等内容，主要是接口能正常调起来就可以了。
0:已预定
pSize
data={'shopId':123,'token':'bolixiyang','startDate':'2016-06-06','canshuduo':'123'}
逆向用例：
orderTotalPriceTotal
是
9:待确认
必填项
token
0:已预定
其实接口的测试用例差不多也就这些儿情况，也许有特殊的接口，到时候和产品，开发人员做好沟通，尽量先从接口层面保证质量。这样再从测试接口的应用层的时候，就可以少很多工作量，只注重样式和各个接口调用的配合就可以了。
参数是否必填
'lst':[
．功能
pNo
data={'userName':'bolixiyang'}
data={'shopId':123,'token':'','startDate':'2016-06-06'}
必填项
实收金额合计（已完成的合计）
现金支付
用例7
覆盖所有必填参数，正向用例
否
2:已完成(3:已完成, 5:已退单)
字段元素如下：
| 否 | 2：订单完成时间（order_finish_time） 支付方式。 参数数值的范围、参数默认值的范围、字符串的长度，逆向用例 | 接口协议 否 | 六．接口测试的设计思路分析 文章为作者独立观点，不代表股票交易接口观点 相关文章
股民评论
|