接口测试用例设计：常见问题和风险

亦凉 2023-09-27 08:37 120阅读 0赞

### 一、接口测试 ###

接口测试，即对API进行测试。

接口测试过程容易出现的典型问题：

(1) 传入参数处理不当，导致程序奔溃

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

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

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

(5) 逻辑校验不完善，可利用漏洞获取非法正当权益

### 二、接口测试用例设计 ###

接口测试过程中，通常需要先编写测试用例，保证测试的覆盖性、准确性。

一份用例的好坏，决定着你测试接口的准确性和覆盖程度。

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

1、针对输入设计，输入即入参，常见的参数类型有：

· 数值型（int,long,float,double）

· 字符串类型

· 数组和链表

· 结构体(结构体（struct）是一些元素的结合，元素实际也是数值型，字符串型，数组或者链表数值型、字符串型、数组或者链表三种参数类型用例设计)

补充：针对输入设计，还需要覆盖必填参数、选填参数。

数值型

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

例如：检查权限的接口：TaskID的取值范围是1-35，那么设计时需考虑：

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

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

· 类型的特殊值：-1,0；

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

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

常见问题和风险：

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

2）类型边界溢出；

3）取值范围外值未返回正确的错误信息。

字符串型：

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

· 例如：接口转换设置闹钟的接口string ddhh ，用例需考虑：

· 长度：长度为4位，比4位少，比4位多

· 边界值：string的最大长度

· 特殊值：空字符

· 字符串内容可考虑类型：数字、非数字；

· 特殊字符；

· 如果用户输入切其他用户可见的内容，则需要考虑敏感字是否被正常过滤。

常见问题和风险：

1）传入非特定的类型程序异常退出。

2）超长字符未进行处理、导致存储、显示等异常。

3）其他用户可见设置的敏感字。

数组或链表类型

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

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

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

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

· 特殊值：0个；

· 合法id和不合法的；

· 重复的id等。

常见问题和风险：

1）0个item是程序异常退出。

2）重复的item处理时未去重导致数据异常。

2、针对逻辑设计

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

· 约束条件分析

· 关系限制分析

· 权限限制分析

· 操作对象分析

· 状态转换分析

· 时序分析分析

约束条件分析：

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

例如：Q币兑换要求积分>50才可以参加。

状态限制：登录状态等。

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

关系限制：

绑定的关系，好友关系等。

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

权限限制：

管理员等。

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

但是实际上，如果有其他手段，例如UI有bug或者通过技术手段直接调用手段，那么接口是否针对这些条件进行了限制尤为重要。

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

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

其他约束条件类似：

时间约束：22:00之前；

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

状态约束：登录手机管家等等约束条件类似。

常见问题和风险：

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

操作对象分析：

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

对象分析主要是针对合法和不合法对象进行操作。例如：

· 用户A查询电话P1话费

· 用户A查询电话P1流量

· 用户A查询电话P2话费

· 用户A查询电话的P2流量

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

常见的问题和风险：

用户可访问非权限内的其他用户信息、敏感信息，从而利用这些信息谋取利益。

状态转换分析

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

从某状态改变到新的状态，依赖于转换接口。而对于某转换接口，其输入状态是确定的，比如Fun23，这个函数只能把状态2转换为状态3，而不能将状态1转换为状态3，那么测试点就可以是：

·状态为2，调用接口，状态切换为23

· 状态为1,3等，调用接口，状态不可切换

那么可以这样设计：

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

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

常见的问题和风险：

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

时序分析:

在一些复杂的活动中，一个活动是由一系列动作按照指定顺序进行的，这些动作形成一个动作流，只有按照这个顺序依次执行，才能得到预期结果。

在正常的流程里，这些动作是根据程序调用依次进行的，并不会打乱，在接口测试时，需要考虑如果不按照时序进行，是否会出现问题。

例如：客户端数据同步是由客户端触发进行的，期间的同步用户无法干预。功能测试的时候可见的就是是否能正常进行同步，而进一步分析，同步流畅实现涉及了一组动作：

从时序图可以看出，后台又3个接口；登录获取用户ID，上报本地数据库，上报本地冲突。三个接口需要依次调用执行，才能完成同步。那么在接口测试就可以考虑打乱上诉接口的执行顺序去进行执行，会有怎样的接口，是否会出现异常。例如：获取用户ID后不上报本地数据而直接上报本地冲突。

常见问题和风险：

1）非顺序执行后，数据出现异常，可能还会出现程序其他异常。

2）通过打乱顺序获取利益。

3、针对输出结果设计

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

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

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

常见问题和风险：

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

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

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

接口超时情况：

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

· 未进行超时处理，导致整个流程阻塞；

· 超时后又收到接口返回，导致逻辑出现错乱。

**喜欢软件测试的小伙伴们，如果我的博客对你有帮助、如果你喜欢我的博客内容，请 “点赞” “评论” “收藏” 一 键三连哦！**  
![在这里插入图片描述][e5839dcedca14117aff9fd1945058bd6.gif_pic_center]

[e5839dcedca14117aff9fd1945058bd6.gif_pic_center]: https://img-blog.csdnimg.cn/e5839dcedca14117aff9fd1945058bd6.gif#pic_center

接口测试用例设计：常见问题和风险

发表评论取消回复

还没有评论，来说两句吧...

相关阅读

相关如何设计接口测试用例？

相关接口自动化测试用例如何设计

相关接口测试用例设计【最新版】

相关如何设计接口测试用例？（文末送接口测试用例模板）

相关接口测试用例设计：常见问题和风险

相关接口测试用例

相关常见测试用例的设计方法

相关常见测试用例

相关接口测试用例和报告模板

相关接口测试用例设计实践总结