接口测试到底测什么
接口测试为什么重要？
我相信你一定听说过这样一句话：“测试要尽早介入，测试进行得越早，软件开发的成本就越低，就越能更好地保证软件质量。”但是如何尽早地进入测试，作为软件测试工程师的你，是不是也没办法说得清楚呢？其实上面那句话中的“测试”，所指的并不是测试工程师这个人，而是指包含了单元测试、接口测试、界面测试等一系列质量保障活动的测试工作。
接口是什么？
接口就是有特定输入和特定输出的一套逻辑处理单元，而它不用知道自身的内部实现逻辑，这也可以叫做接口的黑盒处理逻辑。
而从上面的例子你也可以看到，由于服务对象不同，接口又可以分为两种，一种是系统或服务的内部接口，一种是外部依赖接口。
什么是接口测试？
还是以麦当劳的汉堡为例，接口测试，其实就是要验证制作汉堡的过程是否正确。这里所说的“正确”其实有两方面的意思：一方面，是要验证输入了汉堡的原材料，经过制作汉堡的处理流程，最后交付给你的是一个汉堡；另外一方面，是要验证在输入的汉堡原材料不对或者不全的情况下，经过制作汉堡的处理流程后，不能给你交付一个汉堡。
小结
- 接口测试是通过设计输入和预期输出来完成测试验证的，你之前掌握的测试用例设计方法等测试基本功，在这里还是有用武之地的；
- 接口测试是一个技术知识和业务知识相结合的工作，可以更好地提升你自己的技术实力，让那些说我们是“点工”的人早早闭嘴；
- 接口测试也是功能测试，要说有和界面测试不同的地方，仅仅是和我们交互的，不再是开发工程师设计的界面，而是测试工具或者代码。
在很多人眼里，接口测试是技术，业务测试是业务，但它们其实是不可分割的。所以在这个专栏中，我会通过先介绍方法再引入工具，到最后用代码引入封装框架，一步一步教你完成接口测试。
没有任何文档，怎么才能快速了解接口的信息？
具体的工作模式：
- 借助一些工具的辅助来完成接口分析；
- 通过工具截获一些接口信息；
- 通过分析接口的访问方式、参数等信息整理出一些问题，和研发工程师沟通这些问题，将一些不知道的参数含义、参数取值范围等问题问清楚。
通过这三步的循环，你就可以完成对 SUT 系统接口信息的完善和维护，最终得到一份完整的、接口测试需要的输入—接口文档。
工具辅助
当你第一次拿到一个被测项目，无论它是一个 App 服务还是一个 Web 服务，你都可以通过一些 HTTP 代理完成接口分析，这里我推荐你使用 Fiddler 这款工具。
注意：Fiddler 既支持 Windows 操作系统，也支持 MacOS 操作系统，但是在 MacOs 上的版本并不好用，这是因为 Fiddler 使用了.Net 开发。如果你是一个 MacOS 深度用户，那么我推荐给你两款工具，一款是 Charles，另外一款是 mitmproxy。其中，Charles 是商业软件，mitmproxy 是开源软件，但是 Charles 使用起来更简单，mitmproxy 的使用则稍微复杂一些，你可以依据自己的喜好来选择。
多个接口串行分析
多个接口串行分析在质量保障过程中，测试的主要任务，是保障 SUT 的业务逻辑正确性，而单一接口的测试却很难完成一个业务逻辑，所以，在大部分的测试场景中，我们都需要串行多个接口，才能完成一个完整的业务逻辑。然而，即使我们按照上述三个步骤完成了全部单个接口的分析，也并不能马上开始进行接口测试。这是因为，一个测试的业务逻辑是由多个接口的串行完成的，而多个接口的串行逻辑是由业务逻辑规定的，因此，多个接口之间并不是随意组合的，而是按照业务逻辑、通过数据传递来完成的。这其实就和拼图游戏一样，我们有一堆拼图碎片，很多拼图碎片都可以连接到一起，并不会有明显的不适合，但是，依据拼图的最终图形，这些拼图碎片就是不能放到一起。你要想把拼图完成，就不仅要考虑各个拼图碎片是不是可以链接到一起，还要考虑这些碎片放到一起后是不是对原来图形的正确拼接。那么，你前面整理好的、各个单一接口的信息表，就是拼图游戏里的一个拼图碎片，业务逻辑就是拼图组成的最终图形，而其中的参数，就是拼图碎片的缺口和每一个碎片上的图形。所以，要想使用接口测试完成业务逻辑，你就要制作一个流程中所有接口的接口信息表，同时，还要理清每一个流程的数据流程，数据流程驱动了业务流处理，这样，才能开始业务逻辑的接口测试。
思维方式：用一个案例彻底理解接口测试的关键逻辑
明确被测系统
有了被测系统我们才能开始聊接口测试，但是，目前网络上可以看到的系统例如极客时间的手机应用、百度网站等并不适合做接口测试的讲解，这是因为我们需要知道接口的每一个参数，以及一些接口的处理逻辑。
单接口的测试
单接口的测试单接口测试的重点，其实就是保证该接口的正确性和健壮性，也就是说，你既要保证这个接口可以按照需求，正确处理传入的参数，给出正确的返回；也可以按照需求，正确的拒绝传入非正确的参数，给出正确的拒绝性返回。
业务流程接口测试
业务流程接口测试，主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑，这也是它主要关注的内容。
在接口测试中，我们通过单个接口测试完成了全部异常状态的覆盖；而在业务流程中，我们更需要关心业务流和数据流的关系，并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常，这也是分层测试中为什么在单元测试和界面测试之间要加入一层接口测试的主要原因之一。
你的接口测试也可以和持续集成结合到一起
通过 Postman 这个工具完成从单接口测试用例的设计到业务逻辑接口测试用例的设计，你就已经掌握了接口测试的思维以及具体的实现方法。但是到目前为止，你还处在手动测试的阶段，虽然已经和以前基于界面的业务测经有了很大区别，但是距离自动化的接口测试还有一定的差距。不过你不用担心，因为这个差距仅仅是一个工具的距离。
我相信你一定听说过持续集成，在持续集成中，有一个很重要的环节就是要持续测试，通过持续集成平台调取自动化测试，完成质量保障工作。现在你已经有了 Postman，已经完成了基于 Postman 的接口测试脚本，那么如何将其赋能给持续集成平台呢？
这里我们要借助 Newman 这款工具，它就是 shell 下的 Postman，我们将 Postman 的业务逻辑接口测试脚本导出后，push 到本地的 Git 仓库中，持续集成平台就可以通过 pull 对应的接口测试脚本，然后通过 Newman 执行，这样就可以完成持续集成平台的赋能了。
在这里我只提供给你一个思路，具体的完成方式，你可以通过学习持续集成平台 Jenkins 和 Newman 运行 Postman 脚本完成对应的内容。
总结
走到这一步，你已经掌握了接口测试的思维，在这种思维的指导之下，用什么技术手段或者工具去完成接口测试，也就显得没那么重要了，这也是为什么我并没有将 Postman 这个工具一步一步教你怎么用的原因，因为你既可以选择我推荐给你的 Postman，也可以找到一个你自己喜欢的工具或技术方式完成接口测试。
接口测试的执行方式、设计思维都和业务测试不完全一致，它们既有交集又有差异。交集部分是它们都会涉及到业务逻辑测试，但是接口测试更加关注有数据流驱动的业务流程，而不再着眼于代码异常、代码边界等，这些边界问题在接口测试过程中已经由单接口测试完成了。
接口测试在单接口测试的设计思维上也更加贴近于代码的单元测试，但它还是站在 Client 端的角度来完成测试；而接口测试的业务逻辑测试更加靠近手工业务测试，但却更加聚焦于业务逻辑本身，不再将一些非法业务异常放到该部分进行测试。
参考
https://time.geekbang.org/column/intro/278
