软件测试用例优秀例子_功能测试用例设计方法分享

测试用例可以用来衡量一个项目测试质量,因此在平时的测试流程中,编写测试用例就是测试过程中很重要的一步,每一个测试工程师都需要并且非常熟练的编写测试用例,能在编写测试用例中尽可能的覆盖任何异常的测试点;如何能编写优秀的测试用例,就需要测试人员掌握更多的用例编写技巧以及思考出更多的测试点。针对于游戏测试,大多更偏向于功能方面的测试,根据功能测试用例逐项测试,检查产品是否达到了策划的需求。功能测试主要采用黑盒测试策略设计测试用例,进行测试。主要功能模块测试的测试用例设计方法包括:等价类划分、边界值分析、错误推测法、因果图和判定表、场景法、正交实验法。下面就以上几种方法进行一些分享。

等价类划分法

等价类划分,指的是一种典型的、重要的黑盒测试方法。其就是解决如何选择适当的数据子集来代表整个数据集的问题,通过降低测试的数目去实现“合理的”覆盖,以此发现更多的软件缺陷,统计好数据后由此对软件进行改进升级。

举例一: 设有一个认证条件,要求玩家输入以年月表示的日期。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能"。 首先,划分等价类并编号,下表等价类划分的结果。

600eeb171e031884765357166f953b49.png

设计测试用例,以便覆盖所有的有效等价类,在表中列出了3个有效等价类,编号分别为(1)、(5)、(8),设计的测试用例如下:

265b7b783f4ec91bf264480955086de5.png

为每一个无效等价类设计一个测试用例,设计结果如下:

20ea7da7cc13ee84d8ff138a6e29e972.png

举例二: 登录账号的时候,邮箱地址输入框输入数据,程序检测,判断用户输入的邮箱地址是否合法。现用等价类划分法和边界值分析法设计测试用例:

1)对输入的要求

1、用户名只能用小写字母和数字还有‘.’组成

2、邮箱用户名首位必须是小写字母或者数字

3、用户名长度在6-30个字符之间

4、必须要有 @ 符号和必须要有 ‘.’

5、@后面要以*.*结束(*为任意字符串)

2)等价类表:

9fa6c75b1ee19b7cc3ce7ea9ac70c1fc.png

3)覆盖等价类的测试用例:

70aeb9fa78f06a5b79017085517f49e6.png

边界值分析法

其实边界值可以算是为了配合等价类而加的一个限制条件,一般会根据略小于最小值、略大于最大值、等于最小值/最大值进行边界值的一些验证;一般来说,关于区间型数据边界值的测试,大多都是略小于最小值和略大于最大值是不满足要求的,中间的数据是满足需求的。 边界值附近的数据确定的几种方法:

cd196ed95abdaf66b41cdab0fbd78ce9.png

举例一: 还是以上面要求玩家输入以年月表示的日期来作为例子。假设日期限定在1990年1月~2049年12月,并规定日期由6位数字字符组成,前4位表示年,后2位表示月。现用等价类划分法设计测试用例,来测试程序的"日期检查功能",下面是关于边界值需要检测的点。

9d35c09457bb1eaf4caa8c4b0a4c06b0.png

举例二: 购买一个宝箱,一次性最多只能购买5个,以边界值的标准可选取5个(正好等于)、6个(刚刚大于)、4个(刚刚小于),3个(正常值)作为边界值来测试。

41e435b0a53896ffea6ef3b55e47a885.png

错误推测法

没有确定的步骤,很大程度上是凭经验, 结合以往测试经验和直觉设计软件在功能和流程上可能存在的各种错误,进行容错性测试。例如输入数据为零或输出数据为零时容易发生错误的情况,所以可选择输入值为零的例子,以及使输出值为零的例子;又如输入表格为“空”或输入表格只有一行是较易出错误的情况,所以可选择表示这些情况的例子。根据字面意思,也就是列出可能出现问题的点,猜测哪些情况可能会有问题。 举例一: 如面购买宝箱的例子,针对于需求,仅是对于给出的数据进行了测试,但是在实际情况中,实际要求中需要注意的点。根据平时测试,出现过问题的地方,所以又应该考虑到以下的测试点:

(1)尝试购买-1个宝箱

(2)尝试购买0个宝箱

(3)多次购买小于5个宝箱

(4)多次购买5个宝箱

(5)购买宝箱后重启客户端/服务器

(6).......

举例二:对于游戏中,需要做屏蔽词功能,需要考虑到以下玩家会进行操作的功能点进行测试(多多自走棋为例),我们需要考虑到所有可能出现玩家输入信息的地方,根据对平时对项目的熟悉以及自己的经验,想到一些可能会出现问题的地方:

