接口测试用例设计超细整理，5年测试老鸟分享，一篇概全...

原创于 2025-09-04 16:19:54 发布 · 599 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#软件测试 #软件测试工程师 #自动化测试 #接口自动化测试 #接口测试 #测试用例 #jmeter接口测试

软件测试同时被 3 个专栏收录

314 篇文章

订阅专栏

软件测试工程师

207 篇文章

订阅专栏

接口测试

47 篇文章

订阅专栏

目录：导读

前言

1、什么是接口测试

接口测试：测试系统组件间接口的一种测试。主要用于检测外部系统与系统之间以及系统内部各个子系统之间的交互点。重点测试的是数据的交换，这要求对业务逻辑有一定程度上的理解，对数据流向有较好的定位。

接口测试的过程：通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（request→response）

接口测试的作用：降低成本，提高效率。接口测试能够提供系统复杂度上升情况下的低成本高效率的解决方案。它是一个完整的体系，还包括功能测试，性能测试等。

2、用例设计

测试用例主要从业务场景，功能以及异常测试几个方面考虑；具体测试用例的参考点：

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

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

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

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

3、脚本设计

接口测试脚本有哪些要求：结构好，可读性高，渗透性强。脚本设计步骤：

a）准备测试环境：初始化、注册主动回调函数
b）代码：封装被调用接口
c）数据：准备测试数据
d）执行用例：(1)数据初始化；(2)调用接口
e）执行结果：(1)返回值断言比较；(2)垃圾数据清理

关于接口测试的测试数据：
分为两部分：接口参数数据和用例执行所需系统数据。接口参数数据需要对每个参数根据测试接口的实际功能进行分析，在符合业务逻辑的情况下进行逻辑组合排列，不要遗漏某些边界值和错误点的数据，这样用例更容易发现问题。

关于单元测试，接口测试和白盒测试

a）单元测试：针对具体代码逻辑进行测试，主要测试被测代码的一个很小，很明确的功能是否正确。即单元模块的逻辑是否正确，对业务关注不大；

b）接口测试：针对程序内部的或者外部的接口进行的测试一个接口方法可能包含多个单元模块，并且，一个接口会有自己特定的业务定义：做接口测试更多的从业务的角度去考虑如何测试；

c）白盒测试：单元测试和接口测试都属于白盒测试的一个阶段

4、接口测试发现的典型问题

接口测试经常遇到的bug和问题，如下：
1）传入参数处理不当，导致程序crash；
2）类型溢出，导致数据读出和写入不一致；
3）因对象权限未进行校验，可以访问其他用户敏感信息；
4）状态处理不当，导致逻辑出现错乱；
5）逻辑校验不完善，可利用漏洞获取非正当利益等。

5、测试用例编写

一个接口通常是有输入输出的，输入就是我们常见的入参，输出有时有，有时没有。调用相关接口，接口会执行相关处理逻辑。

接口测试的用例设计，主要从输入和接口处理两方面考虑：
1）针对输入，可按照参数类型进行设计；
2）针对接口处理，可按照逻辑进行用例设计；
3）针对输出，可根据结果进行分析设计。

针对输入设计：

