接口测试用例设计思想

设计思路

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

接口测试用例设计思想相关推荐

软件测试之接口测试用例设计，全网独一份
1.接口测试用例设计简介我们对系统的需求分析完成之后,即可设计对应的接口测试用例,然后用接口测试用例进行接口测试.接口测试用例的设计也需要用到黑盒测试方法,其与功能测试用例设计的方法类似,接口测试用 ...
接口测试用例设计实践总结
接口测试用例设计实践总结 by:授客 QQ:1033553122 设计思路 1) 优先级--针对所有接口 1.暴露在外面的接口,因为通常该接口会给第三方调用: 2.供系统内部调用的核心功能接口: ...
接口测试用例设计的一点总结
背景最近项目中也一直在推动接口测试,中途也遇到很多的问题:从最开始的接口文档管理,接口测试框架的选型,到后续接口测试用例的维护问题.最近在想接口测试的一个覆盖度问题.谈到覆盖度,又得回到接口测试的用 ...
软件测试接口测试接口测试的必备条件接口测试用例设计 HTTP协议基础 Postman
文章目录 1 接口测试概述 1.1 接口测试的定义 1.2 接口测试的范围和适用场合 2 接口测试的必备条件 2.1 接口测试的要求 2.2 标准和规范的接口文档 2.3 如何获取接口信息 3 接口测 ...
软件测试接口测试用例设计
接口测试用例设计随着测试分析和分层测试的深化,"接口测试"出现在我们视野的频次越来越高.那么接口测的用例设计常用哪些方法呢?本文将详细描述. 接口测试 1.1 接口测试接口: ...
全网最详细软件测试接口测试用例设计-怎么编写-模板（最详全）
目录:导读一.前言 1.接口测试 2.接口测试发现的典型问题二.接口测试用例设计 1.针对输入设计 1.1.数值型 1.2.字符串型 1.3.数组或链表类型三.针对逻辑设计 1.约束条件分析 2 ...
（转）接口测试用例设计
随着测试分析和分层测试的深化,"接口测试"出现在我们视野的频次越来越高.那么接口测的用例设计常用哪些方法呢?本文将详细描述. 1 接口测试 1.1 接口测试接口:主要是子模块 ...
【转】接口测试用例设计
文章图片参考源地址: http://url.cn/5ZM37wg 随着测试分析和分层测试的深化,"接口测试"出现在我们视野的频次越来越高.那么接口测的用例设计常用哪些方法呢?本文将 ...
(转)【腾讯 TMQ】接口测试用例设计
导语这是我在其他的开源社区看到的一篇分享帖子.这篇文章的目的只是为大家提供一个思路,但是实现成本太高了,因为一个接口设计的接口测试用例很多,一般公司的接口数量几百到上千不等,每一个接口都设计这么多测 ...

接口测试用例设计思想

接口测试用例设计思想相关推荐

最新文章

热门文章