11.1 接口
11.1.1 接口概述
定义：接口就是API（Application Programming Interface，应用程序接口），是一个软件或服务对外提供的接口，别人只要调用这接口，而内部如何实现，不需要关心。你只要按照要求进行接口调用即可。
外部系统与系统之间以及内部各子系统之间的交互点。包括外部接口、内部接口。
举例：
假设物流中“货物”是数据，存放货物的“总仓库”是数据库，“店铺”是我们的网站、App。页面上显示的内容、数字，以及用户的操作请求和结果都是需要不停搬运的“货物”——数据，则负责调配分配打包的中转站就是API，快递小哥直接从中转站取货就好。
作用：对于软件提供商来说，留出API，让别的应用程序来调用，软件才能发挥最大的价值，才能更有生命力。（同时别人也看不见代码，不伤害商业机密。）
对于应用开发者来说，有了开放的API，就可以直接调用多家公司做好的功能来做自己的应用，不需要所有的事情都自己操刀，节省精力。
11.1.2 接口的表现形式
客户端要先操作服务端资源，首先要找到服务端提供的接口，然后才能向服务端发送资源请求，那么何为服务端接口呢？其实就是一个地址（URL），比如：
http://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1
采用的协议(http:)：一般来讲网址中第一个“:”前面的就是该网址所采用的协议。这里的HTTP就是个协议 。HTTPS是HTTP的安全版本，HTTPS在HTTP的基础对传输的数据进行了加密和签名，以保证数据传输的安全性。我们平常打开两页的时候会看到网址前面都有一个HTTP或HTTPS，这就是告诉你，你在向服务器发送此请求的过程中要遵循的协议是HTTP或HTTPS (也就是规则)。
服务器地址(//www.qubaobei.com)：以双斜杠“//”开头，后面跟的就是这个服务器的地址，专业术语叫域名。
请求资源路径(/ios/cf/dish_list.php) ：表示你要请求的资源在该服务器下/ios/cf/dish_list.php的路径下。
参数（?stage_id=1&limit=20&page=1）：参数可以找到具体内容，和路径之间使用“?”隔开，参数之间使用“&”隔开。参数是以键值对的形式表现出来的。
把此URLhttp://www.qubaobei.com/ios/cf/dish_list.php?stage_id=1&limit=20&page=1称为食品模块个接口， 也称为接口地址。
11.2 接口文档
接口文档展示
11.2.1 封皮
封面最好是本公司规定的封面，有logo，内容标题，版本号，公司名称，文档产生
日期。（错误地方在于，文档的标题要和页眉中的标题一致）
11.2.2 修订历史
表格形式较好些。包括：
版本，修订说明，修订日期，修订人，审核时间，审核人。
11.2.3 接口信息
接口调用方式，是post方式还是get方式，接口地址，别人需要线上的哪个地址就写哪个。（自己提前测试好线上的这个接口，是否有其他问题，千万别犯低级的错误，尤其是某个字母写错）
11.2.4 功能描述
一定要清晰的描述接口功能。（不要遗漏一些细节，比如接口获取的信息不包括哪些，哪些要写明白）
11.2.5 接口参数说明
每个参数都要和实际中调用的一样，包括大小写；参数的含义言简意赅的说明；格式是string 还是int 还是long等格式（例如参数为@RequestParam("appKey") StringappKey, @RequestParam("randomId") Integer randomId）；说明部分，说明参数值是需要哪个公司提供，并详细说明参数怎么生成的，例如时间戳，是哪个时间段的；参数是否必填，一些参数是必须要有的，有些是可选参数，一定要注意写清晰。
11.2.6 返回值说明
1、有一个模板返回值，并说明每个返回参数的意义。
2、提供一个真实的调用接口，真实的返回值。
注：现实工作中，对接口有疑问要及时跟同事交流。
11.3 接口测试的概念
11.3.1 概念
测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
11.3.2 接口测试本质
实质就是数据的传输和接受，传输的是接口地址中的参数，接受的是文本字符串，然后对比文本字符串是否正确。
11.4 接口测试的目的和原理
11.4.1 目的
测试接口的正确性和稳定性。
11.4.2 原理
接口测试的原理是通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。
11.5 常用接口测试工具
11.5.1 典型商业工具：
LoadRunner（LR）：一款商业性能测试工具，用来做接口测试，很好很强大 ，但是配置比较麻烦。
SoapUI：开源测试工具，通过soap/http来检查、调用、实现Web Service的功能/负载/符合性测试；该工具既可作为一个单独的接口测试工具使用，也可利用插件集成到Eclipse，maven2.X，Netbeans 和intellij中使用。 了解就可以了，基本已经不用了。
11.5.2 典型开源工具
Jmeter ：一款开源的接口测试工具，操作简单，方便，既有jdbc request操作数据库数据，也有http request和soap request应对测试
13.5.3 扩展插件
postman：谷歌浏览器的扩展工具，主要用来做接口测试，谷歌商店中选中安装，界面同poster差别不大，界面简洁。
13.6 接口测试应该测什么
13.6.1 单一接口
单一接口功能的测试主要测试返回的数据结构是否和接口文档给出的一致，接口的正常功能是否完成，接口的参数检查测试，接口的异常测试。
13.6.2 组合接口
定义：组合接口测试主要是通过组合多个单一接口，来测试一个业务场景
案例：测试购物网站的一个下单的功能，那么因为在下单之前还有一些流程，所以要测试一个场景。
测试：搜索商品 --> 选中商品 --> 添加进购物车 --> 提交订单 -->支付
（提交订单时还涉及到地址的选取等）
注：涉及到如果使用从cookie或者session在本例中的区别：如果使用cookie加入购物车，那么换一台电脑购物车里的商品就不存在了，但如果使用的是session，购物车里面的东西就一直存在，即：cookie是本机作用的，session不止于本机作用。
13.6.3 结构检查
（1）检查返回值的结构是否正确，如是json类型还是xml类型的数据
（2）字段名称是否正确等
XML和JSON都使用结构化方法来标记数据
13.7 接口测试内容
13.7.1 功能逻辑
通过查数据库或缓存等验证数据是否处理正确。
通过其他辅助途径进行验证
13.7.2 异常测试
接口测试中主要测试接口正常逻辑，但仅逻辑测试不能保证数据的安全及程序接口在异常情况下的逻辑处理的正确性。
13.7.3 路径测试
当被测接口的实现方法中，判断逻辑复杂分支多，且判断中又调用了其他的接口，此时必须要进行路径覆盖测试。
13.7.4 其他异常场景
研发的项目，有些项目是底层使用的系统，根据项目特点，可能会存在特殊的异常场景。
例如： 支付的异步操作，支付消息重试等
11.8 测试案例
11.8.1 get请求
11.8.2 post请求
13.9 接口测试用例模板