开发口中的接口是什么?
我相信绝大多数测试同学听闻“接口”二字都源于开发同学。书本中的标准接口定义叫Interface，在JAVA编程语言中接口是一个抽象类型，是抽象方法的集合，接口通常以interface来声明。一个类通过implements关键字实现接口，从而来重写接口中的抽象方法。
但实际工作中开发同学常常挂在嘴边的接口并不是理论上的接口interface，通常通过以下面两种方式体现：
1.一个http请求
例如：http://host:port/getAllPeople
这个请求就是一个接口，当你发送这个url后，会从服务器端收到请求。服务端的核心代码是，有一个方法来判断url是什么，如果匹配到getAllPeople，则调用相关的方法，例如getAllPeople(){//具体实现代码}
2.不通过http请求，直接调用方法getAllPeople(){//具体实现代码}
而对于我们测试人员最为关注的是第一种方式，即通过http请求调用后端服务代码，因为测试同学代码相对薄弱，直接通过代码调用的方式进行接口测试难度较高，另外好多公司的研发代码是绝对保密的，研发团队以外的人很难获取代码。
为什么近年接口测试的概念这么火爆呢？
传统的开发模式转变，从过去的瀑布到如今的敏捷；
移动互联网的普及，用户页面需求变更频繁，但是服务端接口相对稳定；
微服务的兴起，好多服务根本没有供测试人员的UI可点，我们只能对服务端进行接口测试。
常见的接口类型
HTTP接口；
RPC接口；
Web Service接口；
Dubble接口；
RESTful接口；
其中RESTful接口是基于HTTP接口的，Web Service及Dubble属于RPC接口。目前HTTP接口是最核心也是应用最广泛的接口！
接口测试的核心测试点
校验接口参数是否达到要求（边界、业务规则）
校验接口返回数据的正确性与格式
校验接口覆盖率是否达到要求（一般要求核心接口要达到100%的测试率，非核心接口根据）
性能指标是否满足要求（接口的响应时间、处理能力）
安全指标是否满足要求（一般接口都不会暴露在网上任意被调用，需要做一些限制，比如鉴权或认证。）
接口测试较UI测试的优势
1.接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定
2.测试可以更早的介入（具体的时间点应该是在后台接口开发基本完毕之后，需要模块间进行接口联调的时候）
3.可以发现功能测试覆盖不到的服务端问题
接口测试开展的四个步骤
1.确认接口文档的准确性，这是接口测试通过与否的标准
2.准备接口测试数据
3.构建接口
代码选择java的httpclient jar包或者python的requests模块
工具选择国外的postman、jmeter或国产的Eolinker等
其中比较推荐的Eolinker，是口碑比较好的一个国产接口工具，测试文档和管理功能都很完善，中文界面也可以降低上手难度
使用地址：www.eolinker.com
4.校验接口请求，在成功调用接口后，获取接口的响应数据，根据接口文档来判断接口测试的通过与否
5.
做好接口测试必备的知识点
了解OSI网络模型，TCP/UDP协议，掌握HTTP/HTTPS协议，了解RPC, Web Service及REST，理解Session和Cookie；
掌握常用的接口测试工具Postman,Jmeter,SoupUI等；
掌握基本的抓包工具如Chrome开发者工具,Fiddler，Wireshark等；
掌握一门编程语言Python或Java；
了解Nginx, Apache, Tomcat等服务器中间件；
掌握数据库基本查询命令，及Redis操作，用于检查响应结果；
掌握基本的Linux日志查询和筛选命令。
总结
其实接口测试开展的顺利与否，技术并不占主要因素（核心技术就是我讲的这么多，你会了就可以从事接口测试了）。个人觉得沟通才是接口测试成败的核心，因为接口测试的开展以及接口文档的编写需要开发人员大量的配合，这是极其需要沟通技巧的！(沟通问题不是本文的讨论范围)