对于测试人员来说，掌握接口测试基本上已经成为一个标配的能力了，但是对于初学者来说，看着网上一大堆高大上的名词解释，总会认为接口测试是一个很高深的东西（包括我刚开始也这么认为），所以今天我就尽量用简单通俗的表达告诉你，接口测试其实很简单！
一、什么是接口？
我扒遍了各种相关名词解释和百科词条，发现关于接口的解释还真是多种多样，这里我只列出一个相对更客观更通用的定义，虽然听起来也很别扭。
接口，泛指实体把自己提供给外界的一种抽象化物（可以为另一实体），用以由内部操作分离出外部沟通方法，使其能被内部修改而不影响外界其他实体与其交互的方式。
通俗点说，能够把某个硬件或软件模块封装起来供外部使用，都可以称之为接口，可以存在于所有的软硬件设备之间。
我们在生活中无时不刻不在使用各种接口，比如我们乘坐电梯里面的按钮就是一个接口，我们开车一个踩油门它也是一个接口，我们计算机操作系统中也有很多接口。
在 IT 行业中，我们通常所说的接口指的都是 API 软件接口，即 Application Programming Interface，应用程序接口，简称 API。本文中后面的部分中提到的接口都是指 API 接口。
对于 API 接口来说，使用者只需要关心输入和输出，不需要了解接口内部的具体实现逻辑。
我们工作中常见的接口可以分为两类：
- 系统内部的接口：
- 同一个系统内部不同模块、不同服务之间的调用
- 如系统内部注册、登录接口的调用，查询订单、JDBC接口调用等。
- 系统外部的接口：
- 不同系统甚至不同公司之间的接口调用
- 如同一公司的系统 A 和 系统 B 之间的调用，第三方登录时调用外部公司的微博登录、微信登录接口等。
二、软件测试模型
我们看一下针对接口的测试位于软件测试模型中的位置。
关于测试模型，最出名的就是测试金字塔模型。
测试金字塔的概念是由敏捷开发大师 Mike Cohn 首先提出的，主要包含以下几点：
- 把软件测试分为 UI 界面测试、接口测试、单元测试三层结构
- 应该进行更多的单元测试，而不仅仅是通过用户界面运行的测试
- 单元测试稳定性更高、更高效
但是在实际工作中，单元测试对技术专业性要求更高，很多情况下都是由开发来实施。虽然单元测试能够尽早的发现问题，减小修复成本，但对测试人员的高要求也意味着更高的人力成本，所以对接口测试层的投入显得更加高效、成本更低。
结合实际现状，对接口测试和 UI 层测试以及单元测试进行了比较，最终认定接口（API）测试可以获得更高的投资回报，所以有了金字塔模型的改进版–橄榄模型（不倒翁模型）：
三、接口测试的意义
1. 更早的发现问题
随着敏捷测试的盛行，我们都知道测试工作要尽早的介入到项目开发周期中，因为越早的发现 bug，修复的成本就越低。
然而功能测试一般都要等到系统提供可测试的 UI 界面后才能进行，单元测试又要求较高的专业性和人力成本，所以选择接口测试来更早的介入测试。
接口测试可以在功能界面未开发出来之前对系统的接口进行测试，从而更早的发现总是并以更低的成本修复问题。
2. 缩短产品周期
接口测试更早的介入，可以更早的发现并解决 bug，从而使得留到后期功能测试阶段的 bug 数量减少，最终缩短整个项目的上线时间，有助于实现敏捷测试。
3. 发现更底层的问题
系统中的有些 bug 如果想通过 UI 层功能测试会比较困难，或者构造测试数据和测试条件非常复杂，而通过接口测试可以更简单、更全面的覆盖到底层的代码逻辑，从而发现一些隐藏 bug。
尤其是一些异常的、极端的情况，可以用接口测试很容易的验证。
四、接口测试策略
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
测试的重点是检查数据的交换、传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
具体来说，就是根据测试文档编写测试用例，执行测试，查看不再的参数请求接口时返回的数据是否符合预期，跟普通的测试没太大区别。
接口测试策略包括接口功能测试、接口性能测试和接口安全测试三方面，具体测试点包含但不局限于如下内容：
最后，关于接口测试工具也有很多，常用的有 postman、soapUI、jmeter 等，具体使用方法都不复杂，后面有时间 再一一详述。
这篇文章测重于对接口理论知识的理解，给出的只是方向性的指导，没有详细的具体实践，所以肯定还有同学不知道该怎么办，不过没关系呀，这都是正常的，关于接口测试的内容非常多，也不是一两篇文章能够全部讲完，最重要的是先知道大概的方向，然后就去大胆实践，在做的过程中成长最快。