软件测试--接口测试

目录

1.接口测试的概念

2接口测试

[2.1 概念](#2.1 概念)

[2.2 接口组成](#2.2 接口组成)

[2.3 接口测试重要性](#2.3 接口测试重要性)

[2.4 如何执行接口测试](#2.4 如何执行接口测试)

[2.4.1 接口用例的编写](#2.4.1 接口用例的编写)

[2.4.2 结合业务逻辑来设计用例](#2.4.2 结合业务逻辑来设计用例)

1.接口测试的概念

接口一般来说有两种，一种是程序内部的接口，一种是系统对外的接口。

程序内部的接口：方法与方法之间，模块与模块之间的交互，程序内部抛出的接口，比如贴吧系统，有登录模块、发帖模块等等，那你要发帖就必须先登录，要发帖就得登录，那么这两个模块就得有交互，它就会抛出⼀个接口，供内部系统进行调用。

系统对外的接口：比如你要从别的网站或服务器上获取资源或信息，别人肯定不会把数据库共享给 你，他只能给你提供⼀个他们写好的方法来获取数据，你引用他提供的接口就能使用他写好的方法， 从而达到数据共享的目的，比如说咱们用的app、网址这些它在进行数据处理的时候都是通过接口来进行调用的。 接口类型有很多，如HTTP API接口、RPC等等，接下来我们基于HTTP API接口继续讲解。

2接口测试

2.1 概念

接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

简而言之，所谓接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性要求。 其实接口测试很简单，比一般的功能测试还简单（非官方表述，有感而发），因为功能测试是从页面输入值，然后通过点击按钮或链接等传值给后端，而且功能测试还要测UI、前端交互等功能，但接口测试没有页面，它是通过接口规范文档上的调用地址、请求参数，拼接报文，然后发送请求，检查返回结果，所以它只需测⼊参和出参就行了，相对来说简单了不少。

2.2 接口组成

接口文档应该包含以下内容：

• 接口说明 • 调用url

• 请求方法（get\post）

• 请求参数、参数类型、请求参数说明

• 返回参数说明

由接口文档可知，接口至少应有请求地址、请求方法、请求参数（入参和出参）组成，部分接口有请求头 header 。

标头(header)：是服务器以HTTP协议传HTML资料到浏览器前所送出的字符串，在标头与HTML文件之间尚需空一行分隔，⼀般存放 cookie 、 token 等信息

header和入参有什么关系？它们不都是发送到服务器的参数吗？

它们确实都是发送到服务器里的参数，但它们是有区别的，header里存放的参数一般存放的是一些校验信息，比如cookie，它是为了校验这个请求是否有权限请求服务器，如果有，它才能请求服务器， 然后把请求地址连同入参一起发送到服务器，然后服务器会根据地址和入参来返回出参。也就是说， 服务器是先接受header信息进行判断该请求是否有权限请求，判断有权限后，才会接受请求地址和入参的。

2.3 接口测试重要性

接口其实就是前端页面或APP等调用与后端做交互用的，有人会问，功能测试都测好了，为什么还要测接口呢？

先举个栗子：

比如测试用户注册功能，规定用户名为6~18个字符，包含字母（区分大小写）、数字、下划线。 首先功能测试时肯定会对用户名规则进行测试时，比如输⼊20个字符、输入特殊字符等，但这些可能只是在前端做了校验，后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢？试想⼀下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录可能会通过SQL注⼊等手段来随意登录，甚至可以获取管理员权限， 那这样不是很恐怖？

所以，接口测试的必要性就体现出来了：

• 可以发现很多在页面上操作发现不了的bug

• 检查系统的异常处理能力

• 检查系统的安全性、稳定性

• 前端随便变，接口测好了，后端不用变

2.4 如何执行接口测试

在进行接口测试前，还需要了解：

1. get和post请求

get和post是常见的请求方法。如果是get请求的话，直接在浏览器里输入就行了，只要在浏览器里面直接能请求到的，都是get请求，如果是post的请求的话，就不行了，就得借助工具来发送。

2. http状态码

每发出⼀个http请求之后，都会有⼀个响应，http本身会有一个状态码，来标示这个请求是否成功， 常见的状态码有以下几种：

• 200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返 回了。

• 300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。

• 400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访 问这个页面，404代表没有这个页面

• 500 5开头的代表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果

接口测试分两步走：通过接口设计用例+结合业务逻辑来设计用例

2.4.1 接口用例的编写

1. 通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

2. 参数组合：现在有⼀个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有⼀个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

3. 接口安全：

绕过验证：比如说购买了⼀个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？

绕过身份授权：比如说修改商品信息接口，那必须得是卖家才能修改，那我传⼀个普通用户， 能不能修改成功，我传⼀个其他的卖家能不能修改成功

参数是否加密：比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截 到你的请求，就能获取到你的信息了，加密规则是否容易破解。 ◦

密码安全规则：密码的复杂程度校验

4. 异常验证：

所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来， 我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

2.4.2 结合业务逻辑来设计用例

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不⼀样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是⼀样的。

举个例子，拿贴吧来说，贴吧的需求是这样的：

1. 登录失败5次，就需要等待15分钟之后再登录

2. 新注册的用户需要过了实习期才能发帖

3. 删除帖子扣除积分

4. ......

像这样需要把这些测试点列出来，然后再去造数据测试对应的测试点。