1、什么是接口测试

客户端（前端）与服务端（后端）的关系，一般小编会理解为“服务端负责赚钱养家，客户端负责貌美如花”。客户端更注重的是功能呈现及用户体验，怎么将强大的功能精彩的界面呈现给不同的用户，怎么吸引用户使用它，而服务端则是更多的输出所提供功能服务，如功能逻辑，业务逻辑，算法等等,是完美呈现功能的数据提供者。比如你想买件上衣，那么推荐算法给你推荐的就是上衣，而不是裤子。而接口正是服务端提供给客户端这些功强大功能的一个桥梁。

接口测试就是借助工具模拟客户端向服务端发送请求报文，提供不同的输入参数，服务器接收到请求报文后，对相应的报文即不同的输入参数进行处理，然后返回给客户端响应。工具可以模拟客户端同时接收响应，测试就是要检查请求及返回是否符合需求预期。

2、接口分类

接口分为：内部接口和外部接口。内部接口是内部代码交互调用时用到的接口，如白盒测试就是测试的内部接口；外部接口是客户端与服务器交互时用到的接口，如http接口、Web service接口等

3、接口测试都需要测什么

下面是用一张导图总结了一下接口测试主要测试的内容：

 

以上我们可以看出接口测试对服务端的业务功能逻辑能够达到很好的验证，并且接口测试可以不涉及客户端（前端）的交互，不存在兼容问题，只需要根据接口文档发送对应的请求并对请求结果进行校验即可，本文及之后文章也主要跟大家交流的是接口的功能测试及自动化相关内容。

4、接口测试自动化的必要性

1.API编程已经是近年来非常流行的技术

2.可以发现在客户端（前端）发现不了的bug，如服务端对异常情况的校验

3.适用于目前流行的敏捷开发，在产品需求迭代中能够实现快速的自动化接口验证

4.自动化接口测试实现能够对线上环境的接口监控

5.接口变更频率远远低于UI，所以所需的维护成本更低

6.实现接口自动化更容易（无论是使用工具还是自动化框架），且更容易持续集成

5、接口自动化怎么实现

1.借助工具，如现在已经非常成熟的postman、jmeter、RESTClint、SoapUI等

现成的工具易于上手，但是针对不同的业务场景可能存在一定的局限性，可扩展性不够灵活。

2.接口自动化测试框架

需要一定的编码能力，但可结合业务需求自行封装，可扩展性较强，且易于持续集成。
原文链接：https://blog.csdn.net/m0_70618214/article/details/129499141

6、自动化框架知识准备及设计思路

目前小编所涉及业务的接口基本都是基于http协议的，返回的数据类型也大都是json格式，少量是xml格式。

• 知识准备相关：

1.理解http协议

2.理解http请求的整个流程

3.了解常用的认证机制

4.数据库

5.redis

6.基本的代码能力（结合自己情况选择自动化框架的语言）

• 设计思路相关

1.公共api封装

a.接口请求封装

b.公共请求数据或参数分离（请求域名、公共请求参数）

c.不同接口请求参数的获取（可以用xml、json、excel、csv等格式）

d.数据库api的封装（增删改查）

e.redis api的封装（增删改查）

2.每条case验证测试数据的准备

3.验证点（通过断言验证）

对于接口返回的比较有规范的代码：

a.http状态码

b.业务状态码，一般比较规范的代码返回正常逻辑的数据会规定code=0或1（可能key是其他名称，由开发同学自己定义）

c.消息，一般比较规范的代码返回正常逻辑的数据会规定msg=ok或error(可能key是其他名称，由开发同学自己定义)

d.数据(业务逻辑返回客户端或前端需要的数据格式)

 好了，以上内容做到心里有数之后，就可以开开心心的进行自动化框架设计了，测试框架设计及编写测试用例过程中遇到的问题，后续文章会跟大家一一交流。

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取