一、什么是接口？
API（Application Programming Interface）即应用程序接口，可以是一个软件组件或一个Web服务与外界进行交互的接口，在这里接口可以和API划等号。
官方解释：接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等
接下来从三个层面来理解（逐层解析）：
1、接口可以理解为一个黑盒子，一边输入参数，一边输出参数
（属于直观理解，表面层）
接口的基本元素：地址、输入参数、输出参数，从这层面来看，只关心输入和输出，和平时所说的黑盒测试很像。
作为黑盒测试，基本的测试思路是通过输入和输出判断被测系统或者对象的逻辑
2、接口可以理解为连接前端（Web、APP页面） 和 Database 等底层的纽带，用于在二者之间传递数据，处理数据
（从接口用途角度理解）
底层一般都是使用数据库来插入数据，前端是不可能直接操作数据库（读写数据），为了完成数据交互，需要中间纽带（接口）
当下大部分互联网产品都是基于前后端分离的方式
前端指Web/APP页面主要是负责展示数据和样式，后端（接口层次）主要是负责处理数据，就是纯粹计算，而前后端传递信息就是通过接口，所以说接口稳定性、健壮性、抗压性，直接决定了互联网的成败
前端通过调用接口传递一个约定的参数，接口收到请求后，按照对应的业务逻辑去处理完成，将结果和需要的数据返回给前端，前端会解析这些数据，并展示在页面上，这样就完成了一次广义上的前后端交互。
3、接口可以理解为业务逻辑处理方法的外在表现形式，可以是一个类下面的方法，也可以是一个函数，即函数或方法的代码测试
（白盒测试角度）
二、HTTP协议接口
1、HTTP请求由3部分组成，分别是：请求地址、消息报头、请求正文
2、HTTP响应也是由3个部分组成，分别是：状态码、消息报头、响应正文
三、HTTP协议请求方法
1、GET 方法：URL + header
如：http://www.jianshu.com/p/48b728981aa4;
2、POST 方法：URL + header + body
将请求参数直接作为数据进行传输，数据包的形式用{}表示，json格式（键值对）
如：http://192.168.1.171/api/user_sign/{”time“:"14562987","sign":"sdfgdf354dfg"};
GET和POST方法的区别
1、GET请求的数据会附在URL之后，是不传递参数的请求，或通过Cookie传参；
POST则是把提交的数据则放置在http包的body中 ，是需要传递参数的请求，url地址会在地址栏不会显示出参数
（两者发请求的方式不一样）
2、GET方式提交的数据有长度限制（最大长度是 2048 个字符），
POST方法没有大小限制（参数可以很大）
案例：一个页面的文本框最多支持2W个字符，后端提供给前端的接口类型是GET，结果数据导出时报错了，最终还是改回POST类型
3、POST的安全性要比GET的安全性高
GET把接口和参数捆绑在一起，通过页面鼠标移上去看到链接基本就知道要发什么请求数据了（所发送的数据是 URL 的一部分）
POST方法是看不到的，最多看到一个链接地址，不知道发了什么参数（参数不会被保存在浏览器历史记录或 web 服务器日志中），但可以通过抓包获取参数
实际中接口对安全性能比较高，用MD5加密的方式，把参数加密后再传递过去，即使抓到了参数也不知道本质是什么
4、一般GET请求用来获取数据，POST请求用来发送数据
POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。
POST方法克服了GET方法的一些缺点，通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。
四、为什么要做接口测试？
既然是接口获取和操作资源的方式，而大部分系统和产品中，资源一般都是产品的核心，比如微信核心资源就是通讯录关系链和聊天记录等，因此资源是必测的。
另外接口中大部分的内容是数据，通过数据的对比我们能推测到系统和产品的逻辑，测接口就是测逻辑。
最后接口中的返回相对单纯，不像web页面，html代码中有太多UI的东西，UI最不稳定，变化太快，接口相对稳定一点点，但是里面的干扰信息更少，断言相对容易很多。
1、可以发现很多在页面上操作发现不了的BUG
例如：页面有一个输入框（必填项），这时候不输入内容点搜索是不会发送请求的，页面会提示输入内容 或 任何反应都没有，不会去调用接口，反正只要程序不报错不崩溃就行了，因此从页面上操作限制较多
如果直接调用搜索接口，会直接跳过这个页面的限制，在接口传递参数时，设计一条传递空字符串的 case，再去检查服务返回内容是什么，是服务返回400报错还是返回200正常，而正常的返回的内容又是什么（可以发现一些接口本身的问题）
假如百度搜索框，页面上做了必填项的限制，不填的话“百度一下”按钮就点不了，也就没法去调用百度的搜索接口，那么这个时候就测不了如下场景：数据内容为空，后台接口会返回什么结果或者页面会得到一个什么情况
如果抛开页面直接调用接口，当它为空时，底层逻辑没有做很好的处理，没有做空的判断，那就可能会抛出一些异常信息，说明接口的健壮性并不好
接口没做处理，那么单纯通过页面操作可能是发现不了的，接口传空值有可能返回所有数据，这样的场景就能发现接口有问题
2、检查系统的异常处理能力
如：搜索窗口（搜用户是否存在），输入很长的值，搜的时候发现被截断了，我们看到的数据也都是正常的
但是抛开页面，直接调用接口，传很长的参数值，就能发现接口层面的异常。如果前端接口传一个很长的值到后台，后台用select语句去查询，有可能会抛出SQL日志，如长度不能超过什么字段的最大长度限制，这已经变相的抛出了数据库的哪些表、哪些字段，而这些信息是不希望让用户看到的
3、检查系统的安全性，稳定性
如：搜索窗口（搜用户是否存在），底层就会调用搜索的接口，我们在页面尝试使用 SQL注入 的方式去搜索用户，输入1=1，尽量去模拟后台有问题，如果前端做了处理，过滤了 SQL 中关键性的东西（点号、星号、单引号），这时SQL注入的语句就会被前端拦截掉，不会进入到后端。这时从前端页面看是没有任何问题的（直接过滤）。
如果接口这层没有做类似的处理，前后端没协调好（前端做了后端没做），一旦被别人捕获到接口的地址，并实施SQL注入，将会带来非常严重的后果，会抛出数据库中指定表里的数据，甚至能得到所有表名，对系统的危害性非常大
不管用户名和密码输入的内容是否正确，都能绕过服务器的验证顺利登录成功，因为‘1’=‘1’这个条件一定为真
sql = "select * from user where username='admin' or '1=1 ' and password='admin' or '1=1 '"
4、接口逻辑测试后，前端测试重点便可更多关注易用性、兼容性等
只要前后端严格按照接口协议，一般情况下后端接口在测试完成后就能保证业务逻辑的正确性，剩下来的问题便是前端如何将数据展示出来
五、如何开展接口测试
1、获取待测试接口相关数据
2、对接口逻辑充分理解，必要时可以查看接口代码
3、设计接口测试用例
4、使用工具（编写脚本）模拟发送接口请求，检查返回包数据
5、按照预期结果与实际结果的对比，来判断接口测试用例的通过性
前后端如何调用接口
前后端凭着一纸协议：接口协议文档（规范性的文档）
接口文档有规范的格式和内容要求，后端按照接口协议接收前端传递的合法数据和返回符合的规范的数据，前端按照接口协议传递符合规范的数据和对后端返回的数据依据展示的需要做处理
拿到文档后：
1）前端就可以知道哪个接口能获得什么样的数据，就可以根据设计图后去渲染页面
2）后端就知道前端需要哪些参数，以及什么情况下该给哪些参数，以及给参数的方式
文档包含以下内容：
1、接口说明（）
2、调用URL（接口地址）
3、请求方式
4、请求参数，包含参数类型及其限制条件
5、返回参数说明（返回包结构体）
如上图所示，如果接口返回0001，前端就知道肯定有一个参数为空，于是可以很友好的把信息展示在页面上，可以告知用户“XXX输入内容不能为空，为必填项“类似的文字
接口文档的重要性
1、接口文档就是纽带
2、接口文档是对业务逻辑的传承
3、接口文档是测试接口的重要依据
六、接口实例演示
请思考：在内容中输入后点搜索，怎么得到的数据，前后端是怎么交互的呢？
用图解答上述问题（接口在前后端之间的数据流程过程图）
比如百度搜索python，页面一直转圈（前端等待接口返回数据），可能有以下原因：
1）接口本来就慢，数据量很大
2）网络传输慢
