游戏测试用例
测试用例设计步骤
一、需求文档分析
1、文档阅读
切忌不阅读需求文档,上来直接写用例,至少读3遍文档。
细致理解功能设计意图和设计思路。
避免粗略理解带来的用例遗漏。
一些重要数据可能隐藏在不起眼的语句中。
加深对功能的理解,否则随着时间推移,可能会遗忘很多内容。
2、功能细节沟通探讨
不明白的地方需要及时确认,切忌脑补想当然。
尽早确认细节,最好在开始写之前就确认完毕。
关注需求变更,需求变更后,一定要跟程序和策划确认。
3、逻辑梳理
文档不一定是按照流程顺序写的,而且经常存在功能交叉的地方。
梳理出框架后,逐步细化。
4、功能拓展思考
· 设计缺陷思考
· 测试难点思考(领取奖励后刷新)
· 关联度思考(领取道具存储位置、道具重复问题)
· 特殊情况思考(领取道具过程中断网断电情况)
5、兼容相关思考
· 版本兼容(一种服务器两种版本中的交互)
· 功能兼容(老功能基础上增加新的内容)
· 操作系统版本兼容
· 分辨率兼容
二、功能模块划分
1、功能模块划分原则
· 高内聚、低耦合
· 重整体、清局部
2、模块划分方法
功能流程法:将功能的基本流程画出来,根据流程的每个大的环节进行模块划分,然后再细化和查漏补缺。
层次划分法:按照逻辑层次逐层细化出模块的过程,比较适用于UI划分,大的系统模块划分等。
类型划分法:按照功能包含内容的不同类型进行划分。
注:
· 不同的划分法适用不同的场景,要具体问题具体分析 有时候一个功能需要结合多种方法进行划分。
· 划分方法不重要,划分原则更重要一些。
· 划分完毕后,要结合需求文档重新梳理,确保模块清晰、覆盖完整。
三、测试用例编写
1、格式
清晰的格式为何如此重要:
让用例的脉络更清晰明了 。
方便需求变化后的更新维护 。
方便执行人员快速入手。
首页内容
· 用例名称
· 用例对应的游戏版本
· 编写人、修改日期、修改备注
· 需求文档的链接或地址
正文页内容
· 功能逻辑图(如果有)
· 用例id
· 模块功能名称
· 测试先决条件
· 输入信息
· 输出结果
· 备注信息
注:
尽量保证逻辑清晰。
尽量保证一个输入只对应一个输出。
保证每次更新用例后都有明确的记录标注。
尽量保证一个用例内格式统一。
2、常用的测试用例编写方法
(1)等价类
等价类:指的是一个输入集合内,任何输入数据对于输出的验证来讲都是等效的,此刻我们就可以选取少量代表性的测试数据来代表整体数据。
有效等价类:是对输出来讲有意义的输入集合,可以验证程序的正常功能和流程。
无效等价类:是对输出无意义的输入组合,用于验证非正常流程输入对输出的影响。
(2)边界值
边界值:对输入或输出的边界值进行分析的一种方法。
边界值的确定:一般选取正好等于,刚刚小于和刚刚大于3种情况作为测试数据。
通常适用的范畴:数值测试、字符串测试、数据类型测试等。
(3)因果图&判定表
因果图:简单的来说就是输入与输出之间因果关系的一种关系图。
判定表:可以通过因果图来生成的一种结果判定表。
因果图常常与判定表一起使用,通过因果图生成判定表,通过判定表来书写测试用例。
3、测试用例编写注意事项
输入条件要单一明确,尽量不用容易引起误解的词,比如:可能、大概等。
输出要判断且明确,最好不用“显示正确”这种词汇。
测试步骤要可执行。
保持尽量稿的覆盖度。
能抽象的尽量抽象出来,避免无意义的冗余。
四、测试用例整理与维护
需求变化后需要及时更新老的测试用例,并写清修改情况的备注(修改内容,产品和开发负责人。
测试用例应该尽量避免冗余,如果遇到重复的用例,需要根据实际情况进行修改。
注意测试用例的备份,写完后最好自己本地也备份一份,避免线上被人误删。
五、BUG的界定标准
1、与需求设计不符
2、违背常识
六、BUG的生命周期
· 发现bug
· 提交给开发
· 开发修复
· 测试验证
· 通过后关闭/不通过继续指派给开发
· 上线前回归
七、BUG的等级划分
P0:致命错误,需要立即修复,如宕机、重启性报错等。
P1:严重错误,需要紧急修复,如功能流程错误、数值错误等。
P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等。
P3:无关紧要的错误,允许延期修复,如文字错误、某个像素点缺失等等。
八、BUG的提报标准
标题:【模块名称】+简短描述。
测试环境:表明测试用的版本,系统,服务器,账号等。
描述:bug的详细描述。
重新步骤:重现bug的详细流程步骤及复现概率。
期望结果:希望bug修复后的结果 。
备注:log,截图等。
九、BUG的提报标注——一个bug例子
标题:[士兵]打开士兵技能升级页面报错。
测试环境:内网测试服,v1.1.0版本,IOS系统,账号:zjf01。
详细描述:当我们在游戏中打开士兵升级页面时,系统提示报错信息。
重现步骤:(1)进入游戏;(2)打开士兵技能升级页面;(3)系统报错。
期望结果:能够正常升级士兵技能,打开升级页面不报错。
备注:报错信息见下面的截图
十、BUG的验证标准
严格按照复现步骤验证。
去除测试环境的影响。
验证标注:需要注明验证的版本、服务器等。
十一、BUG的验证标准
拓展:是否对其它功能有影响,做简单回归。
注意点:验证不能只看前端展现,更应关注后端数据。
十二、BUG的跟踪与推动
每个人都有责任跟踪自己的bug的修复状态。
及时与开发沟通,了解修复状态并提供修复过程中的支持。
久不修复的bug需要与开发和上级确认如何处理。
Bug修复后,需要及时验证。
十三、BUG的数据分析
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理