最详细软件测试接口测试用例设计-怎么编写-模板（最详全）

一、前言

1、接口测试

对功能的验证，可以参照接口说明文档来进行

概括起来讲，就是我们需要验证接口说明文档中提到的各种情况，保证这些情况下接口的返回和最初设计的是一样的，这样我们就可以认为该接口实现了功能需求

接口测试用例设计思路

1、暴露在外面的接口，因为通常该接口会给第三方调用。

2、供系统内部调用的核心功能接口。

3、供系统内部调用非核心功能接口。

4、正向用例优先测试,逆向用例次之(通常情况，非绝对)。

5、是否满足前提条件 > 是否携带默认参值参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围值限制

是否满足前提条件

有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token

针对是否满足前置条件(假设为n个条件)，设计0~n条用例

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

接口测试经常遇到的 bug 和问题

如下：

（1）传入参数处理不当，导致程序 crash

（2）类型溢出，导致数据读出和写入不一致

（3）因对象权限未进行校验，可以访问其他用户敏感信息

（4）状态处理不当，导致逻辑出现错乱

（5）逻辑校验不完善，可利用漏洞获取非正当利益等

二、接口测试用例设计

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

接口测试的用例设计，主要从输入和接口处理两方面考虑：

1）针对输入，可按照参数类型进行设计；

2）针对接口处理，可按照逻辑进行用例设计；

3）针对输出，可根据结果进行分析设计。

1、针对输入设计

对于接口来说，输入就是入参。常见参数类型有:

