爆肝整理，接口测试/接口自动化测试总结，你不知道的都在这...

---

前言

1、接口的组成

首先，接口文档应该包含以下内容：
1）接口说明
2）调用url
3）请求方法（get\post）
4）请求参数、参数类型、请求参数说明
5）返回参数说明

由接口文档可知，接口至少应有请求地址、请求方法、请求参数（入参和出参）组成，部分接口有请求头header。

有同学问我header和入参有什么关系？它们不都是发送到服务器的参数吗？

OK，首先，它们确实都是发送到服务器里的参数，但它们是有区别的，header里存放的参数一般存放的是一些校验信息，比如cookie，它是为了校验这个请求是否有权限请求服务器，如果有，它才能请求服务器，

然后把请求地址连同入参一起发送到服务器，然后服务器会根据地址和入参来返回出参。也就是说，服务器是先接受header信息进行判断该请求是否有权限请求，判断有权限后，才会接受请求地址和入参的。

2、接口测试范围

业务功能（包括正常、异常场景是否实现）
业务规则（覆盖度是否全面）
参数验证（边界、业务规则是否达到要求）
异常场景（重复提交、并发提交、事务中断、多机环境、大数据量测试）
性能测试响应时间、吞吐量、并发数、资源要求）
安全测试（权限验证、SQL注入等）

3、接口测试的重点

1）检查接口返回的数据是否与预期结果一致。
2）检查接口的容错性，假如传递数据的类型错误时是否可以处理。
3）接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。

4）接口的性能，http请求接口大多与后端执行的SQL语句性能、算法等比较相关。接口的安全性，外部调用的接口尤为重要。

4、做好接口测试的前提

系统化的接口文档

传统的接口文档，一般采用word或wiki等系统来记录，从单次使用上似乎比较简单，因为大家会更习惯这样的操作，但这种形式存在比较大的问题：

1）接口文档非标准化，无法直接与接口测试工具接口使用。
2）接口维护困难，接口有变化时比较难标识清楚，沟通成本很高。

系统化接口文档，例如rap（淘宝分源的一个系统），具备接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容做二次开发，可以直接导出Soapui等工具使用的格式，直接导入工具中使用，有以下好处：

1）接口测试时不再需要手工输入相关字段，节省时间成本

2）版本化管理，能够清晰的知道哪些接口有变化

标准化的接口规范

接口管理是做好接口测试很重要的前提，如果一个系统有哪些接口都不太清楚，测试就很难覆盖到，接口管理建议采用以下方式：

按接口提供方为单位进行首次划分，按接口使用方进行二次划分，再按业务模块进行细分，分类原则根据内容多少进行优化，不需要固定，如本身接口较少就没有必要分得过细，较多时就需要多划分模块。

如：系统A，提供有 1、2、3、4、5、6、7、8、9 这9个接口，接口分别给B系统、C系统使用，其中1、2为公用接口，3、4、5为B专用，6、7、8、9为C系统专用。

按接口链接URL做为唯一，不同的接口参数做为接口变量，接口有参数变更时在原来接口上进行维护，而不是新增加接口。

为接口增加版本号，方便清楚哪些接口本次有变更，易于维护用例。

5、接口测试怎么测

在进行接口测试前，还需要了解：

1）GET和POST请求

如果是get请求的话，直接在浏览器里输入就行了，只要在浏览器里面直接能请求到的，都是get请求，如果是post的请求的话，就不行了，就得借助工具来发送。

GET请求和POST请求的区别：
GET使用URL或Cookie传参。而POST将数据放在BODY中。
GET的URL会有长度上的限制，则POST的数据则可以非常大。
POST比GET安全，因为数据在地址栏上不可见。
一般get请求用来获取数据，post请求用来发送数据。

其实上面这几点，只有最后一点说的是比较靠谱的，第一点post请求也可以把数据放到url里面，get请求其实也没长度限制，post请求看起来参数是隐式的，稍微安全那么一些些，但是那只是对于小白用户来说的，就算post请求，你通过抓包也是可以抓到参数的。所以上面这些面试的时候你说出来就行了。

http状态码：每发出一个http请求之后，都会有一个响应，http本身会有一个状态码，来标示这个请求是否成功，常见的状态码有以下几种：

1）200 2开头的都表示这个请求发送成功，最常见的就是200，就代表这个请求是ok的，服务器也返回了。

2）300 3开头的代表重定向，最常见的是302，把这个请求重定向到别的地方了。

3）400 400代表客户端发送的请求有语法错误，401代表访问的页面没有授权，403表示没有权限访问这个页面，404代表没有这个页面。

4）500 5开头的代=表服务器有异常，500代表服务器内部异常，504代表服务器端超时，没返回结果

2）接下来再说接口测试怎么测

拿到api接口文档（规范：swagger，showdoc，不规范：word文档，没有：抓包或录制，一般需要抓包或者录制的接口很有可能只测正例），熟练接口业务，接口地址，接口鉴权，接口入参，接口出参，错误码。头痛的面试题：在你们的这个项目（App）你测了哪些接口？

凡是有数据交互的地方就有接口。例如：查询支付宝余额接口。查询芝麻分接口。

编写接口测试计划和方案（接口怎么测）？

通用接口用例设计

通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。

参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

接口安全：
绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？

绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功

参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。

密码安全规则，密码的复杂程度校验
异常验证：所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。
比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。

根据业务逻辑设计

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是一样的。

举个例子，拿bbs来说，bbs的需求是这样的：

登录失败5次，就需要等待15分钟之后再登录
新注册的用户需要过了实习期才能发帖
删除帖子扣除积分
…

像这样的你就要把这些测试点列出来，然后再去造数据测试对应的测试点。

编写接口测试用例。
使用接口测试工具执行接口测试。
输出接口测试报告（HTML格式）

下面是我整理的2024年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

在茫茫人海中，只有不屈不挠的奋斗者才能闯出自己的一片天地，让我们努力拼搏，追逐梦想，创造属于自己的辉煌！

每一次的努力，都是未来成功的种子，让坚持与执着成就你的梦想，勇敢地迈出每一步，终将获得属于自己的辉煌。

每一滴汗水都在为未来的辉煌铺路，坚持不懈的努力终将开启成功之门，让我们怀揣梦想，勇往直前，书写属于自己的传奇。