1.7 接口测试
以麦当劳为小明制作汉堡为例，接口测试其实就是验证制作汉堡的过程是否正确。这里所说的“正确”有两方面的含义。
验证输入的汉堡原材料在经过汉堡的制作流程后，交付给小明的是汉堡。
验证在输入的汉堡原材料不对或不全的情况下，在经过汉堡的制作流程后，无法向小明交付汉堡。
注意，上述两方面验证都要进行。对于测试工程师来说，这两种流程都是正向流程。读者只有具备了这种思维，才能让自己走出客户思维，形成测试工程师思维。测试工程师在工作中能够接触到各式各样的接口，比如HTTP的接口、RESTful格式的接口、Web服务的接口、RPC协议的接口等。其实，无论是哪一种形式的接口，它们都通过某种传输协议来实现客户端和服务器端之间的数据传递。
假设正在测试的是Web端的极客时间，那么客户端就是浏览器，服务器端则是Web服务，浏览器和Web服务之间是通过HTTP传输数据的。
假设正在测试的是移动端的极客时间，那么客户端就是测试设备上安装的极客时间应用，服务器端则是RESTful格式的接口服务，极客时间应用和RESTful格式的接口服务之间是通过JSON格式来传递数据的。
我们由此可以看出接口测试的本质：接口测试其实就是模拟调用方（如客户端），通过接口通信来检测被测接口的正确性和容错性。但是，这里所说的模拟调用方并不是让测试工程师开发浏览器或极客时间应用，而是让测试工程师模拟这些客户端的前端逻辑并调用服务器端提供的接口，这项工作完全可以通过借助一些工具或代码来完成。后面我们在完成一些工作或任务的过程中，会对这些工具进行详细的讲解，并重点从应用的角度讲解哪些工具能够解决哪些问题，以及用什么样的代码可以解决什么样的问题等。工具和代码并不是互斥的，而是相互依存、不可分割的关系。其实，接口测试和业务测试工程师熟悉的业务测试一样，关注的都是输入和预期是否一致，尤其是当输入数据中含有一些非法输入时，接口的处理和逻辑控制是否合理，这些都可以通过接口的返回值来判定。此外，一些小概率逻辑的处理也是测试工程师设计输入的关注重点，比如代码中的一些异常情况，同样要想办法通过输入参数来触发这种逻辑分支，并通过返回值来判定对应接口内部实现的处理逻辑是否合理和健壮。这样看来，接口测试对于任何测试工程师来说都并非全新的工作内容，但话虽如此，接口测试仍有自身的特别之处。
在测试手段上，接口测试是技术驱动和业务驱动双管齐下的工作（界面测试是以业务驱动为主的工作），因此需要借助一定的工具来完成。用到的既有可能是成熟的工具，也有可能是测试工程师编写的代码。因此，测试技术在接口测试阶段会变得和业务知识一样重要。
在工作范围上，接口测试影响的范围要更广一些。接口测试不仅会覆盖一部分单元测试的内容，而且会覆盖一部分业务测试的内容。但是，无论哪些测试内容被接口测试覆盖，对应部分的工作投入其实都减少了。
1.8 小结
本章结合小明去麦当劳点餐的例子，讲述了接口为什么重要、接口是什么以及接口测试都测试些什么。此外，本章还分析了接口测试和业务测试的区别与联系——“相互依存，不可分割”。本章要点如下。
接口测试是通过设计输入和预期输出来完成测试验证的，业务测试工程师之前掌握的测试用例设计方法等测试基本功，在这里仍有用武之地。
接口测试是需要将技术知识和业务知识相结合的一项工作，接口测试可以更好地提升测试工程师的技术实力。
接口测试是功能测试，接口测试和界面测试的不同之处仅仅在于和测试工程师交互的不再是研发工程师设计的界面，而是测试工具或代码。