（1）数值型 (int,long,float,double 等）

（2）字符串类型

（3）数组或链表

（4）结构体

结构体 (struct) 是一些元素的结合，元素实际也是数值型，字符串型，数组或链表。

下面详细说明数值型、字符串型、数组或链表三种参数类型用例设计。

1.1、数值型

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

如果参数规定了值的范围，则需要考虑等价类取值范围内、取值范围外，取值的边界，如有需要，可能会遍历取值范围内的各个值。

例如检查权限的接口：TaskChecker.checkTask(int taskID) taskID 的取值范围是 1-35，那么设计时考虑：

1-35 范围内和范围外的值

1-35 的边界：0，1,35,36；

类型的特殊值：-1,0

数据类型的边界值：int 的最小值最大值

因为 1-35 代码的权限 ID 不同，可能需要遍历 1-35 的每个值

常见问题和风险：

特殊值处理不当导致程序异常退出；

类型边界溢出

取值范围外值未返回正确的错误信息等

1.2、字符串型

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

例如接口转换设置闹钟的接口 DateUtil.getDayOfDDHH(String ddhh)，用例可以考虑：

• 长度为 4 位，比 4 位少，比 4 位多；

• 边界值：String 的最大长度；

• 特殊值：空字符

• 字符串内容可考虑类型：数字，非数字；

• 特殊字符

• 如果是输入用户输入且其他用户可见的内容，则还需要考虑敏感字是否被正常过滤。可能出现的问题和风险

• 传入非特定类型程序异常退出

• 超长字符未进行处理，导致存储、显示等异常

• 其他用户可见设置的敏感字

1.3、数组或链表类型

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

例如批量提交任务的接口 submitTask(int[] taskID)，参数用例设计考虑：

正常取值：1-5 个权限，范围外：6 个权限；

边界值：1-35 的边界值，请求允许最大最小值；

特殊值：0 个；

合法 ID 和不合法的；

重复的 ID 等。

可能存在的问题和风险：

0 个 item 时程序异常退出；

重复的 item 处理时未去重导致结果异常等。

三、针对逻辑设计

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

1、约束条件分析

（1）数值限制：分数限制、金币限制、等级限制等等。

例如：兑换 Q 币活动要求积分>50 才可参与。

（2）状态限制：登录状态等。

例如：同步用户信息需要先登录账号。

（3）关系限制：绑定的关系，好友关系等。

例如：帮家人防骗功能只能查询绑定家人的来电信息。

（4）权限限制：管理员等。

约束条件的测试在功能测试中经常遇到，在接口测试中更为重要。它的意义在于：用户进行操作时，在该操作的前端可以已经进行了约束条件的限制，故用户无法直接触发请求该接口。但是实际上，如果有其他手段：例如 UI 有 bug 或者通过技术手段直接调用接口，那么接口是否针对这些条件进行了限制就尤为重要。

例如常见的例子：要兑换 5Q 币需要 200 积分，但是我积分不足，所以兑换按钮是灰色无法点击的状态：

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

其他约束条件类似：

• 时间约束：22：00 之前；

• 数值约束：积分 200；限量 5 个；

• 状态约束：登录手机管家；

• 等等约束条件类似。

常见的问题和风险：

• 约束条件判断不足，导致用户可通过特殊手段获取利益

2、操作对象分析

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

对象分析主要是针对合法和不合法对象进行操作。例如下述用例子:

• 用户 A 查询电话 P1 话费

• 用户 A 查询电话 P1 流量

• 用户 A 查询电话 P2 话费

• 用户 A 查询电话 P2 流量

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

常见的问题和风险：

• 用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。
  ###3 状态转换分析

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

如上图所示，从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如 Fun23, 这个函数只能把状态 2 转换为状态 3，而不能把状态 1 转换为状态 3。

那么测试点就可以是：

（1）状态为状态 2，调用接口 Fun23（），状态切换到状态 23；

（2）状态为 1,3 等，调用接口 Fun23（），状态不能切换。

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

那么可以这样设计：

（1）正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取满足任务条件提交后，变成已完成状态；完成后可以再次领取任务。

（2）非正常的状态切换：未领取任务满足任务条件直接提交任务；已领取时再次领取任务等等。

常见的问题和风险：

可通过特殊手段达到原本不能的状态，从而谋取利益。

四、针对输出设计

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

1、针对输出结果

接口处理正确的结果可能只有一个，但是错误异常返回结果有很多情况很多值。如果知道返回结果有很多种，就可以针对不同结果设计用例。例如提交积分任务的时候我们通常能想到的是返回正确和错误，错误可能想到：无效任务，无效登录态，但是不一定能否完全覆盖所有错误码，而接口返回定义的返回码可以设计更多用例：

覆盖返回码也是用例设计的一种思路。

常见问题和风险：

（1）错误前端处理不足，导致前端异常；

（2）错误提示处理不当，导致用户看到晦涩的错误码；

（3）错误提示不当，导致用户不知道哪里出了问题，如何解决。

2、接口超时

接口正常情况下是有返回的，那么如果接口不返回呢？也就是说接口超时后的处理也是测试需要考虑的部分。如果超时处理不当，可能会引起以下问题：

（1）未进行超时处理，导致整个流程阻塞

（2）超时后又收到接口返回，导致逻辑出现错乱

五、其他测试设计

1、接口设计合理性分析

接口定义是否合理可以从以下几个方面分析：

（1）接口字段是否冗余；

（2）接口是否冗余；

（3）接口是否返回了调用方期望得到的信息；

（4）接口定义是否可满足所有调用需求；

（5）接口定义调用是否方便。

六、实例

下面举一个完整例子，通过上述方法来分析如何对接口进行用例设计。

某模块提供了一个接口给其他模块，用户请求任务，接口定义如下：

1、针对输入设计

dialogDetailText（dialogButtonText 类似）

长度

1）正常：请安装提示进行操作；

2）边界：一个字：请；长度非常长：无悬浮窗权限，可能影响 XX 功能无法使用，请开始悬浮窗权限，以便获得更好的用户体验；甚至更长；

3）特殊：空字符串。

内容

1）特定类型：中文，英文，数字等；

2）特殊字符：/n/r/t ,.><?*$&%~"ஜღ℡♬€✎等；

3）敏感字符：非用户设置，不涉及。

taskID（requestType 类似）

等价类

取值范围内：1,5,10 等；

取值范围外：0，99。

边界法

取值范围边界：0,1,38,39,40

数据类型边界：-2147483648 ,2147483648

特殊值：0,-1 等。

遍历法：1,2,3,4,5…38,39 对应每种不同 ID。

2、针对逻辑设计

（1）约束条件分析

去引导某功能需要：未完成过任务，任务有任务数据。

那么用例可以是：以下情况下调 requestTask：

1）未使用过有任务数据时；

2）未使用无任务数据时；

3）使用过有任务数据时；

4）使用过无任务数据时。

如果有其他约束条件类似设计。

（2）操作对象分析

调用请求接口后，会显根据任务数据，引导对应的任务。任务数据，任务操作方式，任务功能都可以是对象。

1）任务数据

数据类型：本地，云端 等

数据有效性：正确数据，错误数据

2）操作方式

方式：安装，下载，打开等等 。

3）任务功能

功能：用户操作了该功能，未正常操作该功能；什么都不操作；完成一个任务功能；完成多个任务功能；任务功能使用顺序等等。

对象：还需要关注，会不会操作到不合法的对象，例如任务数据和功能不对应等问题。

（3）状态转换分析

功能是有 4 个状态的：完成，未完成，未知。状态图如下：这里是产品里涉及的状态转换：

针对该状态：

1）正常状态转换：未完成状态请求并完成任务后是否可变成完成状态；未完成状态请求但不完成，还是未完成状态。

2）走不到的状态路径：未知和完成状态请求任务，不能进行进行该任务。

（4）时序分析

从时序的角度分析，调用请求接口前需要以下 2 步动作：

1）拉取任务数据；

2）判断任务状态。

从时序得到的用例有：

正常时序：按照正常时序请求 1 2 3；

缺失的时序

缺少动作 1 调 2 3；缺少动作 2 调 1 3；缺少动作 1 和 2 直接调。

打乱的时序

打乱的时序：2 1 3，还可以有 1 3 2，2 3 1，3 1 2，3 2 1。

针对处理逻辑的设计中，可能使用某一种或某几种方式就可以将用例覆盖前，故实际使用中，可能不会全部使用，只要找到最合适的方式覆盖用例即可。

3、针对输出分析

请求任务接口返回的数据是任务完成结果，即返回完成，未完成两种状态（未知都作为完成返回）。

从结果可以考虑遍历：

1）未完成

2）完成

3）完成 - 未知

从接口处理时间分析，考虑：请求后快速返回，很长时间才返回，甚至不返回结果的情况

七、总结

以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：

主流程测试用例：正常的主流程功能校验。

分支流测试用例：正常的分支流功能校验。

异常流测试用例：异常容错校验。

在进行服务端测试的时候，性能和安全性方面的用例是必须要考虑的。服务端的性能测试往往与功能性测试分开执行，一般情况下在服务端的功能测试进行完毕保证功能上没有问题的情况下，可以进行性能测试

性能测试借助于一些工具开展，比如LoadRunner等，关于性能测试，在后续的分享中我们会为大家详细介绍

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取