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

游戏测试用例

测试用例设计步骤

一、需求文档分析

1、文档阅读

  • 切忌不阅读需求文档,上来直接写用例,至少读3遍文档。
  • 细致理解功能设计意图和设计思路 。
  • 避免粗略理解带来的用例遗漏。
  • 一些重要数据可能隐藏在不起眼的语句中 。
  • 加深对功能的理解,否则随着时间推移,可能会遗忘很多内容。

2、功能细节沟通探讨

  • 不明白的地方需要及时确认,切忌脑补想当然 。
  • 尽早确认细节,最好在开始写之前就确认完毕。
  • 关注需求变更,需求变更后,一定要跟程序和策划确认

3、逻辑梳理

  • 文档不一定是按照流程顺序写的,而且经常存在功能交叉的地方。
  • 梳理出框架后,逐步细化。

4、功能拓展思考

  • 设计缺陷思考
  • 测试难点思考(领取奖励后刷新)
  • 关联度思考(领取道具存储位置、道具重复问题)
  • 特殊情况思考(领取道具过程中断网断电情况)

5、兼容相关思考

  • 版本兼容(一种服务器两种版本中的交互)
  • 功能兼容(老功能基础上增加新的内容)
  • 操作系统版本兼容
  • 分辨率兼容

二、功能模块划分

1、功能模块划分原则

  • 高内聚、低耦合
  • 重整体、清局部

2、模块划分方法

  • 功能流程法:将功能的基本流程画出来,根据流程的每个大的环节进行模块划分,然后再细化和查漏补缺。
  • 层次划分法:按照逻辑层次逐层细化出模块的过程,比较适用于UI划分,大的系统模块划分等。
  • 类型划分法:按照功能包含内容的不同类型进行划分。

注:

  • 不同的划分法适用不同的场景,要具体问题具体分析 有时候一个功能需要结合多种方法进行划分。
  • 划分方法不重要,划分原则更重要一些。
  • 划分完毕后,要结合需求文档重新梳理,确保模块清晰、覆盖完整。

三、测试用例编写

1、格式
清晰的格式为何如此重要

  • 让用例的脉络更清晰明了 。
  • 方便需求变化后的更新维护 。
  • 方便执行人员快速入手。

首页内容

  • 用例名称
  • 用例对应的游戏版本
  • 编写人、修改日期、修改备注
  • 需求文档的链接或地址

正文页内容

  • 功能逻辑图(如果有)
  • 用例id
  • 模块功能名称
  • 测试先决条件
  • 输入信息
  • 输出结果
  • 备注信息

注:

  • 尽量保证逻辑清晰。
  • 尽量保证一个输入只对应一个输出。
  • 保证每次更新用例后都有明确的记录标注。
  • 尽量保证一个用例内格式统一。

2、常用的测试用例编写方法
(1)等价类

  • 等价类:指的是一个输入集合内,任何输入数据对于输出的验证来讲都是等效的,此刻我们就可以选取少量代表性的测试数据来代表整体数据。
  • 有效等价类:是对输出来讲有意义的输入集合,可以验证程序的正常功能和流程。
  • 无效等价类:是对输出无意义的输入组合,用于验证非正常流程输入对输出的影响。

(2)边界值

  • 边界值:对输入或输出的边界值进行分析的一种方法。
  • 边界值的确定:一般选取正好等于,刚刚小于和刚刚大于3种情况作为测试数据。
  • 通常适用的范畴:数值测试、字符串测试、数据类型测试等。

(3)因果图&判定表

  • 因果图:简单的来说就是输入与输出之间因果关系的一种关系图。
  • 判定表:可以通过因果图来生成的一种结果判定表。
  • 因果图常常与判定表一起使用,通过因果图生成判定表,通过判定表来书写测试用例

(4)正交实验法&场景法
3、测试用例编写注意事项

  • 输入条件要单一明确,尽量不用容易引起误解的词,比如:可能、大概等。
  • 输出要判断且明确,最好不用“显示正确”这种词汇。
  • 测试步骤要可执行
  • 保持尽量稿的覆盖度。
  • 能抽象的尽量抽象出来,避免无意义的冗余。

四、测试用例整理与维护

  • 需求变化后需要及时更新老的测试用例,并写清修改情况的备注(修改内容,产品和开发负责人。
  • 测试用例应该尽量避免冗余,如果遇到重复的用例,需要根据实际情况进行修改。
  • 注意测试用例的备份,写完后最好自己本地也备份一份,避免线上被人误删。
    游戏测试bug详解

五、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详解

    来源:佳期如顭

    声明:本站部分文章及图片转载于互联网,内容版权归原作者所有,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年3月1日
下一篇 2020年3月1日

相关推荐