测试老鸟整理，接口测试+接口自动化面试题，一篇概全...

---

前言

1、单接口测试（场景测试）

1）json格式测试
通常我们的接口一般设计的都是传递json串，那么就需要去测试
如果传递非json的情况，这时候程序会不会正确的处理，返回相应的 error code

2）默认值测试
很多情况一些非必填的参数会有默认值，比如说一个查询的接口，参数count为返回查询的结果数量，默认为10，那么就应该有一条case来测试，当然前置条件是数据库里面必须要存在这样的数据超过10条。

3）异常类型测试
比如上面的count参数，这个参数的类型一定是可以转换为int类型的，这时候我们需要测试如果传的一些不可以转换为int类型值来测试代码是否加入判断

4）必传项测试
如果接口的参数有必传项，那么需要测试在不传这个参数的时候接口返回情况，测试是否会提示相应的error code

5）非必传项测试
如果接口有非必填项，当我不传递这些参数的时候会不会正常的返回相应的结果

6）非空测试
无论是必传的和非必传的参数，传递的key是正确的，但是value=null，这时候返回结果是否正确

7）业务逻辑测试
传递正确的参数，接口对数据库进行查询的操作，需要去验证数据库查询是否正确，接口对数据库进行增删改的操作，也需要看数据库是否同步进行了这些操作

8）兼容性测试
比如说今天接口进行了调整，但是前端没有进行变更，这时候需要验证新的接口是否满足旧的调用方式

9）错误码测试
通用的错误码与业务错误码是否能够清晰的说明调用问题，错误码是否能够尽可能的全的覆盖所有的情况

10）数据异常测试
假如数据库设计为32位varchar类型，那么如果传33位会是什么情况，会不会抛出相应的错误码，而不会抛出数据库异常

11）返回值测试
返回值除了内容需要是正确的，还需要类型也是正确的，保证调用方拿到这些参数能够正确的解析

12）加密测试
组合接口测试（场景测试）

单个的接口测试通过后，需要将单个的接口组成连续的场景，比如说投资接口需要用到一个类似token的 参数，而这个参数是登陆接口获取到的，所以就需要先调用登陆接口，然后再去调用投资接口。

还有就是 像数据权限与操作权限这些，都会依赖一些其他的接口，那么把这些依赖的接口组成一个场景来测试数据的 正确性。

还有一部分接口是内部调用的，比如说注册接口，在注册的时候通常需要获取一个验证码，然后输入 验证码再进行提交注册的操作，在这过程中，验证验证码的操作是在注册的内部完成的，那么其实在组合场景 的时候就不需要再去中间加入验证验证码的接口。

2、接口测试流程

测试计划->需求分析 -> 用例设计 -> 框架设计及脚本开发 -> 测试执行 -> 结果分析->持续集成

流程分成以下八步：

第一步：确定测试范围，测试排期、人员安排
第二步：分析出测试需求，并请开发提供接口说明文档；
第三步：设计测试用例，里面要包括详细的入参（正常情况，异常情况包括输入参数个数，类型，可选/必选，特殊字符、考虑参数有互斥或关联的情况） 和出参数据（符合接口文档需求）；
第四步：与开发一起对接口测试用例进行评审；
第五步：开始执行接口自动化测试用例；
第六步：BUG管理及追踪
第七步：测试报告总结；
第八步：完成后进行自动化持续集成；

接口测试注意点：

1）明确接口定义：了解接口的功能、输入输出参数、数据格式等，确保测试的准确性。
2）测试边界条件：覆盖正常和异常情况，包括最大值、最小值、空值等。
3）测试正常流程：确保接口在正常情况下的运行情况。
4）测试异常情况：模拟错误输入、错误参数等，检查接口的错误处理能力。
5）测试参数组合：尝试不同的参数组合，以发现潜在的问题。

3、接口自动化面试题

1）接口自动化流程怎么做的，框架怎么搭建的？

