背景
随着前后端分离项目的发展，越来越多的公司开始使用接口自动化，面试题也开始涵盖了接口自动化的内容。
这就导致了近一年来，无论是微信还是口口，我经常会被测试群友问这样的问题：接口自动化到底要怎么学？
对于这个问题，先问自己几个问题：
- 自己对接口自动化的理解有多少？
- 什么才是接口自动化？
- 接口自动化是点到即止，还是路漫漫其修远兮？（学无止境）
接口类型
首先，我来说说什么是接口。接口，即 api，可以是系统内部接口，也可以是外部系统提供的接口。接口类型根据项目特点而定。
根据调用特性，接口大致可以分为以下几类：
- 基于 http/https 协议接口：
- webservice 接口
- Restful 接口
- RPC 协议接口
- gRPC 协议接口
- ...
其中 http 接口是最常见的，也是大家刚开始接触接口测试就能遇到的类型。http 接口的单接口测试，用什么工具都可以，例如 Postman、Jmeter、Soupui、postwoman、HTTPRequester 等等，甚至 fiddler 都可以。
注意：单接口测试，一般情况下是交给开发去自测的，而不是作为测试人员的要求。
为什么这么说呢？
举个简单的例子：开发自测正常，串业务流程时，字段类型不达标，数据库写入值遗漏的场景是不是经常发生？
（闭眼思考下，以前遇到的甩锅现象的根源是不是可以在这里找到）
因此，如果把接口自动化纳入到测试流程里，就要规范起来，而不是仅仅测试下接口是不是通了。
一般用任意接口工具调通的接口，非 http 接口莫属，那么其他接口如何测试呢？
各种协议接口涉及的技术
要测某种协议的接口，首先了解其涉及的技术，即所谓的知己知彼。
开发不会告诉你怎么测试，因为他懂的是代码，而你可能不懂。
举个例子，RPC 协议的接口测试，首先了解 RPC 是什么，常用的 RPC 框架有哪些，了解底层基本原理后，才能为我们的测试工作开展打好基础。
RPC 是什么
RPC 是协议，俗称远程过程调用，RPC 实现包括：Dubbo、Hetty、Thrift、GRPC 等，其中以阿里的 Dubbo 类型最为常见。那我们来说说 dubbo 相关的技术
Dubbo 相关
学习主流的 RPC 协议，避免不了的就是去测试 Dubbo 接口。首先我们要对 Dubbo 有一定的了解。Dubbo 是一个分布式服务框架，可以实现服务治理，即所谓的 SOA。提到 dubbo 又需要了解 zookeeper 注册中心，dubbo 服务是以什么形式和 zookeeper 进行交互，dubbo 服务与服务之间又是如何实现互相调用的，这些都是我们要去了解的对象，但是又不需要太深，因为测试不需要去写微服务框架。
总结：测试某种协议接口，先了解底层原理及调用关系，才好对症下药，测无遗漏。
接口自动化赋能
讲了这么多，对 http 接口，dubbo 接口，webservice 接口都会测了，那是不是就足够接口自动化了？
我们要接口自动化，目的是实现摆脱页面，实现后端的接口纯自动化。既然是纯后端，那就和后端开发写代码时用到的依赖等技术又息息相关了。
例如：
- 发短信，短信存到 redis
- cookie 存到 MongoDB，3 天有效期
- 新增后密码存到数据库，且做了加密 等等
对于这些典型的案例，我们可以使用复杂问题简单化的思路，把要做的分为以下几步：
- 1. 了解后端开发代码存取及校验逻辑
- 2. 从指定依赖服务（如 redis、mongdb）中提取数据
- 3. 进行调试校验
基本上按照上面的三步走，一个问题的答案也迎刃而解了，那么思路有了，难点也出来了，怎么从 redis 提取数据呢？怎么连接数据库？怎么连接 MongoDB？
这里就是体现技术的时候了，不是三两句能讲清的了。
高级后端自动化
走技术的路，一般都很有趣。像接口自动化越往前走，发现路越深，永远会遇到不重样的问题，每天都有新鲜感 (￣︶￣)
`有疑问咨询 810295842
走着走着，高级后端自动化之 -- 解决方案道路就被你走出来了，从此你不再仅仅是个自动化测试。。。
举例一
疑难杂症：对接第三方项目的接口，对方给不出接口，应当如何处理？
解决方案：所谓时代造就英雄，Mock 应运而生。。。
mock 接口的原理比较简单，模拟第三方接口，和开发联调（测试成了开发的上游），调试通过，对接正式接口进行测试。
难点在于 mock 语法，例如入参和出参有必然联系的，需要实现联动，例如 JavaScript 语法、java 语法你也得懂些。
举例二
疑难杂症：某个项目有几百个接口，需要进行接口冒烟，时间紧任务重，如何在 2 天内完成？
解决方案：用 Jmeter 编写数据驱动框架，轻松实现接口冒烟。
难点在于各个项目特性不同，需要因地制宜修改框架。
举例三
疑难杂症：如何让领导看到我的接口自动化成果？
解决方案：持续集成框架，Jenkins 集成 Jmeter、邮件，实现每日定时发报告（让领导想不知道都难）
举例四
举不动了，回头给你们介绍下数据回写框架吧。。。（实现一个接口数万种场景的接口测试）
根据调用特性，接口大致可以分为以下几类：
http
https
RPC
webservice
Restful api
...
这个分类方法表示不认同。http、https 代表的是传输协议；RPC 代表的是调用方式；web service 代表是个 web 服务（有点废话）；restful api 代表的是接口定义风格
这几个东西不是同一个维度的，不能进行并列分类，比如这句话是没问题的 “某某 RPC 调用方法，背后采用了 http 传输协议和 web service 进行通讯” 。
基础概念非常重要，请说明清楚，不要误导别人。
根据调用特性，接口大致可以分为以下几类：
http
https
RPC
webservice
Restful api
这样的培训教程，不知道会误导多少人
疑难杂症：某个项目有几百个接口，需要进行接口冒烟，时间紧任务重，如何在 2 天内完成？
解决方案：用 Jmeter 编写数据驱动框架，轻松实现接口冒烟。
数据驱动框架不适用这种情况吧？
数据回写 框架，有点小期待
小七的自动化课堂
回复
现在这个还是不大对。。。我说下我的个人理解。
首先，按网络接口角度，网络接口调用的核心目的，主要有 2 个：把约定好格式的信息，发送给指定的目标
传输协议的目的是为了解决发送给指定的目标这个目的的。有多种协议，比如 http、https、tcp 等。tcp 也是常说的长连接，http 是基于 tcp 的但无法支持任意一方随时发起通知，所以对于一些实时通信要求比较强的，会直接基于 tcp 来进行网络连接。tcp 典型的使用场景有微信的消息传输、直播应用的公屏消息等。至于怎么定义指定传输目标？http/https 用的是 url ，tcp 用的是 ip 。
而序列化方式则是为了解决约定好格式的信息这个问题的，常见的有 proto buffer 、json、xml 等。序列化方式保障发送者和接收者用一致的格式解读数据，确保数据传输正确性的同时根据传输场景进行优化（比如一样的信息，用 json 占用的空间比 xml 小，proto buffer 又比 json 小）。当然，除了序列化方式，部分协议也有定义信息格式这类字段，比如 http header 。
然后，在实际编码中，不管什么传输协议、序列化方式，都得自行基于网络库来建一大堆封装方法，接口多了这部分逻辑也有不少的工作量，所以就有了 RPC 调用，把网络库部分自动封装好，开发不用管底层网络库，直接引用 api 包，调用里面提供好的对象和函数即可，大幅度降低开发的调用成本。
而 dubbo、grpc 属于实现了 RPC 理念的具体框架，由于它们封装了底层的传输协议、序列化方式，因此也具备切换多这个协议的能力，比如 dubbo 支持 http、dubbo、thrift 等多种协议。同样由于 RPC 本身就是一种调用方式，本质就是对传输细节的封装，所以一样会有 一个rpc框架封装另一个rpc框架 的情况。比如 dubbo 底层也支持通过 grpc 来进行调用。
至于 RESTful（Representational State Transfer），不属于以上任何一类，它是一种针对 http 协议的接口风格。核心思想是把最常见的数据库的增删改查，和 http 协议的 post、delete、put、get 方法进行一一对应，便于简化服务端逻辑（这种直接增删改查数据的，可以直接基于数据库生成完整的调用逻辑，现在实际也有相关的工具）。当时时代背景是接口协议定义没有任何统一指导思想，大家随心所欲，经常会出现同样是删除资源，每个人创造一种风格的接口路径（有的叫 delete，有的叫 remove 等），复用度也不高，所以产生了这种定义清晰简单，扩展性复用性也强的接口风格，并受到很多开发的欢迎。只是传播过程中很多一知半解的，把它等同于 http 接口了，讲着讲着变了味。
可能有的人会觉得，概念不重要，也确实很多人即使把概念搞混，也不影响工作。但基于这篇文章是想给新人们宣导用的，所以里面的概念还请理清，避免新人们不同地方看到不同的概念，陷入混乱，这就违背了初衷了。
陈恒捷
回复
嗯，管理员的想法我赞同，但是我这篇文章是给被测接口做分类，不是介绍接口的概念来的。
在这期间我也和各大技术总监、开发经理（包括阿里等大厂的）聊过，中国文字博大精深，其实分类也有千千万万种，每个人看的角度不一样是不
小七的自动化课堂
回复
每个人角度不一样这个没问题，只是你这个分类，特别是 RPC 和 gRPC 并列，这个分类方法会让新手很迷惑这两个 rpc 有啥差异，实在有点说不过去。
既然要给新同学布道入门接口自动化，内容里给读者一个经得起推敲的指引，这个是基本要求吧。如果有些不确定的，建议特别说明 “个人观点，不一定正确，欢迎探讨”。
这么热闹的吗
陈恒捷
回复
管理员好，首先，真的很感谢管理员对我的文章的关注，欢迎批评指正。
其次，关于接口分类的细节，并不是本篇文章的重点，反而被 “误导新人” 这个帽子放大了，这个我并不接受。我相信 testerhome 是个开放的平台，大家有底线的畅所欲言也算是言论自由的。
再者，关于接口的分类，写文章之前，以及与您互评期间，我求证过各个阶层的无论是来自于阿里/华为/中信等大厂的 CTO 到技术经理，文章中的分类不是空穴来风，也不仅仅是我个人观点。
我不是很喜欢百度去粘贴概念，那不是我的风格。（百度很多文章都是作者个人观点）
接口的分类是否符合您的看法，我相信这也不是我关注的重点，我也无意去误导新人。
感谢关注！
小七的自动化课堂
回复
行，讨论到此结束吧，我们继续保持双方的观点就好。也希望后续的文章，这些概念性的内容，请做好审核，最好是加上参考资料或者出处，经得起大家的推敲。
关于言论自由这个，也特别说明下，社区一直保持言论自由，这个帖子一直没有被屏蔽就是一个证明。但也请注意，社区的初衷是为了帮助新人成长，提高测试地位，推进质量发展，因此会保持对内容进行审核。遇到内容不大正确，经不起推敲的，会有人站出来指出；太不靠谱的，我们也会直接屏蔽。
其中实现一个接口数万种场景的接口测试有误导嫌疑：
1、一个接口数万种场景，那么这个接口设计是否有问题？
设计有问题，让开发改方案~
2、如果接口设计没有问题，数万种场景是否存在大量重复的场景？
场景有重复，那就需要按照等价类的思想去掉重复的场景。
小七的自动化课堂
回复
没有带任何情绪，只是客观评价。
一个接口包括数万种场景，如果是真实的，极可能违反系统设计原则了；如果没有违反，接口参数虽然可以组合，但是是可以通过等价类去重的。
打起来骂起来杀起来