接口测试--转自测试百晓生微信公众号

区分概念

测试：我想了解下接口，你能给我讲讲这个系统中的几个重要接口吗？

JAVA开发：这里面有几百个接口，都很重要的，你想看哪一个？

测试工程师：~这~~~

 

很明显，这两个初级工程师对接口的理解，显然出现了偏差，JAVA工程师理解的接口是指JAVA中的interface,而测试工程师所理解的接口，是指多系统间进行数据交互、通信的接口。为了让大家不出现理解偏差，我们今天来统一口径，了解一下什么是测试行业通用的接口测试。

 

我眼中的接口测试

某百科：

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

 

通俗的讲，接口是指系统模块与模块或系统与系统间进行交互。如下图所示：

 

 

再举个实际的栗子：

 

 

有一个新闻客户端：

在手机上打开新闻客户端按住屏幕往下拉时，页面会刷新，会有新的新闻展示出来，这就是一个请求获取数据的接口。服务端返回：

 

 

客户端根据返回值，进行渲染，然后展示给用户。

所以对于新手而言，接口测试就是要做到如下两个基本点：

1、保证服务端有响应，有返回值

2、保证返回值的正确性，如果newsId与title匹配不上，则表示接口返回错误

 

 

接口的类型

 

由于通信协议太多，以后我们把最常用http协议的接口作为主要例子。

 

目前我们所说的接口中，用的最多的是RPC，webservice，restful的接口。但现在流行的是基于HTTP协议的rest风格的接口，为什么只强调rest风格的接口呢？在这里介绍一下rest 接口，rest接口在使用过程中不受调用客户端语言的限制，在网络传输过程中不需要传递强类型的对象，仅仅通过网络传递字符串，也就是说rest是一组约束条件和原则，大家都遵守这些条件与原则，于是乎，交互的数据就具有通用可解析的特点了。更通俗点说，rest风格的接口就是指返回值是json串的接口。现在restful风格类型的接口已经越来越成为互联网行业通用的接口表现形式。

 

到底什么是接口测试

 

通过上面的概念的理解，我们大致可以知道了，接口测试一般就是指基于HTTP协议的返回值是JSON串的测试(也有可能是一个字符串\XML)，那其本质就是客户端发送一个request给服务端，服务端响应后返回一个response，然后我们分析response是不是符合预期，这即是接口测试。大家先这么理解吧。

 

接口测试的前景

 

 

由于接口传输的主要是数据，数据的准确性、安全性应该是被首先保障的。所以，一般的接口测试比UI功能测试 优先级要高一些。

 

由于接口只是单纯的数据交互，无界面，与传统的UI测试相比，更接近底层一些，更容易发现底层的问题，且难度相对UI测试要低很多，所以接口测试号称测试界的“短平快”，更加符合现在敏捷开发，快速迭代的开发模式。

 

同时在自动化方面接口自动化测试也是最容易看到成效的，更容易获得你老大的支持哟。

 

 

 

接口的生命周期

 

 

 

其中测试人员一直贯穿到整个生命周期，具体是这样的：

 

 

 

测试人员都是全能的，职责几乎贯穿了整个接口生命周期。那到底从哪里开始测试呢？可能100个人有100个自己的理解。

 

自然是越早开始越好，现在测试人员的价值早不是以前找多少个BUG。在“专注、极致、口碑、快”的今天，能帮开发越快迭代的测试才越值钱。

 

 

该怎么办呢？

 

 

当接口定义完以后，就进入了开发设计阶段，这时候，后台接口开发人员需要设计数据库表等方面的工作，提供出这个接口最快得两三天左右，但终端可能立刻就需要这个接口的数据从而进行下面的功能的开发，前端开发人员不可能等着。OK，机会来了，测试人员就可以介入了，说的没错，就是测试人员提供mock，使接口能够正确的返回，从而使前端开发能够接着往下进行。

 

测试界的军规，缺陷发现越晚，代价就越高。

 

 

就让咱们开始吧

 

我们先分析一下接口请求的过程：

 

 

 

接口开发语言很多，比如php/python/java，甭管 PHP是不是世界上最好的语言，它们的接口请求的过程都是如上图所示，所以，既然我们要mock，只能是在”执行方法/函数并将数据返回终端”这一环节来操作了，我们可以提供一个方法，将终端所需要的数据写死在方法体中，并返回给终端，这样，终端就能够拿到的数据并进行下面的开发。

 

比如这样一个接口定义：

 

路径：/api/v1/getUserInfo

请求方式：GET

请求参数：userid=1

返回正确值：

{    "redCode": 200,

    "redMsg": "success",

    "data": {

        "id": 1,

        "name": "zhangsan",

        "age": 18}}

返回异常值：

