接口测试用例设计实践总结(转载)
设计思路
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 |
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"
}
]
}
}
用例设计
存在问题:
如上,还没写完就有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
相关文章
- javaWeb学习总结(3)- Servlet总结(servlet的主要接口、类)
- 接口自动化测试:Postman实战教程
- Java 接口
- 【软件测试】python接口自动化测试编写脚本,资深测试总结方法,你的实用宝典......
- 【软件测试】资深测试的总结,接口测试中的最常见的几个错误......
- 【自动化测试】如何做好python接口/web自动化测试?看看8年测试老鸟的总结......
- 干货 | Dubbo 接口测试原理及多种方法实践总结
- C#【高级篇】 C# 接口(Interface)
- 【软件测试】接口自动化测试你真的会做吗?资深测试工程师的总结......
- 全网最完整,接口测试总结彻底打通接口自动化大门,看这篇就够了......
- 【软件测试】接口测试和接口性能测试,资深测试老鸟的总结......
- Jmeter接口测试流程详解(中科软测认证中心)
- 接口测试方案(接口测试思路)
- PHP 开发 APP 接口 学习笔记与总结 - APP 接口实例 [7] APP 错误日志接口
- PHP 开发 APP 接口 学习笔记与总结 - APP 接口实例 [6] 版本升级接口开发
- PHP 开发 APP 接口 学习笔记与总结 - APP 接口实例 [2] 首页 APP 接口开发方案 ① 读取数据库方式
- PHP 开发 APP 接口 学习笔记与总结 - APP 接口实例 [1] 单例模式连接数据库
- PHP 开发 APP 接口 学习笔记与总结 - 静态缓存
- 华为支付购买token的verify接口报错Token is expired or invalid
- 基于layui的框架模版,采用模块化设计,接口分离,组件化思想
- linux seq_file 接口
- java Map接口
- 如何设计 MVVM 架构的 Repository 接口
- ZeroMQ(ZMQ)函数接口英汉直译
- 在云服务上做接口压测心得总结
- ESP32使用TCP HTTP访问API接口JSON解析获取数据
- 总结一下FC线的接口
- DDR3 AXI4接口读写回环测试
- 在微信小程序上做一个「博客园年度总结」:解决前端获取接口数据太慢的一种思路
- go语言基础(四)包,接口
- ABP 调用swagger里面的登录接口报错400,/api/TokenAuth/Authenticate ,调用post接口就报错400