(1)创建账号(玩家填写角色名称)

(2)聊天功能(世界聊天、好友私聊、队伍聊天、发送邀约信息、制图工坊、房间队伍聊天、局内战斗聊天、局内私聊、局内观众、局内裁判、观战发送聊天信息)

(3)个人信息(玩家修改昵称)

(4)自建房间(玩家创建/修改房间昵称)

场景法

百度百科对场景法的解释是:通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果的一种方法。用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。我们通常以正常的用例场景分析开始,然后再着手其他的场景分析。场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确定的过程,经过遍历所有的基本流和备用流来完成整个场景。场景主要包括4种主要的类型:正常的用例场景,备选的用例场景,异常的用例场景,假定推测的场景。 在一个游戏功能中,将大功能拆分为一个个小功能,而这些小功能就可以视为一个个小场景,这些小场景的集合就成了这个完整的功能模块。

举例,比如多多自走棋的通行证每周挑战功能:

f1ff7adc1614f9e64a6d812b9eec57b7.png

根据这个界面,我们可以分为以下几个部分:

(1)每日奖励

(2)经验等级

(3)具体任务信息

(4)购买等级

(5)奖励展示

(6)视频播放

(7)帮助按钮

(8)购买等级

以上这些小功能以玩家可能会涉及到的操作为出发点,我们可以理解为一个个小场景,将他们组合起来就构成了这个完整的功能,这些小功能构成了整个每周挑战这个功能。以上的这些小功能应该更多以玩家的角度进行考虑。

因果图法和判定表

等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系、相互组合等。考虑输入条件之间的相互组合,可能会产生一 些新的情况。但要检查输入条件的组合不是一件容易的事情,即使把所有输入条件划分成等价类,他们之间的组合情况也相当多,因此需要考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例,这就需要利用因果图。 下面先了解一下因果图得一些规则,下面以图的形式详细说明6种因果逻辑。 c表示原因,e表示结果:

(1)恒等:如果原因为真,那么结果必定为真。

f794b9dda05c49c31a5a9eb11db1af82.png

(2)非:只有原因为假,结果才为真。

4ed85eda3620867e0a7e831c1c3fbdc4.png

(3)与:只有2个原因都为真,那么结果为真。

d4c029dba5076a162ed53842fee5f7ee.png

(4)或:2个原因中有一个为真时,结果就为真。

6a7758e330d6bb8d93bbcca2bebfd943.png

(5)与非:先与后非。

9dfd6d485197da46e3a7f1023316ec82.png

(6)或非:先或后非。

db7c62f88d2dea4611c57cc0228e951a.png

(7)排他性约束:各个原因之间不能同时为真, 但可以同时为假。

5d7e9b9dade6355a623ead1dde21fd55.png

(8)包含性约束:各个原因中总有一个为真。即可以同时为真,但不可以同时为假。

178bf3bbbc486135ece286c5414f8a59.png

(9)必要性约束:当原因a为真时,原因b必须同时为真

cc1250968f0a2964753efe3b4b7a3c41.png

(10)唯一性约束:有且只有原因a和原因b中的一个为真但是原因b为真时,原因a既可以为真,也可以为假。

421d38602ec67205c40aea1062c805d7.png

(11) 掩码标记(结果约束):如果结果b为真,那么结果a一定为假,如果结果b为假,则结果a的状态不定

dde34f4082b914ebc548b585a47adad3.png

举例一: 以多多自走棋为例,玩家查看图鉴中的棋子:第一步必须是A(点击仓库)或B(点击大厅右上角图鉴按钮),第二步必须是C(点击棋子图鉴),在此情况下玩家进入到棋子图鉴界面,但如果第一步不正确,得出结论L;如果第二步骤不是C,则得出结论M。 首先我们整理一下,得出以下信息以及因果图:

1)根据题意,原因和结果如下:

原因:

1——第一步是A;

2——第一步是B;

3——第二步是点击棋子图鉴。

结果:

21——进入棋子图鉴;

22——得出结论L;

23——得出结论M。

2)其对应的因果图如下:

11为中间节点;考虑到原因1和原因2不可能同时为1,因此在因果图上施加E约束。

d6672363fd2d7114a7264dc33ac4eb00.png

3)根据因果图建立判定表: 因为 一般可以根据因果图画出判定表,判定表里只有0,1(1代表真,0代表假)两个数字。若输入条件有n个,则用例考虑的情况有2n种,即8种:

e4d3886eca112739bd2437eece697bc6.png

表中8种情况的左面两列情况中,原因①和原因②同时为1,这是不可能出现的,故应排除这两种情况。表的最下一栏给出了6种情况的测试用例,这是我们所 需要的数据。所以用例有:

