什么是接口测试，如何做接口测试？

比起点点点的功能测试，“接口测试”显得专业又高大上，也因此让有些初级测试人员“望而生畏”。别担心，其实接口测试也是功能测试的一种，它是针对接口进行的功能测试。

写在前面：本文参考了茹炳晟老师的《测试工程师全栈技术进阶与实践》，并结合自己的理解进行了删减和补充。

一. 什么是接口测试？

软件接口，是指软件不同模块之间交互的接口，我们通常所说的API（Application Programming Interface 应用程序接口），即是软件系统不同模块之间衔接的约定。

接口测试即是对软件各个模块的接口进行的测试。

二. 为什么要重视接口测试？

近年来软件的规模日益庞大，软件系统越来越复杂，仅仅从用户界面的测试无法保证系统的健壮性和容错性，且越早发现问题修复的成本越低。下图是迈克 · 科恩（Mike Cohn）提出的传统了软件测试的金字塔模型：

金字塔模型告诉我们：

测试层级越低，问题定位越容易；

测试层级越高，维护成本越高；

测试层级越高，修复成本越高。

但由于互联网产品追求的是快速实现功能并上线，基本不会给开发或测试人员有多余的时间去做足够的单元测试；及时预留了单元测试的时间，频繁的迭代也会让单元测试处于不断写的状态。因此，互联网产品的单元测试也有一定的针对策略，一般是对核心模块相对稳定的业务和服务覆盖单元测试。在此情况下，API测试变得尤为重要。主要原因如下：

API测试用例的开发、调试和执行效率比较高
API相对稳定
API测试用例的执行的稳定性远远高于GUI测试
现在很多互联网产品都采用了微服务架构，在此架构下，如果做好了每个服务的API测试，整体产品的质量就有了保障。

因此，互联网产品一般采用的都是菱形的测试策略：

三. 接口测试有哪些好处？

上一小节介绍了为什么要重视接口测试，那做接口测试有哪些好处呢？

实现测试左移
用户界面的GUI测试是模拟真实用户使用软件的行为，它位于测试的最顶层，发现问题后，定位和修复的代价都比较大。API测试可以实现测试的左移，即前后端分离的项目，当后端开发完毕，即可进行接口测试，而无需等待前端。可以保证尽早发现问题，降低问题修复成本。
降低维护成本
相比较用户界面，接口比较稳定，维护成本低
提高测试效率
一方面，由于接口在执行中不依赖于任何界面上的操作，其执行稳定性远远过于GUI，因此可以实现自动化，提高测试效率；
另一方面，可以将一些常用的接口用例做成小工具（或直接执行脚本），测试过程中的一些数据准备及构造的场景，就可以直接拿来用了；
还有，需要反复执行的回归场景，可以直接执行用例。
有利于bug定位
很明显，通过接口发现的问题，就是后端问题，可以直接找负责接口的开发人员；如果仅仅是用户界面发现的问题，可以直接找前端开发。这种测试策略可以明确bug的范围，降低bug定位成本
保证系统的安全性、健壮性和容错性

一些通过UI无法进行的输入，可以通过接口轻易地实现。例如在什么是测试思维 – 测试工程师的核心技能举例的微信余额支付从场景：

单单从用户界面上操作，这里的负数、非全数字，都是无法输入的；但是从接口的角度看，这些值都可以作为输入参数。

四. 如何设计和组织接口测试用例？

首先明确一下接口测试的范围。第二节已经说了，由于互联网的“快”，API测试变得尤为重要。但是不是所有的API都要测试呢？——不是。正如单元测试一样，API测试也要考虑性价比，因此一般我们选择核心的业务模块做API测试。由于不同业务的核心模块不同，这里不作讨论。

刚刚介绍了，接口测试是针对接口进行的功能测试。因此，接口测试和功能测试的用例设计原则是一样的：场景分析都要灵活运用测试思维（什么是测试思维 – 测试工程师的核心技能），常用的用例设计方法都是等价类划分、边界值等（软件测试入门必学--如何设计测试用例）。那二者有哪些不同呢？