对于接口来说，输入就是入参。常见参数类型有:
1）数值型(int,long,float,double等）
2）字符串类型
3）数组或链表
4）结构体

结构体(struct)是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。
下面详细说明数值型、字符串型、数组或链表三种参数类型用例设计。

数值型：

数值型的参数主要考虑以下几个方面设计：

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。
例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID的取值范围是1-35，那么设计时考虑：

●1-35范围内和范围外的值；
●1-35的边界：0，1,35,36；
●类型的特殊值：-1,0
●数据类型的边界值：int的最小值最大值；
●因为1-35代码的权限ID不同，可能需要遍历1-35的每个值。
常见问题和风险：
●特殊值处理不当导致程序异常退出；
●类型边界溢出
●取值范围外值未返回正确的错误信息等

字符串型：

字符串型的参数，主要考虑字符串的长度和内容：

例如接口转换设置闹钟的接口DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：
●长度为4位，比4位少，比4位多；
●边界值：String的最大长度；
●特殊值：空字符；
●字符串内容可考虑类型：数字，非数字；
●特殊字符。

●如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。
可能出现的问题和风险：
●传入非特定类型程序异常退出
●超长字符未进行处理，导致存储、显示等异常
●其他用户可见设置的敏感字

数组或链表类型：

参数类型为数组或链表时，用例可以考虑：

例如批量提交任务的接口submitTask(int[] taskID)，参数用例设计考虑：
●正常取值：1-5个权限，范围外：6个权限；
●边界值：1-35的边界值，请求允许最大最小值；
●特殊值：0个；
●合法ID和不合法的；
●重复的ID等。

可能存在的问题和风险：
●0个item时程序异常退出；
●重复的item处理时未去重导致结果异常等。

针对逻辑设计：

接口需要进行一些逻辑处理的，那么按逻辑设计用例可以从以下几个角度分析。

约束条件分析：
1）数值限制：分数限制、金币限制、等级限制等等。
例如：兑换Q币活动要求积分>50才可参与。

2）状态限制：登录状态等。
例如：同步用户信息需要先登录账号。

3）关系限制：绑定的关系，好友关系等。
例如：帮家人防骗功能只能查询绑定家人的来电信息。

4）权限限制：管理员等。
约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。

但是实际上，如果有其他手段：例如UI有bug或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。
例如常见的例子：要兑换5Q币需要200积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态：

正常用户是无法操作的，但是兑换其实是调后台的一个接口，如果绕过页面按钮的限制，直接调用后台接口兑换呢？是否可以兑换？预期当然是不能兑换的。因此积分这个数值限制就需要针对接口进行测试，并且非常重要。

其他约束条件类似：
●时间约束：22：00之前；
●数值约束：积分200；限量5个；
●状态约束：登录手机管家；
●等等约束条件类似。

常见的问题和风险：
约束条件判断不足，导致用户可通过特殊手段获取利益

操作对象分析：

操作通常是针对对象的，例如用户绑定电话号码，电话号码就是操作对象，而这个电话号码的话费、流量也是对象。

对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:
●用户A查询电话P1话费：
●用户A查询电话P1流量；
●用户A查询电话P2话费；
●用户A查询电话P2流量。

后台的逻辑处理，如果一个电话已经被绑定过，从后台的角度是可以查询到该电话的话费和流量的。但是在用户侧，应该是A绑定了的电话，才能让A查询到该电话的话费。故类似对象的测试也必不可少。

常见的问题和风险：
●用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。

状态转换分析：

被测逻辑可以抽象成状态机，各个状态之间根据功能逻辑从一个状态切换到另一个状态。如果我们打乱了这个次序，从一个状态切换到另一个不在它下一状态集中的状态，那么逻辑将会打乱，就会出现逻辑问题。

如上图所示，从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23, 这个函数只能把状态2转换为状态3，而不能把状态1转换为状态3。
那么测试点就可以是：
1）状态为状态2，调用接口Fun23（），状态切换到状态23；
2）状态为1,3等，调用接口Fun23（），状态不能切换。

例如在做任务的时候，任务有三种状态：未领取，已领取未提交，已完成三种状态。

那么可以这样设计：
1）正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。
2）非正常的状态切换：未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。

常见的问题和风险：
可通过特殊手段达到原本不能的状态，从而谋取利益。

针对输出设计：

针对输出设计其实是针对接口返回的结果进行分析。

针对输出结果：

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。

例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：

覆盖返回码也是用例设计的一种思路。
常见问题和风险：
1）错误前端处理不足，导致前端异常；
2）错误提示处理不当，导致用户看到晦涩的错误码；
3）错误提示不当，导致用户不知道哪里出了问题，如何解决。

接口超时：
接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：
1）未进行超时处理，导致整个流程阻塞
2）超时后又收到接口返回，导致逻辑出现错乱

接口测试项目实战

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