随着前后端分离项目的发展，越来越多的公司开始使用接口自动化，面试题也开始涵盖了接口自动化的内容。
这就导致了近一年来，无论是微信还是口口，我经常会被测试群友问这样的问题：接口自动化到底要怎么学？
对于这个问题，先问自己几个问题：
首先，我来说说什么是接口。接口，即 api，可以是系统内部接口，也可以是外部系统提供的接口。接口类型根据项目特点而定。
根据调用特性，接口大致可以分为以下几类：
其中 http 接口是最常见的，也是大家刚开始接触接口测试就能遇到的类型。http 接口的单接口测试，用什么工具都可以，例如 Postman、Jmeter、Soupui、postwoman、HTTPRequester 等等，甚至 fiddler 都可以。
注意：单接口测试，一般情况下是交给开发去自测的，而不是作为测试人员的要求。
为什么这么说呢？
举个简单的例子：开发自测正常，串业务流程时，字段类型不达标，数据库写入值遗漏的场景是不是经常发生？
（闭眼思考下，以前遇到的甩锅现象的根源是不是可以在这里找到）
因此，如果把接口自动化纳入到测试流程里，就要规范起来，而不是仅仅测试下接口是不是通了。
一般用任意接口工具调通的接口，非 http 接口莫属，那么其他接口如何测试呢？
要测某种协议的接口，首先了解其涉及的技术，即所谓的知己知彼。
开发不会告诉你怎么测试，因为他懂的是代码，而你可能不懂。
举个例子，RPC 协议的接口测试，首先了解 RPC 是什么，常用的 RPC 框架有哪些，了解底层基本原理后，才能为我们的测试工作开展打好基础。
RPC 是协议，俗称远程过程调用，RPC 实现包括：Dubbo、Hetty、Thrift、GRPC 等，其中以阿里的 Dubbo 类型最为常见。那我们来说说 dubbo 相关的技术
学习主流的 RPC 协议，避免不了的就是去测试 Dubbo 接口。首先我们要对 Dubbo 有一定的了解。Dubbo 是一个分布式服务框架，可以实现服务治理，即所谓的 SOA。提到 dubbo 又需要了解 zookeeper 注册中心，dubbo 服务是以什么形式和 zookeeper 进行交互，dubbo 服务与服务之间又是如何实现互相调用的，这些都是我们要去了解的对象，但是又不需要太深，因为测试不需要去写微服务框架。
总结：测试某种协议接口，先了解底层原理及调用关系，才好对症下药，测无遗漏。
讲了这么多，对 http 接口，dubbo 接口，webservice 接口都会测了，那是不是就足够接口自动化了？
我们要接口自动化，目的是实现摆脱页面，实现后端的接口纯自动化。既然是纯后端，那就和后端开发写代码时用到的依赖等技术又息息相关了。
例如：
对于这些典型的案例，我们可以使用复杂问题简单化的思路，把要做的分为以下几步：
基本上按照上面的三步走，一个问题的答案也迎刃而解了，那么思路有了，难点也出来了，怎么从 redis 提取数据呢？怎么连接数据库？怎么连接 MongoDB？
这里就是体现技术的时候了，不是三两句能讲清的了。
走技术的路，一般都很有趣。像接口自动化越往前走，发现路越深，永远会遇到不重样的问题，每天都有新鲜感 (￣︶￣)
`有疑问咨询 810295842
走着走着，高级后端自动化之 -- 解决方案道路就被你走出来了，从此你不再仅仅是个自动化测试。。。
疑难杂症：对接第三方项目的接口，对方给不出接口，应当如何处理？
解决方案：所谓时代造就英雄，Mock 应运而生。。。
mock 接口的原理比较简单，模拟第三方接口，和开发联调（测试成了开发的上游），调试通过，对接正式接口进行测试。
难点在于 mock 语法，例如入参和出参有必然联系的，需要实现联动，例如 JavaScript 语法、java 语法你也得懂些。
疑难杂症：某个项目有几百个接口，需要进行接口冒烟，时间紧任务重，如何在 2 天内完成？
解决方案：用 Jmeter 编写数据驱动框架，轻松实现接口冒烟。
难点在于各个项目特性不同，需要因地制宜修改框架。
疑难杂症：如何让领导看到我的接口自动化成果？
解决方案：持续集成框架，Jenkins 集成 Jmeter、邮件，实现每日定时发报告（让领导想不知道都难）
举不动了，回头给你们介绍下数据回写框架吧。。。（实现一个接口数万种场景的接口测试）