接口测试之用例设计实践总结

Posted 2021-04-24 51Testing软件测试网

　　设计思路

　　1) 优先级--针对所有接口

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

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

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

　　2) 优先级--针对单个接口

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

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

　　3) 设计分析

　　通常，设计接口测试用例需要考虑以下几个方面：

　　1、是否满足前提条件

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

　　逆向用例：

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

　　2、是否携带默认值参数

　　正向用例：

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

　　3、业务规则、功能需求

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

　　4、参数是否必填

　　逆向用例：

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

　　5、参数之间是否存在关联

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

　　逆向用例：

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

　　6、参数数据类型限制

　　逆向用例：

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

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

　　正向用例：

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

　　逆向用例：

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

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

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

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

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

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

　　4) 编写描述

　　尽量逻辑化，这样方便后续的维护

　　5) 实践操作

　　接口样例

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

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

　　接口方向

　　客户端->服务端

　　接口协议

　　接口协议：JSON

　　HTTP请求方式：GET

　　消息请求

　　字段列表如下：

　　消息请求样例：

　　?shopId=1111111111&token=123411nmk515155&queryDate=2015-10-10

　　消息响应

　　字段元素如下：

　　明细列表对象字段元素定义：

　　成功时，返回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-2913:44:26",

　　"orderId":"12345679282015092913440268141",

　　"mobile":"13424183952"

　　},

　　{

　　"orderTitle":"红塔山",

　　"settlePrice":7.5,

　　"cashTotal":7.5,

　　"posTotal":0,

　　"onLineTotal":0,

　　"orderTime":"2015-09-2911: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条，如果是手工测试，对于正向用例，根据等价类原理，可以制造一条数据，覆盖多条用例，当然，也可以冗余处理，即一条用例一条数据，这样的好处就是每次的验证点比较单一一点，比较有针对性。

　　问题

　　如果是自动化测试呢，这里是设计一个方法覆盖多条用例呢(如上，一条数据，覆盖多条用例)？还是一个方法覆盖一条用例呢？

　　我个人的答案是一个方法一条用例，你的呢？

 

推荐阅读

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击阅读☞

点击左下角“阅读原文”，查看更多内容！