浅谈接口测试用例设计

 

1、接口测试

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

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

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

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

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

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

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

2、接口测试用例设计

接口测试过程当中，一般须要先编写测试用例，保证测试的覆盖性、准确性。

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

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

1. 针对输入，可按照参数类型进行设计
2. 针对接口处理，可按照逻辑进行设计
3. 针对输出，可根据返回结果进行分析

 

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

1. 数值型（int,long,float,double）
2. 字符串类型
3. 数组和链表
4. 结构体(结构体（struct）是一些元素的结合，元素实际也是数值型，字符串型，数组或者链表数值型、字符串型、数组或者链表三种参数类型用例设计)

 

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

 

数值型

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

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

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

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

l 类型的特殊值：-1,0

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

l 1-35代码的权限ID不一样，可能须要遍历1-35的每一个值

 

常见问题和风险：

1. 特殊值处理不当致使程序异常退出；
2. 类型边界溢出；
3. 取值范围外值未返回正确的错误信息

 

字符串型：

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

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

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

l 边界值：string的最大长度

l 特殊值：空字符

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

l 特殊字符

l 若是用户输入切其余用户可见的内容，则须要考虑敏感字是否被正常过滤

 

常见问题和风险：

1. 传入非特定的类型程序异常退出
2. 超长字符未进行处理、致使存储、显示等异常
3. 其余用户可见设置的敏感字

 

数组或链表类型

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

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

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

l 边界值：1-35的 边界值，请求容许最大最小值

l 特殊值：0个；

l 合法id和不合法的；

l 重复的id等

 

常见问题和风险：

1. 0个item是程序异常退出
2. 重复的item处理时未去重致使数据异常

 

 

二、针对逻辑设计

接口须要进行一些逻辑处理的，按照逻辑设计用例能够从如下几个角度分析

1. 约束条件分析
2. 关系限制分析
3. 权限限制分析
4. 操做对象分析
5. 状态转换分析
6. 时序分析分析

约束条件分析：

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

例如：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，那么测试点就能够是：

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

那么能够这样设计

1. 正常的状态切换：未领取状态，领取任务后变为已领取状态；已领取知足任务条件提交后，变成已完成状态；完成后能够再次领取任务。
2. 非正常的状态切换：未领取任务知足任务条件直接提交任务；已领取时再次领取任务等

常见的问题和风险：

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

 

时序分析:

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

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

 

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

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

 

常见问题和风险：

1. 非顺序执行后，数据出现异常，可能还会出现程序其余异常
2. 经过打乱顺序获取利益

 

三、针对输出结果设计

接口处理正确的结果可能只有一个，可是错误异常返回接口有不少状况不少值，若是知道返回结果有不少种，就能够针对不一样结果设计用例。

例如：提交积分任务的时候咱们一般能想到的是返回正确和错误，错误可能想到：无效任务、无效登陆态，可是不必定可否彻底覆盖全部错误码，而接口返回定义的返回码能够设计更多用例

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

 

常见问题和风险：

错误前端处理不足，致使前端异常

错误提示处理不当，致使用户看到晦涩的错误码

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

 

接口超时状况：

接口正常状况下试有返回的，那么若是接口不返回呢，也就是接口超时后的处理也是测试须要考虑的部分，若是超时处理不当，能够会引出一下问题：

1. 未进行超时处理，致使整个流程阻塞
2. 超时后又收到接口返回，致使逻辑出现错乱

 

文章转载其余人页面，忘记是哪位好心人分享了，