{

    "redCode": 201,

    "redMsg": "data null",

    "data": {}

}

 

 

可以设计两组请求参数userid=1和userid=2提供给终端，在mock的方法体中这样写：

 

 

当接口开发完毕后，撤下我们的MOCK类，依据MOCK类，完善自动化测试脚本，并对已开发完的接口进行自动化测试。

 

 

优点

承上启下，承接终端，启发服务端，使之平滑过渡。

 

 测试数据已体现在MOCK类中

 

 最重要的一点：更接近底层，利于我们更好的去了解接口

 

缺点

需要编码能力教强

从流程上大家还不是足够的熟悉系统容易漏测

 

接口到底在测什么

 

在写接口测试脚本时，对于接口返回值的断言，有的同学偏向于连接数据库，取值并将数据进行加工后与接口返回值进行比较，以达到运态期望值的目的，个人认为这是一种不正确的方式，理由如下：

 

1

 数据加工的过程，就是接口业务逻辑实现的过程，就算测试通过了，你也无法保证你的代码没有BUG。如果提前写好期望，可以最大限度的避免这个问题。

 

2

一个稳定的接口，其输入与输出都是稳定的，根本不需要所谓的动态期望值，我们只需要给出参数，将返回值我们事先设定好的写死的数据进行断言即可。

 

3

 如果你真想把控开发业务逻辑的过程，到不如去做白盒测试与单元测试，这样的收益更大。

 

 

接口测试在每个人眼中的不同

百晓生的接口测试系列也到了尾声了，陆续收到一些反馈，大家都认为接口测试是一种相对比较简单且回报率要相对高些的一种测试手段，特别是在互联网+的浪潮之下。大家蜂拥而至后，发现接口测试其实并不简单，也会有心力憔悴的感觉，似乎又回到了UI自动化的怪圈。针对这种情况，百晓生也是急大家之所急，跟很多测试界大牛交流了这些问题，经过整理，希望能对大家有些帮助。

 

A君：

 

Q：你所理解的接口测试？

A：接口测试本身不难，难的是监控。

 

Q：监控是指监控哪方面？

A：主要2个方面，性能和功能。性能主要是看接口的响应时间，指定告警阀值，告警策略。例如，10分钟内，平均响应时间超过某个值。这里的性能是劈开并发。功能主要看接口在灌入正确参数，异常参数的一些返回值，也就是业务逻辑的检查。

 

Q：那这个监控是指接口测试脚本的执行了？

A：是的，接口测试脚本调试完成后，就可以丢到执行中心去执行了，也就是监控。

 

Q：验证是如何做的？也就是期望值是如何产生的？

A：你测试一个接口，连期望值都不知道，怎么测？所以，期望值你是知道的。

 

Q：期望值，有的人是从数据库取值，然后与返回值进行比对，有的是直接写死，然后与返回值比对，你们采用的是哪种方式？

A：我们不是写死的，测试接口的数据大多数是动态生成，也就是说通过调用其他接口来准备你待测接口的数据， 在接口自动化的过程中，不操作数据库。

 

Q：通过调用其他接口来准备你待测接口的数据，举个例子说明一下？

A：有些场景，譬如接口B依赖接口A的返回，你在测试接口B的时候，就应该先调用接口A，拿到返回作为接口B的测试输入， 而不是直接从数据库拿一个A数据，或者写死一个数据。

 

Q：如果这个接口不依赖任何，其期望值是不是写死就好一些？

A：有些返回里面永恒不变的，写死没问题，有些东西要变的，写死就不行了，变的情况一般使用通配来检查。也就是说，返回值里，可能分两部分：变化的，与不变的。那我们也可以分两部分来检查，变化的，通配检查，不变的，可以写死的进行检查。

 

Q：执行中心统一定时多长时间运行一次？

A：这个看你的用例规模，执行引擎的数量，如果你的资源不够，非要1分钟执行一次，那肯定跪。

 

Q：接口平台会起到什么作用？

A：平台只是提供一些用例编写，维护的便利，执行策略等常规配置，至于没有平台，你照样可以完成这些事情。

 

 

B君：

 

Q：你们如何做的接口测试？

A：很简单，用EXCEL来维护用例与数据，写个执行引挚就可以了。

 

Q：验证时，有去查数据库吗？

A：分情况而言，一般不去验证数据库。

 

Q：脚本写完后，如何实施？比如是丢在线上进行不间断的跑？

A：构建的时候触发，构建完成->触发任务->通过。每天也会有BVT测试。

。。。。。。

 

 

 

交流至此，不知道对大家有没有启发，也希望大家从迷惑中走出来，真正让自动化给我们带来生产上的效益，而不是成为我们去面试 谈薪水时的噱头而已。