史上最细，接口测试+接口自动化总结，一篇策底打通...

---

前言

1、接口测试需要验证数据库么？

有的接口会返回很多数据，有的接口可能就返回一个状态码及success之类的消息，这些需要验证数据库么？

现在在写一个测试框架，配置接口参数和预期返回值，生成xml文件管理用例，用一个比较方法对预期和返回作比较，不需要根据每个接口写脚本，现在的疑惑只是比较返回值，并不清楚接口是否真的成功了，比如删除之类的接口，返回说成功了，但数据是否真的删除了？如果要验证数据库，感觉得为每个用例写脚本去验证了，这就和初衷不符（只写个比较函数，比较返回的所有值，不需要为每个接口单独验证）。

不少同学在做自动化是都会问要不要验证数据库？我的答案是不要！

根据分层自动化测试的概念。

UI层自动化模拟的是用户操作，假设我是一个普通的用户，在你家的系统上购买了一件商品，我怎么知道有没有购买成功？难道要去查你家系统的“已购买表”？没权限，就算有权限我也不会！那我怎么验证？很简单啊！系统不是有“已购买” 商品列表嘛！点开“已购买”菜单看就可以了！（如果没有这功能，那说明你的系统设计有问题。用户体验不好，差评！！）

接口自动化模拟的是开发的代码操作，A开发写的接口给B开发去调用，A系统的接口给B系统去调用，假设我是一个开发，我调用了微信的接口去做获取用户头像，有个用户获取不到，来！微信团队，你让我查查你们的数据库呗！微信肯定不答应。（数据库不是你想查，想查就给你查！）

那接口返回了“success”，但没有把数据添加/删除成功怎么办？从我两年接口自动化的经验来说，这中情况基本非常少见，因为开发在写代码的时候，返回“success”的前提条件肯定是基于操作成功的。（开发写代码的时候肯定会自已运行一下啊！怎么会运行都不运行，哪儿来的自信！）

你们的开发就是粗心怎么办？我是这么做的，开发提交了新的接口，我会边读接口代码边设计接口用例（如果接口逻辑看不懂接口数据可能就构造不出来，接口用例自然也不会写。）代码有问题就直接告诉开发改了，在这个过程中，我是会查数据库的。一旦接口用例写好之后，后面再回归去跑的时候就不管了，当然，每条接口用例里面肯定不会加查询数据库的动作。

在特殊情况下，我调用了一个删除数据的接口，有没有真的删除一条数据，我可以调用查询数据的接口啊！查不出来刚才删除的数据，不就证明刚才的删除接口操作是ok的了。

2、接口测试是什么？

常见接口类型：

1）webService接口：是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。可以使用的工具有SoapUI、jmeter、loadrunner等；

2）http api接口：是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。可以使用的工具有postman、RESTClient、jmeter、loadrunner等；

3、为什么要做接口测试

1）互联网的快速发展，公司内部系统或与外部系统的关联越来越多，一个业务流程关联多个后端系统，它们的关联都是基于接口来实现，接口测试可以将复杂的系统关联进行简化，只要做好每个接口的测试就能够较好的保证系统质量。

2）单个系统的变更，是否会影响到关联业务系统，比较难用常规的测试方面来覆盖相关的应用系统（例如使用此接口的外部 系统有N个，不可能每个做功能兼容性测试），但可以通过对接口功能的覆盖来验证是否影响它人对接口的调用。

3）接口功能比较单一，能够比较好的进行测试覆盖，也相对容易实现自动化持续集成，可以减少人工回归成本与时间，缩短测试周期。

4）接口相对于界面功能，会更底层一些，测试覆盖会更容易（如业务在调用接口时做了判断，当不满足条件时链接就不显示，此时从界面无法测试相关功能是否做好判断，通过接口就比较容易）

5）大家都知道，接口其实就是前端页面或APP等调用与后端做交互用的，所以好多人都会问，我功能测试都测好了，为什么还要测接口呢？

OK，在回答这个问题之前，先举个栗子：

比如测试用户注册功能，规定用户名为6~18个字符，包含字母（区分大小写）、数字、下划线。首先功能测试时肯定会对用户名规则进行测试时，比如输入20个字符、输入特殊字符等，但这些可能只是在前端做了校验，

后端可能没做校验，如果有人通过抓包绕过前端校验直接发送到后端怎么办呢？试想一下，如果用户名和密码未在后端做校验，而有人又绕过前端校验的话，那用户名和密码不就可以随便输了吗？如果是登录可能会通过SQL注入等手段来随意登录，甚至可以获取管理员权限，那这样不是很恐怖？

所以，接口测试的必要性就体现出来了：

可以发现很多在页面上操作发现不了的bug
检查系统的异常处理能力
检查系统的安全性、稳定性
前端随便变，接口测好了，后端不用变

4、接口测试范围

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

5、接口测试的重点

1）检查接口返回的数据是否与预期结果一致。

2）检查接口的容错性，假如传递数据的类型错误时是否可以处理。

3）接口参数的边界值。例如，传递的参数足够大或为负数时，接口是否可以正常处理。

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

6、通用接口用例设计

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

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

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

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

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

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

7、接口自动化

为什么做接口自动化

接口测试我们有Postman、Jmeter工具，一般采用Postman+Newman+Git+Jenkins实现和Jmeter+Ant+Git+Jenkins实现，也能实现接口自动化功能，那为什么还要做代码级别的接口自动化呢？

主要有以下几点：

敏捷开发，迭代周期短、接口量大，这种情况下，如果仅仅使用工具级别的接口自动化很难协同，与同事间版本协同困难。

复杂场景的接口难以实现，加解密等
接口项目中有多种不同的协议
排错，定位接口问题不方便，要结合抓包实现才行
有些情况使用工具实现自动化比较困难，例如多接口串联、数据库验证、日志监控时

工具生成的报告不够直观
有些公司做web自动化+接口自动化难以实现

接口测试工具：Jmeter+Ant+csv+Jenkins+Alluer；
接口测试工具：Postman+newman+csv+Jenkins+Alluer；
接口自动化测试：Python+requests+pytest+yaml+alluer+Jenkins；

接口测试项目实战

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最耀眼的不是站在聚光灯下的瞬间，而是黑暗中依然前行的勇气。当你觉得撑不住时，请记住：每个伟大的突破都藏在"再坚持一天"的决定里。你的脚步，正在创造属于自己的传奇！

别被暂时的风雨模糊了视线！那些让你流泪的磨练，正在雕刻更璀璨的未来。当别人选择放弃时，你的坚持就是胜利的宣言。向前奔跑吧，整个世界都在等待你的光芒绽放！