1）测试对象不同

功能测试：主要测试应用程序的具体功能

接口测试：主要测试应用程序中各个模块间的接口的输入、输出等是否符合预期

2）测试目的不同

功能测试：确保应用程序的具体功能和需求文档一致

接口测试：测试应用程序中各个模块间的接口的输入、输出等是否符合预期，和其他模块的交互是否OK

3）测试重点不同

功能测试：重点在用户界面及功能

接口测试：重点在业务逻辑

4）测试工具不同

功能测试：主要是人工直接操作用户界面

接口测试：需要使用接口测试工具，例如postman，jmeter等，更多是实现基于代码的测试套件

5）测试扩展不同

功能测试：用户界面变化比较频繁，可做充分的探索性测试

接口测试：接口相对稳定，有利于实现自动化，来保证业务逻辑。例如用户界面的重构，如果接口不变，则用户界面可以随意更改，同时用实现的接口自动化来保证业务逻辑。但“自动化”本身不会扩展，其无法替代手工测试的探索性测试。

4.1 单个接口的测试

通过上面几小节内容，我们已经了解到，接口是软件系统不同模块之间衔接的约定。因此接口测试是比较规范的，通常就是三个标准的步骤：

准备测试数据
发起请求
验证响应结果

接口测试时需要关注的点有：

URL地址：具体的接口url
请求方法：GET、POST、PUT、DELETE等
请求头域（Header）：发送申请时携带的头部信息。通常一些鉴权的信息：authentication/cookie、响应的数据格式：content-type等等的设置。当然响应的数据也会返回一些头部信息。
请求参数（Parameter）：GET是以键值对的形式，POST的参数在body体里
响应内容（Response）：接口的返回码及返回内容，即输出。通常要对这部分进行验证。

4.2 多个接口的测试

实际业务场景中，通常一个单一的前端操作可能会触发后端一系列的API调用，因此API测试用例一般都不是单个的API调用，而是一系列，并且经常在后一个API调用中需要使用前一个API调用返回的结果，同时需要根据前一个API调用的返回结果决定在后面应该调用哪个API. 因此这两个问题的解决直接影响到多个接口测试用例的实现。

如何高效地获取单个前端操作所触发的API调用序列？

询问开发人员
这是最直接的方法。但经常询问一则会对开发人员造成打扰，二则显得咱也不够专业。
阅读开发代码
需要有一定的编程基础

3. 参阅开发人员的详细设计文档
一般比较规范的详细设计文档或接口文档都会有业务逻辑图，注明各个接口间的调用顺序。

4. 抓包
可以通过Fiddler等抓包工具，在不依赖开发人员的情况下自己获取。

5. 查看日志

通过基于用户行为的日志，可以获取API调用序列。

如何在后一个API调用中使用前一个API调用返回的结果？

手动检查
自然是可以的，只是效率比较低。
自动化实现
接口的规范性，使得将结果的验证和引用实现自动化，不但可以验证业务流程，还能提高验证的效率。

如果使用postman，可以自动生成验证代码。但当需要频繁执行大量的测试用例时，Postman等基于界面的API测试就无法满足需要了。于是出现了基于代码的API测试框架。比较典型的是基于Java的OkHttp和Unirest、基于python的http.client和Requests、基于Node.js的Native和Request等。一些大型的企业还会结合自身的业务开发自己的API测试框架。各个框架各有优劣，思想都是相通的。大致的思路如下：

提炼出业务主流程，每个主流程对应一个测试套件，即test suite
对于一些异常场景，可以在主流程的test suite中添加，它不会影响最终的结果；也可以单独建立test suite以减少对主业务流程的干扰；
支持多个取值的参数，可以在不同的test suite中交叉覆盖（正交实验法）