流程：
分析需求，确定测试范围；
搭建自动化测试环境、准备相关测试数据；
工具选型，搭建测试框架；
编写用例；
执行用例，生成测试报告；
持续集成；

框架怎么搭建：如果是选择用现有框架的话，可以选择postman、jmeter、Robotframework等框架，也可以基于一些开源的框架平台上再去进行二次开发，比如httprunner等，觉得都用不习惯的话，可以考虑自己写代码封装新的框架。看这套面试题，求职者应该回答的是自己写代码的方式。

自己框架搭建要考虑的问题：

用例怎么存储，编写是否方便，易用性怎么样，学习成本高不高；
用例执行执行，日志，报告等如何查看；
断言如何设计，用例执行失败怎么处理等；
多人协作怎么管理代码等；

2）你们公司没有通用的接口自动化框架吗？为什么还需要你们部门来搭建这套。

开源框架有开源框架的好处，但是也存在一些问题，有些数据处理起来没这么方便，易用性方面使用起来也不一定很方便，需要一定的学习成本。每个部门的业务场景不一样，开发平台/工具主要还是从成本以及解决某个实际问题的方便去考虑。

3）接口自动化回归过程中有没有发现什么问题？取得了怎么样的效果和收益？

比如有时候，开发改某个需求，改动了一些公共的代码之类的，就有可能影响到其他的接口，如果之前稳定的接口已经写好用例的话，这种情况下就能快速的验证出来改动是否有问题。

效果和收益的话，可以说一下接口自动化做起来之后，之前手动回归的功能现在变成自动回归了，节省了多少人力/时间。

4）接口自动化搭建和落地过程中遇到什么问题？

用例怎么存储更方便，怎么样设计才能使得编写用例的时候方便，有没有什么办法自动生成用例，用例之间的依赖和数据传递怎么做，用例是否要区分环境，有些用例如果只能在测试环境执行，线上不能执行的，如何区分。怎么样设计能够支持快速切换到其他不同的平台上面去。

5）最难的技术难点是什么？

动态变量参数化、接口依赖及中间变量问题、异步接口结果验证问题、相应参数化及嵌套很多的验证问题、接口测试框架的稳定性问题、多接口场景问题、多线程并发、多项目以及不同人员并发操作的情况。

6）你们持续集成是怎么做的？

持续集成的话，一般都是跟部署结合一起一起使用，比如测试环境更新后，自动触发用例执行。另外，可以设置每晚定时自动构建。

7）有了jmeter等开源的接口自动化平台，为什么还要代码来做自动化？

哈哈，这个也是我想问那些自己写代码做自动化的，以及现在的一些培训机构教的java或者python自动化的模式，为什么不选用开源的框架或平台。其实，大家都心知肚明，自己写脚本写框架，更能体现你的水平，能够拿到的薪资更高。

自己写代码，在一定程度上，可以省去对工具的学习成本，虽然说工具的使用不难，但是要把工具用好也不容易，并不是只有写代码才能体现出你的能力。而且，写代码之前，要先了解一下现有工具的一些功能，看下有没有必要自己写代码封装框架。

8）你主要负责参与哪部分框架搭建，你们怎么合作共享代码的？

代码传递的话，一般都是通过git仓库去管理，然后再通过分支去管控，这个可以参考开发的代码分支管理。

9）数据驱动，关键字驱动怎么做的？

数据驱动的话，有相应的包直接可以支持。关键字驱动的话，可以参考Robotframework框架，我所理解的关键字驱动，其实就是一种代码约定。

接口测试项目实战

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最精彩的不是实现梦想的瞬间，而是追梦路上那个永不言弃的自己。那些看似遥不可及的目标，终会在你日复一日的坚持中触手可及。别怕慢，怕的是停下；别怕难，怕的是放弃！

你比自己想象的更强大！每个挫折都是成长的契机，每次坚持都在改写命运的轨迹。当别人选择放弃时，你的执着就是胜利的开始。向前奔跑吧，整个世界都会为追光者让路！