接口测试 [腾讯 TMQ] 接口测试用例设计

匿名 · 2018年01月17日 · 最后由 你来咬我啊 回复于 2020年06月12日 · 17900 次阅读
本帖已被设为精华帖!

作者:刘燕

团队:腾讯移动品质中心(TMQ)

导语

随着测试分析和分层测试的深化,“接口测试” 出现在我们视野的频次越来越高。那么接口测的用例设计常用哪些方法呢?本文将详细描述。

1 接口测试

1.1 接口测试

接口:主要是子模块或者子系统间交互并相互作用的部分。

这里说的接口是广义的,客户端与后台服务间的协议;插件间通信的接口;模块间的接口;再小到一个类提供的方法;都可以理解为接口。

接口测试:是指针对模块或系统间接口进行的测试。

1.2 接口测试发现的典型问题

接口测试经常遇到的 bug 和问题,如下:

(1)传入参数处理不当,导致程序 crash;

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

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

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

(5)逻辑校验不完善,可利用漏洞获取非正当利益等。

2 接口测试用例设计

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

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

1)针对输入,可按照参数类型进行设计;

2)针对接口处理,可按照逻辑进行用例设计;

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

2.1 针对输入设计

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

(1)数值型 (int,long,float,double 等)

(2)字符串类型

(3)数组或链表

(4)结构体

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

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

2.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 的每个值。

常见问题和风险:

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

  • 类型边界溢出

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

2.1.2 字符串型

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

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

  • 长度为 4 位,比 4 位少,比 4 位多;

  • 边界值:String 的最大长度;

  • 特殊值:空字符;

  • 字符串内容可考虑类型:数字,非数字;

  • 特殊字符。

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

可能出现的问题和风险:

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

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

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

2.1.3 数组或链表类型

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

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

  • 正常取值:1-5 个权限,范围外:6 个权限;

  • 边界值:1-35 的边界值,请求允许最大最小值;

  • 特殊值:0 个;

  • 合法 ID 和不合法的;

  • 重复的 ID 等。

可能存在的问题和风险:

  • 0 个 item 时程序异常退出;

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

2.2 针对逻辑设计

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

2.2.1 约束条件分析

(1)数值限制:分数限制、金币限制、等级限制等等。

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

(2)状态限制:登录状态等。

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

(3)关系限制:绑定的关系,好友关系等。

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

(4)权限限制:管理员等。

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

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

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

其他约束条件类似:

  • 时间约束:22:00 之前;

  • 数值约束:积分 200;限量 5 个;

  • 状态约束:登录手机管家;

  • 等等约束条件类似。

常见的问题和风险:

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

2.2.2 操作对象分析

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

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

  • 用户 A 查询电话 P1 话费:

  • 用户 A 查询电话 P1 流量;

  • 用户 A 查询电话 P2 话费;

  • 用户 A 查询电话 P2 流量。

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

常见的问题和风险:

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

2.2.3 状态转换分析

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

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

(1)状态为状态 2,调用接口 Fun23(),状态切换到状态 23;

(2)状态为 1,3 等,调用接口 Fun23(),状态不能切换。

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

那么可以这样设计:

(1)正常的状态切换:未领取状态,领取任务后变为已领取状态;已领取满足任务条件提交后,变成已完成状态;完成后可以再次领取任务。

(2)非正常的状态切换:未领取任务满足任务条件直接提交任务;已领取时再次领取任务等等。

常见的问题和风险:

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

2.2.4 时序分析

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

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

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

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

常见的问题和风险:

  • 非顺序执行后,数据出现异常,可能还会出现程序其他异常

  • 通过打乱顺序获取利益

2.3 针对输出设计

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

2.3.1 针对输出结果

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

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

常见问题和风险:

(1)错误前端处理不足,导致前端异常;

(2)错误提示处理不当,导致用户看到晦涩的错误码;

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

2.3.2 接口超时

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

(1)未进行超时处理,导致整个流程阻塞

(2)超时后又收到接口返回,导致逻辑出现错乱

2.4 其他测试设计

2.4.1 已废弃接口测试

