本文将讲述接口测试及常用接口测试工具,接口测试工具可以通过前置sql来实现。

首先，什么是接口呢？

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

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

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

一、常见接口：

1、webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；

2、http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

二、前端和后端：

 在说接口测试之前，我们先来搞清楚这两个概念，前端和后端。

      前端是什么呢，对于web端来说，咱们使用的网页，打开的网站，这都是前端，这些都是html、css写的；对于app端来说呢，它就是咱们用的app，android或者object-C（开发ios上的app）开发的，它的作用就是显示页面，让我们看到漂亮的页面，以及做一些简单的校验，比如说非空校验，咱们在页面上操作的时候，这些业务逻辑、功能，比如说你购物，发微博这些功能是由后端来实现的，后端去控制你购物的时候扣你的余额，发微博发到哪个账号下面，那前端和后端是怎么交互的呢，就是通过接口。

      前面说的你可能不好理解，你只需记住：前端负责貌美如花，后端负责挣钱养家。

三、什么是接口测试：

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

OK，上面是百度百科上说的，下面才是我说的

其实我觉得接口测试很简单，比一般的功能测试还简单（这话我先这样说，以后可能会删O(∩_∩)O哈！），现在找工作好多公司都要求有接口测试经验，也有好多人问我（也就两三个人）什么是接口测试，本着不懂也要装懂的态度，我会说：所谓接口测试就是通过测试不同情况下的入参与之相应的出参信息来判断接口是否符合或满足相应的功能性、安全性要求。

我为啥说接口测试比功能测试简单呢，因为功能测试是从页面输入值，然后通过点击按钮或链接等传值给后端，而且功能测试还要测UI、前端交互等功能，但接口测试没有页面，它是通过接口规范文档上的调用地址、请求参数，拼接报文，然后发送请求，检查返回结果，所以它只需测入参和出参就行了，相对来说简单了不少。

四、接口组成

接口都有那些部分组成呢？

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

1、接口说明

2、调用url

3、请求方法（get\post）

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

5、返回参数说明

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

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

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

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

五、为什么要做接口测试：

大家都知道，接口其实就是前端页面或APP等调用与后端做交互用的，所以好多人都会问，我功能测试都测好了，为什么还要测接口呢？OK，在回答这个问题之前，先举个栗子：

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

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

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

②、检查系统的异常处理能力

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

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

六、接口测试怎么测：

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

1）、GET和POST请求：

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

GET请求和POST请求的区别：

    1、GET使用URL或Cookie传参。而POST将数据放在BODY中。

    2、GET的URL会有长度上的限制，则POST的数据则可以非常大。

    3、POST比GET安全，因为数据在地址栏上不可见。

    4、一般get请求用来获取数据，post请求用来发送数据。

其实上面这几点，只有最后一点说的是比较靠谱的，第一点post请求也可以把数据放到url里面，get请求其实也没长度限制，post请求看起来参数是隐式的，稍微安全那么一些些，但是那只是对于小白用户来说的，就算post请求，你通过抓包也是可以抓到参数的。所以上面这些面试的时候你说出来就行了。

2）、http状态码

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

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

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

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

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

接下来再说接口测试怎么测：

1）、通用接口用例设计

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

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

③、接口安全：

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

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

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

     4、密码安全规则，密码的复杂程度校验

④、异常验证：

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

2）、根据业务逻辑来设计用例

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

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

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

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

   　　 3、删除帖子扣除积分

   　　 4、......

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

 七、用什么工具测

　　接口测试的工具很多，比如 postman、RESTClient、jmeter、loadrunner、SoapUI等，本人首推的测试工具是postman和jmeter，接下来就简单介绍下如何使用这两款工具进行接口测试，其他工具本次暂不介绍。

1）、Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。

jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。

注：以下用例中所用地址皆为本人在本地所搭的环境，外网无法访问，见谅。

①、获取用户信息：该接口用于通过userid获取用户信息

　　请求地址：http://192.168.1.102:8081/getuser

　　请求方式：POST/GET

       入参：

 出参：

  postman中请求如下

 jmeter中请求如下：

  ②、获取用户信息：需要添加header，Content-Type application/json

1.1    请求地址

http://192.168.1.102:8081/getuser2

1.2    请求方式

get/post

1.3     入参

参数

数据类型(长度)

是否必传

备注

userid

String

Y

用户id

 1.4     出参

参数

数据类型(长度)

备注

code

int

状态码200为成功，500为异常

userid

int

用户id

name

string

用户名称

age

int

用户年龄

 postman测试如下，本次入参为json类型，当然文档中没说非要用json，用其他方式也是可以的

 jmeter测试如下

 ③、修改用户余额2

1.1     功能描述

功能描述：需要添加cookie，token token是写死的token12345

1.2    请求地址

http://192.168.1.102:8081/setmoney2

1.3    请求方式

Post

1.4    入参

参数

数据类型(长度)

是否必传

备注

userid

String

Y

用户id

money

String

Y

修改的余额数值

接口测试工具

zip

0星

超过10%的资源

2KB

下载

 1.5     出参

参数

数据类型(长度)

备注

code

int

状态码200为成功，500为异常

success

String

状态

  postman测试如下：

 jmeter测试如下：

 ④文件上传

postman：

jmeter:

 ⑤、请求webService接口

请求webService接口需要用到的工具是SoapUI，如下图

在jmeter里请求如下： 

一、前置用例及前置执行SQL

1.1 用于解决为用例的执行创建数据场景；

1.2 前置用例功能是通过执行已设定的用例，创建后续用例的数据场景。通常可用于：验证登录成功场景时，先通过设置前置用例为注册成功用例，以确保执行登录时该帐号是已注册的；

1.3 前置执行SQL，当前设计仅限测试环境可用，生产库不适宜直接进行db的update、delete、insert into操作。

二、断言设置

2.1 验证方式

通过以下三种方式获取用例执行实际结果，与用例设置的期望值作对比。

JsonPath：Fastjson的JSONPath进行json数据提取；

示例：

{ "data": [{ "calorieStandardRate": 36, "happenDate": 20181217, "motionTimeStandardRate": 9 }, { "calorieStandardRate": 100, "happenDate": 20181219, "motionTimeStandardRate": 34 }, { "calorieStandardRate": 100, "happenDate": 20181220, "motionTimeStandardRate": 44 }, { "calorieStandardRate": 90, "happenDate": 20181221, "motionTimeStandardRate": 3 }], "message": "OK", "result": "0000"}

$.data[-1].calorieStandardRate：代表取data数组中最后一个的 calorieStandardRate 值；

$.data[0].calorieStandardRate：代表取data数组中第一个的 calorieStandardRate 值； 

$.data.length()：代表取data数组的长度，可进一步代表返回了几条数据；

Response：表示接口返回的response字符串；

Value(SQL)：表示执行sql查询后的结果；

2.2 预期值

期望结果和实际结果均支持字符串、sql脚本、Jsonpath动态取值，避免写“死”测试数据，造成在后期的用例失败，提高用例的可持续性。

2.3 对比方式

值相等、值不相等、值包含、值不包含

2.4 在线调试

可在线对用例进行调试校验。完整的记载着用例的输入、参数替换、输出、断言对比结果。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。