接口测试

关于接口的概念，这里就不在引用一些资料中的定义了。我根据自己的理解和认识把接口大致分为两类：程序接口和协议接口。

程序接口，也可以看做是程序块接口，具体到程序中一般就是提供了输入输出的类、方法和函数。对于程序接口的测试，一般需要使用与开发程序接口相同的编程语言，通过对类、方法和函数的调用，验证其返回结果是否正确来进行测试。这一类测试工作，即可以由开发人员自己完成，也可以由有良好编程能力的测试人员来做。

协议接口，一般是指系统通过不同的协议提供的接口，例如使用 HTTP/SOAP 协议等。这种类型的接口对底层代码做了封装，通过协议的方式对外提供调用。因为不涉及底层程序，所以一般不受编程语言的限制。我们可以通过接口测试工具或者其他编程语言进行测试。这一类测试工作多数情况下由测试人员完成。

接口的分类

从系统的调用方式不同，又可以将接口大致分为以下三种。

1.系统与系统之间的接口

系统与系统之间的接口，既可以是公司内部不同系统之间调用的接口，也可以是不同公司不同系统之间调用的接口。对于前者，我所测试 MAC 系统就是一个对公司内部提供服务的接口平台。提供用户抽奖、活动报名、活动投票等接口服务。对于后者，如微信、微博所提供的第三方登录接口，如果你开发的系统不想自建用户体系，那么完全可以调用这些接口来实现用户的登录。

2.下层服务对上层服务的接口

应用层，可以认为是系统所提供的 UI 层功能。对于 Web 系统来说，就是浏览器页面上所提供的功能，如登录、注册、查询、删除等。

Service 层，可以理解为服务器所提供数据的处理。

DB 层（Data Base）数据库主要用来存放数据，例如用户的个人信息、商品的信息等。

下面举例来说明各层之间的调用过程。首先应用层实现了一个用户查询的功能，需要用户输入查询的关键字，并显示查询结果，当用户使用查询功能时，首先底层调用 Service 层所提供的查询接口，查询接口得到应用层调用的查询数据；然后再通过 DAO 访问数据库，根据用户输入的查询数据，查询数据库中的数据；最后，将查询到的数据库返回给应用层，用户在应用层看到查询结果。

在这个过程中，各层之间的交互就是通过接口，应用层与 Service 主要通过 HTTP 接口。Service 层与 DB 层主要通过 DAO（Data Access Object）数据库访问接口。对于 Python 与 MySQL 数据库之间的调用，

3.系统内部，服务与服务之间的调用，大多数情况下是指程序之间的调用。

继续举例，假设系统开发一个用户查询接口，输入用户名，返回用户信息（性别、年龄、手机号、邮箱地址等），如果用户不存在则返回 null。现在需要新开发一个用户抽奖的接口，该接口需要用户名和抽奖活动 id，抽奖接口得到用户名后可以调用用户查询接口，如果用户查询接口返回 null，那么抽奖接口就可以直接返回用户不存在了。在这个例子中，用户抽奖接口调用的就是用户查询接口。

这里的用户查询接口和抽奖接口本质上就是程序开发的函数或方法，提供入参与返回值。

接口测试的意义

根据分层自动化测试中的定义，最底层由开发人员编写的单元测试保证代码的质量，最上层由功能人员手工+UI 自动化测试保证功能的可用。那么接口测试的意义是什么呢？

1.更早的发现问题

测试工作应该更早地介入到项目开发中，因为越早发现 bug,修复的成本越低。然而功能测试必须要等到系统提供可测试的界面后才能进来。单元测试和接口测试是更早介入测试的两个方面。接口测试可以在功能界面未开发出来之前对系统的接口进行测试，从而可以更早地发现问题并以更低的成本修复问题。

在一些实际项目开发过程中，开发人员并没有充足的时间去编写单元测试，并且他们往往对自己编写的代码有足够的信息，不愿意将时间“浪费”在单元测试的编写上。这个时候接口测试就会变得更加重要。

2.缩短产品研发周期

更早介入测试带来的另一个好处是可以缩短产品周期。接口测试的介入可以更早地发现并解决 bug，使得留到功能测试阶段被修复的 bug 减少，从而缩短整个项目的上线时间。

3.发现更底层的问题

系统中的有些 bug 如果想通过 UI 层功能测试会比较困难，或者构造测试条件非常复杂。通过接口测试可以更简单更全面地覆盖到底层的代码逻辑，从而可以发现一些隐藏的 bug。

除此之外，我们通常把 UI 层的验证称为弱验证，这是因为它很容易被绕过。如果只针对 UI 层的功能进行测试，就很难发现后端系统对一些异常情况的处理能力，而接口测试可以很容易地验证这些异常情况。

搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核