比起点点点的功能测试，“接口测试”显得专业又高大上，也因此让有些初级测试人员“望而生畏”。别担心，其实接口测试也是功能测试的一种，它是针对接口进行的功能测试。
写在前面：本文参考了茹炳晟老师的《测试工程师 全栈技术进阶与实践》，并结合自己的理解进行了删减和补充。
一. 什么是接口测试？
软件接口，是指软件不同模块之间交互的接口，我们通常所说的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中交叉覆盖（正交实验法）
五. 常见面试题
项目中使用的是什么协议的接口？
提示：一般有HTTP、HTTPS、RPC等。然后会结合回答继续问~
HTTP接口有哪些请求方法？
提示：常用的GET、POST、PUT、DELETE等
HTTP接口的返回码
提示：2xx、3xx、4xx、5xx
接口测试有哪些好处？
接口测试是如何做的？
提示：从流程和设计上回到
有哪些常用请求头，请求头是做什么的？
cookie和session的区别，UA等
如何区分前后端bug？
六. 思考和总结
接口测试在测试工程师的工作中比重越来越大，因此也是专业TE的必备技能。
本文简单介绍了接口测试的背景以及优点，对于设计和组织部分也是简略一提，更是没有设计工具、框架的使用。其实这部分如果要详细说，每个工具，每个框架都是个很大的话题。本文只是提供一个简单的思路，还需要每个测试人多思考多总结。
如果有机会，我会慢慢总结并分享~Fighting! 与各位共勉！
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
