[腾讯 TMQ] 接口测试用例设计
接口测试 [腾讯 TMQ] 接口测试用例设计
腾讯移动品质中心 · 2018年01月17日 · 最后由 于静 回复于 20 天前 · 21794 次阅读
本帖已被设为精华帖!
目录
作者:刘燕
团队:腾讯移动品质中心(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)完成-未知
从接口处理时间分析,考虑:请求后快速返回,很长时间才返回,甚至不返回结果的情况。
[腾讯 TMQ] 接口测试用例设计的更多相关文章
- (转)【腾讯 TMQ】 接口测试用例设计
导语 这是我在其他的开源社区看到的一篇分享帖子.这篇文章的目的只是为大家提供一个思路,但是实现成本太高了,因为一个接口设计的接口测试用例很多,一般公司的接口数量几百到上千不等,每一个接口都设计这么多测 ...
- 8-5接口测试用例设计与编写2 rest-assured
rest-assured 简约的接口测试DSL 支持xml json的结构化解析 支持xpath jsonpath gpath等多种解析方式 对Spring的支持比较前面 底层是httpclient ...
- python接口自动化(三)--如何设计接口测试用例(详解)
简介 上篇我们已经介绍了什么是接口测试和接口测试的意义.在开始接口测试之前,我们来想一下,如何进行接口测试的准备工作.或者说,接口测试的流程是什么?有些人就很好奇,接口测试要流程干嘛?不就是拿着接口文 ...
- python接口自动化(五)--接口测试用例和接口测试报告模板(详解)
简介 当今社会在测试领域,接口测试已经越来越多的被提及,被重视,而且现在好多招聘信息要对接口测试提出要求.区别于传统意义上的系统级别测试,很多测试人员在接触到接口测试的时候,也许对测试执行还可以比较顺 ...
- 基于Groovy+HttpRestful的超轻量级的接口测试用例配置的设计方案及DEMO实现
目标 设计一个轻量级测试用例框架,接口测试编写者只需要编写测试用例相关的内容(入参及结果校验),不需要理会系统的实现,不需要写跟测试校验无关的内容. 思路 测试用例分析 一个用例由以下部分组成: (1 ...
- XMind2TestCase:一个高效测试用例设计的解决方案!
一.背景 软件测试过程中,最重要.最核心就是测试用例的设计,也是测试童鞋.测试团队日常投入最多时间的工作内容之一. 然而,传统的测试用例设计过程有很多痛点: 1.使用Excel表格进行测试用例设计,虽 ...
- 请以excel管理你的接口测试用例
闲话休扯,上需求:自动读取.执行excel里面的接口测试用例,测试完成后,返回错误结果并发送邮件通知. 分析: 1.设计excel表格2.读取excel表格3.拼接url,发送请求4.汇总错误结果.发 ...
- App版本更新接口的设计
前段时间公司业务调整,新开了新的移动端的项目,所以和朋友聊到了“版本号”和“版本更新所需的数据表设计”. 一般来讲大部分的软件版本号分3段,比如 A.B.C A 表示大版本号,一般当软件整体重写,或出 ...
- TestNG使用教程详解(接口测试用例编写与断言)
版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明. 本文链接:https://blog.csdn.net/sinat_34766121/artic ...
随机推荐
- Windows Server 2008 R2 ntoskrnl.exe 引起蓝屏故障,重新启动
前不久在HP ProLiant DL360 G6的服务器上面安装了Windows Server 2008 R2,系统一到晚上凌晨就出现蓝屏.重启现象,并且在 C:\Windows\Minidump 目 ...
- netty权威指南学习笔记三——TCP粘包/拆包之粘包现象
TCP是个流协议,流没有一定界限.TCP底层不了解业务,他会根据TCP缓冲区的实际情况进行包划分,在业务上,一个业务完整的包,可能会被TCP底层拆分为多个包进行发送,也可能多个小包组合成一个大的数据包 ...
- C++面试常见问题——07容器和迭代器
容器和迭代器 vector.list.deque #include<iostream> #include<vector> #include<deque> #incl ...
- windows查看所有进程:netstat -ano
windows查看所有进程:netstat -ano ------------------------------------------------------------------------- ...
- python 鞍点
# 鞍点: 所在行的最大值,所在列的最小值 import random A = [[random.randint(1,100) for j in range(5)]for i in range(5)] ...
- 安装python包的两种方法
1.在 anaconda 环境中安装包 selenium conda install selenium 2.python 下安装包 selenium pip install selenium 3.测试 ...
- java枚举类(转)
转自: http://blog.sina.com.cn/s/blog_697b968901013ih1.html 这里主要讲解的是Java的枚举类型 什么是枚举? 以我的理解答:枚举是我们自己定义的一 ...
- 实验吧-隐写术-黑与白(二)(反转+五笔+Image steganography)
反转有二:颜色反转.文件名反转 文件名这么乱,毫无规律,好奇怪,进行反转后发现是:steganography(就是隐写术的意思),这还是个图片文件,有一款工具正好叫Image steganograph ...
- sublime text 常用插件安装
一.安装方法 ctrl+ship+p —— 在弹出的地方输入 pci (package control: install pagckage)—— 再输入 要安装的包名 二.一步过慢或失败解决: 原因: ...
- 吴裕雄--天生自然C++语言学习笔记:C++ 重载运算符和重载函数
C++ 允许在同一作用域中的某个函数和运算符指定多个定义,分别称为函数重载和运算符重载. 重载声明是指一个与之前已经在该作用域内声明过的函数或方法具有相同名称的声明,但是它们的参数列表和定义(实现)不 ...