接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
-----------------百度百科
接口测试，属灰盒测试范畴。可能都知道测试类型分黑盒测试，白盒测试，灰盒测试；黑盒测试又名功能测试，功能测试的范围局限于UI层面，主要测试产品的各个功能是否正常，是否如预期的一样。遗憾，通常与预期的需求相差甚远，催生了一系列的测试岗位诞生。
当然，白盒测试则是基于代码进行测试、对一个函数进行测试，颗粒度与黑盒测试形成一个极端对比。那么，对于系统间的子模块与子模块之间的衔接，逻辑依赖、数据交换，接口之间的交互则是灰盒测试，也是接口测试。
类似的图有很多，本图也是在百度进行搜索到的。
“类似的图”说明的有很多，不论是从测试类型、技术角度以及收益角度都是可以说的通的。那么今天的主角便是接口测试（API）测试，可以抛出问题了。。
秉行5w1H原则：
（why）为什么要做接口测试？
（what）接口测试是测什么？
（where）接口测试应该在什么地方进行？
（when）接口测试应该在什么时间、地点完成？
（who）接口测试应该由谁来执行？
（how）接口测试应该怎样来执行？采取哪些措施？
衍生以下两个问题：
接口测试技术深度如何？
接口测试能达到什么样的效果？
1、（why）为什么要做接口测试？
为了满足分布式、高并发、横向扩展、低耦合度等要求、业务复杂度不断上升。前后端分离的情况下，中间有很多夹层，层与层之间各司其职又相互关联，之间的通讯协议以及报文格式并不完全相同。
从项目的角度来看，绕过前端太过于容易，很多UI层面的case已经不能够达到完全的‘覆盖’要求。那么就必须对UI层面下方的API层进行测试。
2、（what）接口测试是测什么？
接口测试是对系统中的各个子交互点进行测试，其重点便是测试数据之间的交互过程，以及逻辑。其本质还是协议！
3、（where）接口测试应该在什么地方进行？
执行接口测试的方法有太多，当然包括各种各样的工具、框架、平台等。
对一些工具、代码框架做了些许整理。（本人观点、不代表全部、仅供参考）
轻量工具级：Postman/Jmeter/soupUI
该类工具级别具有包含常用协议，类似Postman，乃是Google的产品，开发常用于自行调试接口。简单实用、上手简单。
高级工具级/代码框架：Jmeter/SoupUI/(Python)Request库/TestNG
该类工具级/代码，具备多种协议支持、前置条件、后置条件、外部文件读取、检查点、结果图形化展示等功能。
框架化：TestNG+Maven/Jmeter+Ant+Jenkins/Request+HTMLReport+Jenkins
该级别的集成框架已经是市场比较流行的一些框架，（向下兼容）多种协议支持，前置、后置条件、第三方集成、轻量自动化等功能。
平台化：平台化的接口测试较为复杂，因为已经不仅仅涉及到了接口测试单方面的东西，从执行代理、执行引擎、协议支持、到数据读写、任务分发调度、结果收集、集成CI/CD等等功能，俨然搭建一套这样的平台是一项工作量十分大的工作，而且技术要求较高。
4、（when）接口测试应该在什么时间、地点完成？
论起接口测试的介入时间，当然是越早越好，接口测试本就使整个项目的测试工作进行前移，减轻后期的功能测试成本，而且覆盖率能够大大提升，因此，宜早不宜晚！
5、（who）接口测试应该由谁来执行？
测试人员。
6、（how）接口测试应该怎样来执行？采取哪些措施？
接口测试应该从立项和需求澄清开始跟进、熟悉系统的架构、了解内部、外部接口之间的关联，对接口文档进行分析、从小家到大家，小国到大国，持续推进。从最基础的做起，实现持续集成，接口测试的效果会越来越明显。
7、接口测试技术深度如何？
依项目情况、技术延伸、业务需要而定。从功能到性能、安全，步步加深。
8、接口测试能达到什么样的效果？
从项目工作成本的角度来看，完全可以达到快速冒烟、快速回归的测试目的，后期功能测试的压力会随之降低。覆盖率也相对于UI测试而言，提高了很多。当然，也有部分能够弥补手工无法完成的任务。
从技术角度看，完全是对测试人员在一个新领域的考验。
来源：oschina
链接：https://my.oschina.net/u/4334628/blog/4017978