游戏测试用例及游戏测试bug详解

发表于:2021-6-29 09:33

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:佳期如顭    来源:CSDN

分享:
  游戏测试用例
  测试用例设计步骤
  一、需求文档分析
  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),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号