(1)1,3------21

(2)1-----23

(3)2,3----21

(4)2-----23

(5)3---22

(6)不进行任何操作-----22,23

正交试验法

利用正交实验设计方法设计测试用例,比使用等价类划分、边界值分析、因果图等方法有以下优点:节省测试工作工时;可控制生成的测试用例数量;测试用例具有一定的覆盖率。

举例:

f8aa9174275a29055be55cf09c3b80ec.png

这是游戏账号注册的一个窗口。我们可以看到要测试的控件有3个:邮箱地址、密码、验证码,也就是要考虑的因素有三个;而每个因素里的状态有两个:填与不填。 选择正交表时分析一下:

1、表中的因素数>=3;

2、表中至少有3个因素数的水平数>=2;

3、行数取最少的一个。

从正交表公式中开始查找,结果为:

L4(23)(0-填 1-不填):

6439f6b8a122fd4f4a0d1412c4dfc23b.png

变量映射如下

3ad7a3b9d52f66a0f43c6db399b08310.png

测试用例如下:

1:填写邮箱地址、填写密码、填写验证码

2:填写邮箱地址、不填密码、不填验证码

3:不填邮箱地址、填写密码、不填验证码

4:不填邮箱地址、不填密码、填写验证码 增补测试用例

5:不填邮箱地址、不填密码、不填验证码

从测试用例可以看出:

(1)如果按每个因素两个水平数来考虑的话,需要8个测试用例,而通过正交实验法进行的测试用例只有5个,大大减少了测试用例数。用最小的测试用例集合去获取最大的测试覆盖率。

(2)因素数不相同 如果因素数不同的话,可以采用包含的方法,在正交表公式中找到包含该情况的公式,如果有N个符合条件的公式,那么选取行数最少的公式。

(3)水平数不相同 采用包含和组合的方法选取合适的正交表公式。


PS:

我们是行者AI,我们在“AI+游戏”中不断前行。

如果你也对游戏感兴趣,对AI充满好奇,那就快来加入我们(hr@xingzhe.ai)

  • 2
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
测试阶段 3 测试用例的分类 3 文本框需求 4 字段为特殊代码校验: 4 文本框为数值型 4 文本框为日期型 5 文本框为时间型 6 密码框 返回目录 6 单选按钮 7 组合列表框/下拉列表 7 数码框(up-down)控件 8 搜索框填充域测试 8 复选框 9 滚动条 9 通过测试: 返回目录 9 失败测试: 10 登陆 10 添加 10 删除 10 查询 返回目录 11 翻页控件 12 树控件的测试外观操作返回目录 12 命令按钮 返回目录 13 一、各种控件在窗体中混和使用时的测试 13 选项卡 返回目录 14 默认焦点 14 TAB顺序 14 快捷键/热键 14 上传文件的测试 14 下载文件的测试 15 【安全性测试】 16 功能测试 v返回目录 16 兼容性测试 17 【性能测试】 17 邮箱输入框字段校验测试 18 验证码输入框字段校验测试 18 替换测试大体相同. 返回目录 19 插入文件 19 链接文件 19 插入对象 19 编辑操作 19 界面测试【UI】 20 窗体 20 标题栏 21 文字 21 控件 21 图片 22 窗口在任务栏上的系统菜单 22 提示对话框测试要点: 23 菜单 23 特殊属性 24 其他 24 新增功能 24 修改功能 24 删除功能 25 查询功能 25 权限检查 26 提示功能检查 26 并发功能 27 导出功能 28 导入功能 28 多币别测试 29 打印功能 29 日志检查 29 导航相关检查 30 返回功能检查 30 重置检查 30 PDF测试 30 发送邮件 31 扫描枪 31 安装测试 31 卸载测试 32 更新 33 键盘操作 33 快捷键支持 34 测试驱动程序设计 34 【易用性测试】 35 导航 功能导航 主要功能的导航是否在明显位置 35 菜单 采用“常用--主要--次要--工具--帮助”的位置排列 35 工具栏 相同或相近功能的工具栏放在一起 36 索引 索引的排列顺序要主次有分 36 按钮 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置 36 快捷键 常用功能要支持快捷键 36 帮助和支持 获取帮助 操作时要提供及时调用系统帮助的功能 36 通用类 系统业务流程需要易于用户理解 37 错误处理 错误规避 37 错误提示 37 一致性 37 与Windows等标准一致 37 内部操作一致 38 反馈信息 38 工作提示 38 功能提示 38 功能性 38 完备性 38 便捷功能 39 控制 可控性 39 视觉清晰 39 布局 39 资源 39 字体 39 颜色 40 语言 文字表达 40 专项测试角度:push测试(推送测试)、交互模式: 40
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值