接口测试实战(Ⅰ)接口测试分析

Posted 2021-04-24 八哥找bug

在之前的文章中，我们介绍了接口测试原理，也介绍了PostMan、Fiddler等工具的使用；从本期开始，我们将会带领大家从头开始进行一次接口测试的实战。

一.测试流程

项目过程中引入接口测试后，我们整体的测试流程大概如下图所示：

完成需求分析后，前端实现UI，后台实现接口，此时我们进行接口测试，并考虑对对应的接口实现自动化；在前端和后台联调数据的时候，我们设计功能性的测试用例；正式提测，我们就可以将重心转移到前端的测试（包括前端的UI、入参构造、功能等）。通过这样的安排将测试工作前移，提高测试工作效率和版本的质量。

接口测试虽然作为版本的一环，但是也是有一套完整的体系，有接口的功能测试、性能测试、安全测试；接口测试也是保证高复杂性系统质量的内在要求和低成本的经济利益的驱动作用下的最佳解决方案。

二.接口测试用例设计：

我们知道，接口实际上是系统与系统间的交互，接口测试本质上是验证在给定的入参下能否得到返回的回参，判断回参或接口进行的业务逻辑处理是否正确。对于有详细回参的接口，我们取返回值中的重要字段进行验证；而对于具体实现某些功能的接口，我们按照该接口实现的功能进行验证，

针对接口功能，我们可以从以下方面进行：

1.尽可能的全面覆盖入参的传入情况设计对应入参的测试用例：

①正常的入参  ②异常的入参 ③需要入参的传入空参数 ④同一个接口可以有多个类型的入参，覆盖每一种入参情况 ⑤结合业务逻辑考虑可能出现的情况

⑥考虑安全等其他因素的入参

2.当接口的功能为返回回参时：

①正常的入参/正常的重载入参/正常的可变入参给出正确的返回结果，按照接口定义的格式和业务逻辑返回

②异常的入参/空入参/针对安全或其他因素考虑的入参：接口内部可以引发异常，但是必须将异常情况封装，接口的返回值应该是封装后的错误码和异常信息；内部的异常则可以通过异常日志或其他方式进行记录；必须要严格禁止不将异常封装处理直接抛给上层的情况。

③结合实际逻辑进行考虑和分析，这种不仅仅是参数本身的验证，也要考虑业务逻辑的处理：比如电商类的APP，是否有验证商品金额和实际支付金额一致，如果没有验证，那么我恶意篡改参数，就可以以非常便宜的价格进行购物了。

3.当接口实现了某些具体的功能（比如更新数据库时），此时一般来说返回值就是很简单的code和一些处理信息，那么此时，我们直接验证该功能的实现情况即可。

接口的性能、安全测试则与前端区别不大，大部分情况下只需要将前端传入的参数或者压力条件直接传给接口即可。由于直接与服务器交互，接口的性能、安全测试实现起来甚至比前端的更加轻松。

接口自动化测试则是自动化测试中低成本高收益的代表，特别是在多系统多平台的交互架构下；接口自动化测试可以采用Jmeter等工具实现，也可以自己编写自动化框架或脚本实现。

三.一个具体接口的测试分析:

我们定义如下API，并基于该API进行接口测试的分析

功能：根据APP传入的条件查询产品，返回商品的基础数据

URL：/Goods/GetGoodsList

访问方式：POST

入参类型：放于请求报文中，格式为Json

入参1：入参全为空，当入参为空时按照上架时间进行降序排序，取最新上架的产品进行分页处理后返回

入参2：

   SearchKeys: 我亲爱的你, //用户输入的查询数据，不能为空

    PageSize: 10,//分页的Page大小，默认入参为10，前端传入

    PageIndex: 1,//分页的PageIndex，第几页，前端传入

    OrderBy: 0,//排序条件：0-销量，1-价格，由前端传入，前端的通过单选控件实现

    Method: ASC//排序方式：ASC-升序，DESC-降序，前端通过单选控件实现

两种入参均按照这个格式返回值：

{

    "data": [{

        "CommodityID": 15962,//产品ID

        "CategoryID": 146,//分类ID

        "CommodityName": "韩国Whoo后拱辰享美黄金气垫粉底液#21 SPF50+/PA+++15g*2亮白色（效期20年5月）",//产品名

        "SalePrice": 219.00,//售价

        "SaleAmount": 9//销量

    }, {

        "CommodityID": 15961,

        "CategoryID": 108,

        "CommodityName": "【2袋装】澳洲德运Devondale高钙全脂成人牛奶粉1KG/包（效期19年4月） （西藏、新疆不发货）",

        "Thumb": "http://qiniukzg.zhangguishangcheng.net/8adf3a2f-e1f9-402c-9902-ec4edbe25c53.jpg",

        "SalePrice": 145.00,

        "SaleAmount": 200

    }],

    "records": 0,

    "status": "success",//返回状态，success-成功；failed-出现异常或失败时返回

    "message": null //返回封装后的异常信息，当为空时表示没有返回异常，就是不要返回的code

}

代码处理逻辑：按照分页的页面和大小，从Commodity表一张表中直接查询到对应数据，查询结果进行实例化为Json处理后返回，对应字段均存在Commodity表中

那么我们整体的测试思路如下：

1.功能测试：

我们按照对入参的分析，简单划分如下：

1.不带参数

2.构造任意参数

3.按照接口文档的定义，针对每个入参分别构造参数进行访问

具体的测试点可以参考下面的图：

接下来，我们可以根据这个思路进行用例的细化与更多覆盖面的分析，或者组织研发、测试同学进行测试用例的评审，也可以结合迭代系统中相关模块出现的Bug，来完善测试用例。

八哥找bug全力打造测试圈UI自动化，接口自动化交流平台；开展Python技术分享以及各类优质书籍推荐。关注八哥找bug，咱们一起玩转测试，走向人生巅峰！

八哥找bug

长按二维码，关注八哥找bug