史上最全，接口测试总结与用例设计规范，一文详全...

---

前言

1、为什么要做接口测试

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

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

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

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

2、接口测试范围

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

3、接口测试的重点

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

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

4、系统化的接口文档

传统的接口文档，一般采用word或wiki等系统来记录，从单次使用上似乎比较简单，因为大家会更习惯这样的操作，但这种形式存在比较大的问题：
接口文档非标准化，无法直接与接口测试工具接口使用
接口维护困难，接口有变化时比较难标识清楚，沟通成本很高

系统化接口文档，例如rap（淘宝分源的一个系统），具备接口维护标准化、版本化管理、MOCK测试等功能；对标准化的接口内容做二次开发，可以直接导出Soapui等工具使用的格式，直接导入工具中使用，有以下好处：
接口测试时不再需要手工输入相关字段，节省时间成本
版本化管理，能够清晰的知道哪些接口有变化

5、标准化的接口规范

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

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

如：系统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做为唯一，不同的接口参数做为接口变量，接口有参数变更时在原来接口上进行维护，而不是新增加接口
为接口增加版本号，方便清楚哪些接口本次有变更，易于维护用例

6、测试用例

接口测试用例的设计方法其实和功能测试用例的设计方法是类似的，因为接口是需要满足需求的，而接口测试所依赖的也是需求说明书，但是，因为接口测试毕竟是通过代码去测试代码。

所以，为了保证覆盖率，可能会使用到单元测试的方法，具体的测试用例设计，我考虑的如下，请参考，如果有错误，一起讨论。

输入参数测试：针对输入的参数进行测试，也可以说是假定接口参数的不正确性进行的测试，确保接口对任意类型的输入都做了相应的处理：输入参数合法，输入参数不合法，输入参数为空，输入参数为null，输入参数超长。

功能测试：接口是否满足了所提供的功能，相当于是正常情况测试，如果一个接口功能复杂时推荐对接口用例进行结构划分，这样子用例具有更好的可读性和维护性。

逻辑测试：逻辑测试严格讲应为单元测试，单元测试应保持内部逻辑的正确性，可单元测试和接口测试界限并不是那么清楚，所以我们也可以从给出的设计文档中考虑内部逻辑错误的分支情况和异常；

异常情况测试：接口实现是否对异常情况都进行了处理，接口输入参数虽然合法，但是在接口实现中，也会出现异常，因为内部的异常不一定是输入的数据造成的，而有可能是其他逻辑造成的，程序需要对任何的异常都进行处理。

7、用例设计规范考虑

1）通过性验证

先按照接口文档传入所有必填字段并且字段值在正确范围内，预期返回正确结果

2）参数验证（正向/逆向）

必填参数：针对每个必填参数，都设计一条参数为空的测试用例，接口错误信息返回正确

非必填参数：设计一条用例所有非必填的参数都传入值，非必填参数（类型，范围）不正确，是否给出合理提示

参数值范围：参数的值在/不在接口文档中规定参数值范围内
长度边界值：符合长度范围内的，长度边界值，超过长度边界值的类型：符合参数类型的，不符合参数类型的（数组，字符串,正数，负数，整数，小数，小数点位数，中文，英文，特殊符号）

特殊值：空、null、“null”、“”、" "、0、值的前后带有空格、特殊符号等
接口文档中不存在的参数：接口传入文档中不存在的参数不会异常
接口中传入的参数被覆盖：重复传入相同的key，但value不同

传入的参数格式不对：非json、少括号

参数个数：如果接受列表类型的参数，如果对列表大小没有进行限定则传入一个超大列表，如果对列表大小进行了规范则需要测试列表大小的边界值；接口能否正确返回数据；

3）参数组合

很多时候，接口中的参数有多个取值来满足不同的业务逻辑，当这样的参数>1时，就会出现参数组合的场景。

例如参数A可传[1，2，3]
参数B可传["first"，"second"，"third"]

存在的组合：返回信息正确
不存在的组合：错误信息通俗易懂，错误码正确
参数组合中参数的个数：若多个参数组合，是否允许任意多个参数的随机组合（例如2个参数组合、3个参数组合、不传）

4）接口前提条件验证

前提条件是否满足：

token（token失效/token格式不对/token类型不对、登录退出登录其他账号）
headers（例如Content-Type：application/json; charset=utf-8 、不填）

5）接口返回信息和状态码等正确

状态码正确
错误信息没有歧义（增：调用了一次新增接口之后再调一次新增接口，删：调用了一次删除接口之后再调一次删除接口）

返回数据的结构正确
返回数据字段值类型正确

6）数据操作正确性验证

如果接口是操作数据相关的，需要查看数据的流转和持久化是否正确完成，一般查看MySQL和Redis是否有相应的CUD操作即可

7）并发能力

也就是对接口做性能测试，验证并发能力是否满足预期

8）接口权限/安全

权限控制：当借口只有特定权限的用户才能操作时，验证不同权限的用户的处理逻辑

幂等校验：抓包工具拦截请求，修改敏感字断值
事务/锁校验：同时操作同一条数据的修改操作，给出正确信息
参数非明文：参数是否加密，加密规则是否易破解
密码复杂度：密码安全规则，密码的复杂程度校验

9）弱网验证

弱网下，接口是否可以正常响应

接口测试项目实战

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

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最动人的篇章，往往写在最艰难的转折之后。当你觉得力不从心时，请记住：每一个"不可能"的突破，都始于"再试一次"的勇气。你的坚持，正在为世界书写新的可能！

别让他人的质疑成为你的枷锁！你体内蕴藏着改变命运的力量，每个微小的进步都在为辉煌铺路。当别人停下脚步时，你的坚持就是最有力的回应。向前走，属于你的舞台正等待绽放！