已废弃协议,是指之前有定义,但是因为需求变更或其他原因,目前版本不用。这些接口虽然不再使用,但有可能代码并没有及时删除。如果利用技术手段调用这些接口,可能获取额外利益。

例如,任务之前有个清理任务,在一个版本需求里将清理任务替换为下载任务。在新版本客户端已不再调用完成清理任务的接口;但是如果该接口未关闭,用户就可以继续请求 submitTask(int taskID) 接口完成清理任务获得积分。

因此新版本在考虑兼容旧版本的同时,还应做好相关废弃接口的检查,避免用户获得额外利益。

2.4.2 接口设计合理性分析

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

(1)接口字段是否冗余;

(2)接口是否冗余;

(3)接口是否返回了调用方期望得到的信息;

(4)接口定义是否可满足所有调用需求;

(5)接口定义调用是否方便。

2.5 一个完整的例子

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

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

2.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.5.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。

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

2.5.3 针对输出分析

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

从结果可以考虑遍历:

1)未完成

2)完成

3)完成 - 未知

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

3 小结

接口用例设计方法中,针对输入、输出的设计是通用的,接口设计时都可用到。对于接口逻辑的设计可能会应用比较适合的一种或几种方法,在接口用例设计时,需要选取最合适的方法去覆盖被测逻辑。

接口测试和传统功能测试区别和联系是怎样?欢迎说说你的想法。

关注微信公众号腾讯移动品质中心 TMQ,获取更多测试干货分享!

共收到 24 条回复 时间 点赞

分析的和全面,但是这样写出的测试用例会不会太多了,效率不高,受益也不高呢,可以看哈你后面写出来的测试文档不呢

这样的成本太高了,对于一些公司不是那么实用

匿名 #4 · 2018年01月23日
donly 回复

你好,下个月 tmq 会举办以此为主题的在线沙龙活动,建议你询问作者本人。

匿名 #5 · 2018年01月23日

建议大家在微信公众号上留言哈,小编会及时联系作者给予回复。

Joo 接口测试用例到底应该怎么写 中提及了此贴 01月23日 15:44

是在哪里举行呢?怎么报名呢?

数值型输入为什么没有考虑特殊字符呢

匿名 #9 · 2018年01月25日

的确很全,但是要完成这么全的用例得多少工时。。。

很有参考价值~ 可根据部分规则自动生成对应 case 来进行自动化测试,从而发挥更大效益

这篇帖子的图呢

匿名 #12 · 2018年03月07日
古古阁 回复

gg 啦

讲得非常好

恒温 将本帖设为了精华贴 03月11日 08:55

大公司的确需要做到这样,小公司经常坑得你功能都不够时间测试,除非你能直接拿一套现成的东西出来。

匿名 #17 · 2018年03月13日
云翼风希 回复

😂

@tmq
2.2.2 操作对象分析 该小节 实际属于安全测试范畴.

水平权限漏洞:凡是用户 A 可以利用来访问用户 B 的敏感资源的漏洞。

是很全面,稍微花点时间建模,有个通用的模型做基准,再根据具体需求扩展,就能省下很多设计用例的时间

mark 一下。感谢分享

老马 专栏文章:接口测试用例覆盖组织设计 中提及了此贴 11月12日 10:03
simple 专栏文章:[精华帖] 社区历年精华帖分类归总 中提及了此贴 12月13日 14:44
simple [精彩盘点] TesterHome 社区 2018 年 度精华帖 中提及了此贴 01月07日 12:08

感谢!
有个问题想请教下:
我理解的这片文章中主要针对单个接口进行测试,那么对于一个包含几个接口的功能,或者一个流程,或者说一个产品,如何设计接口测试用例呢?如何组合?如何设计数据达到自动化执行。

cool,分析的很透彻全面,受益匪浅

Child 回复

你的测试模型是怎样的呢?可以分享一下吗?

分析的很全面。想看看你写的测试用例是啥样子的(很多人都想看啊)

我也想看测试用例是啥样子

多人团队可以这么写、但是、如果测试团队人很少的情况下、投入产出比就不是正比

测试新人 「功能人的 2023」 中提及了此贴 12月22日 16:28
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册