2.6.2 接口自动化测试的价值
单接口测试不断地扩大检测范围，既保证了单个接口功能的正确性，也覆盖了单接口的可靠性，从而不断提升接口测试的测试深度和测试广度，向下则逐渐覆盖一些公共接口的单元测试内容。
业务场景测试通过多接口串联及上下文参数处理完成业务逻辑的模拟，往上则逐渐覆盖应该由UI层保障的业务逻辑测试。
这种变化是工程实践选择的结果，它主要的优越性如下。
接口自动化测试更容易与其他自动化系统相结合。
相对于UI测试，接口自动化测试可以更早开始，也可以测试一些UI测试无法测试的内容，因此它使“测试更早地投入”这句话变成现实。
接口自动化测试还可以保障系统的鲁棒性，使得被测系统更健壮。
2.6.3 与接口自动化测试相关的实现技术
接口自动化测试主要包含模拟协议客户端、接口逻辑模拟、数据驱动、自动化执行、断言操作、关键字驱动、测试替身等。除这些必要内容以外，测试缺陷自动提交、误报缺陷自动过滤也是必须关注的技术方向。本节将介绍这些技术。
模拟协议客户端指模拟协议客户端行为的测试技术，这既可以是测试脚本也可以是测试平台，它主要提供一种模拟与被测服务交互的技术手段，提供与被测系统发生交互的基础，从而方便接口测试的实现。例如，HTTP常用代码调用对应协议访问客户端类，如Java的HttpClient、Python的requests等，或者利用常规工具Postman（Postman的使用方法参加附录F）等。
接口逻辑模拟指通过录制修改或者脚本开发，在模拟协议客户端技术的基础之上实现与被测服务的交互。该交互主要实现了被测接口的访问与参数传递，以及返回值的获取，如HTTP接口通过写代码完成访问URI、参数、访问方法等的设置，发起访问并获取返回值，或者通过Postman中新建的请求完成对应的设置。与HTTP相关的知识参见附录C。
数据驱动指为接口自动化测试的接口逻辑模拟部分提供被测接口参数的入参，该入参可以按照某种形式存储在外部文件或者外部服务中，通过自有的参数策略进行选取，从而实现一个接口逻辑模拟方式的多次入参访问，以大幅度提高接口模拟逻辑的复用率，以及接口自动化测试的开发效率。例如，在编写脚本时，常会将参数放入.CSV、JSON、数据库等文件或者服务中。
断言操作指提供针对接口自动化测试返回值的部分或者全部的一些预期的自动比对，其中支持一些布尔运算，如等于、包含、不包含等。
自动化执行指接口自动化测试能够支持按需或者定时调用部分或者全部接口自动化测试脚本完成测试。这里的按需指按照固定需要，这既可能是迭代的需要也可能是质量保障环节的需要。同时，要提供定时执行能力，这既可以由自动化接口测试框架或者平台自己提供，也可以借助持续集成平台完成。
关键字驱动指提供关键字封装功能，能够通过关键字将一些接口封装成某一流程的关键字，而通过该关键字就可以完成对应业务流的测试、调用等。这样我们就可以把一些接口自动化测试隐藏到业务识别关键字中，提高编码的可读性和复用性。
测试替身指为了达到测试目的并且减少对被测对象的依赖，在依赖接口编程的程序中使用测试替身代替一个真实的依赖对象，从而保证测试的速度和稳定性。在国内它常和Mock概念等同。
测试缺陷自动提交指接口自动化测试在执行过程中失败，并发现被测系统缺陷时，可以自动上报现象、脚本及实际返回值，完成新缺陷的提交。
误报缺陷自动过滤指接口自动化测试在执行中出现失败后，判断对应失败并非被测系统的缺陷导致的，而是环境问题、数据问题、依赖问题而导致的，这些并不是缺陷，可以自动将其反馈给测试工程师而并不上报新缺陷。
接口的逻辑模拟生成指通过某些接口输入内容自动完成接口的逻辑模拟形式的生成，通常自动生成测试代码。
测试报告指对测试结果以统一的方式展示，能够提供表格、统计图等格式的总体分析，甚至可以将缺陷报告、误报缺陷自动过滤模块的内容同时输出到报告中。
整体来说，一个接口自动化测试至少要包含模拟协议客户端、接口逻辑模拟、数据驱动、断言操作、关键字驱动、测试报告。对于微服务化的系统，测试替身是必不可少的内容。而测试缺陷自动提交、误报缺陷自动过滤、测试脚本生成则是随着测试技术的发展而新出现的技术，但是这些技术发展迅速，有可能成为接口自动化测试技术未来发展的方向。
2.6.4 如何开始接口测试
开始接口测试并不需要具备非常高端的知识体系，而需要一些行动，在行动过后具体是选择工具平台还是学习脚本开发由实践驱动。同时，技术、技术栈还要根据团队代码基础、项目迭代周期及团队技术水平综合选择。
下面就以目前测试工作中常见的HTTP接口为例，讲解如何开始接口测试（也可以通过一些代理工具查看协议交互的内容，HTTP代理工具参见附录B）。
在开始接口测试时，不要贸然使用你已经掌握的接口测试工具或者接口测试代码访问被测接口，要先理解接口的实现。这是因为只有理解了接口的实现才能设计出完善的测试用例，保障被测接口的质量。
对于接口的实现，主要收集以下内容。
实现者的契约：说明为什么要实现这个接口，即该接口要完成的实际逻辑。这里说的并非代码逻辑，而是要弄清楚是为了满足什么需求而创建的接口，接口要完成什么逻辑处理过程，这个逻辑处理过程满足了什么业务实现。然后，我们即可在业务逻辑的基础之上设计测试数据。
交互的接口信息：建立在接口实现的业务逻辑基础之上，要掌握该接口的访问URL、HTTP 方法、header的内容要求、Cookie的内容要求、body的内容要求等，这样我们就可以通过接口测试工具模拟接口的调用方，再与测试数据相结合，完成接口测试的关键信息的整理。
在搭建测试框架时，不要纠结于技术选型，更不要以研发工程师的技术栈作为标准，而应根据团队的技术实力与技术功底来做选择，这是因为研发工程师和测试工程师关注的角度及交付目标是不同的。
对于任何研发工程师来说，主要工作就是通过写代码满足产品需求或实现原型设计。研发工程师关心高并发、低消耗、分布式、多冗余，相对来说更关注代码的性能和可靠性。
测试工程师无论使用接口自动化测试，还是使用基于界面的手动测试，首要目标都是保障交付项目的质量，业务侧的表现在大多数情况下不是测试工程师关注的重点。
因此，在技术栈的使用频度和使用广度上，研发工程师都远超测试工程师，除非团队本来就有相应的知识储备。为了提高工作效率，使用团队熟悉的技术栈完成接口自动化测试即可。这里强调一下，无论采用何种技术栈写代码，它们都只是帮助团队实现接口测试的手段，而不是为了测试团队交付的结果。
