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