游戏测试用例

游戏测试用例

        • 1. 设计步骤
          • 1. 需求文档分析
            • 1.1 文档阅读
            • 1.2 功能细节沟通探讨
            • 1.3 逻辑梳理
            • 1.4 功能拓展思考
            • 1.5 兼容相关思考
          • 2. 功能模块划分
            • 2.1 功能模块划分时应遵循什么样的规则li>
            • 2.2 功能模块划分有哪些比较好的方法
            • 2.3 模块划分注意事项
          • 3. 测试用例编写
            • 3.1 格式
            • 3.2 常用的测试用例编写方法
            • 3.3 测试用例编写注意事项
          • 4. 测试用例整理与维护
        • 2. 游戏测试bug详解
          • 2.1 BUG详解:
          • 2.2 BUG的鉴定标准:
          • 2.3 BUG的生命周期:
          • 2.4 BUG的等价划分:
          • 2.5 BUG的提 标准
          • 2.6 BUG的验证标准:
          • 2.7 BUG的跟踪与推动:
          • 2.8 BUG的数据分析:
        • 3. 弱 测试
          • 3.1 弱 测试要解决的问题
          • 3.2 测试方法
        • 4. 客户端性能测试–安卓
          • 4.1 客户端性能测试指标
        • 5. 客户端性能测试–ios
        • 6. 游戏接口测试
          • 6.1 常见的接口分类
          • 6.2 游戏接口测试的主要内容
          • 6.3游戏接口测试常用工具

1. 设计步骤

1. 需求文档分析
1.1 文档阅读
  • 切忌不阅读需求文档,上来直接写用例,至少读三遍文档
    1 细致理解功能设计意图和设计思路
    2 避免粗略理解带来的用例遗漏
    3 一些重要数据可能隐藏在不起眼的语句中
    4 加深对功能的理解,否则随着时间推移,可能会遗忘很多内容
  • 带着思考去阅读,如果让你设计这个功能,还有更优的选择吗li>
1.2 功能细节沟通探讨
  • 不明白的地方需要及时确认,切忌脑补想当然
  • 尽早确认细节,最好在开始写之前就确认完毕
  • 关注需求变更,需求变更后,一定要跟程序和策划确认
1.3 逻辑梳理
  • 文档不一定是按照流程顺序写的,而且经常存在功能交叉的地方
  • 我们需要先梳理出框架后,逐步细化
1.4 功能拓展思考
  • 设计缺陷思考:升级;拆解;道具;领取道具的数量,次数
  • 测试难点思考:领取次数,刷新(测试,不能直接等)
  • 关联度思考:道具存储问题
  • 特殊情况思考:断电,断 ,服务器维护
1.5 兼容相关思考
  • 版本兼容:同时存在两个版本时,不同的版本
  • 功能兼容:老功能中添加新英雄
  • 操作系统版本兼容:mac,windows
  • 分辨率兼容:美术展示等
2. 功能模块划分
2.1 功能模块划分时应遵循什么样的规则h6>
  • 高内聚,低耦合:购买月卡和购买单个分开
  • 重整体,轻局部:从整体关注
2.2 功能模块划分有哪些比较好的方法
  • 功能流程法:将功能的基本流程画出来,根据流程的每个大的环节进行模块划分,然后再细化和查缺补漏。
    举例:请就银行ATM的取款功能进行模块划分
    插卡环节–>密码登录环节–>输入金额环节–>取走钱币环节–>取卡环节
  • 层次划分法:按照逻辑层次逐层细化出模块的过程,比较适用于UI划分,大的系统模块划分等。
    举例:请就dota这款游戏进行模块划分
    dota–>战斗内的内容–>英雄–>动画;技能
    dota–>战斗内的内容–>道具
    dota–>战斗内的内容–>地图
    dota –>战斗外的内容–>账 登录;按键设置
  • 类型划分法:按照功能包含的内容的不同类型进行划分。
    举例:兵种测试,道具测试等。
    兵种测试:可训练兵种和不可训练兵种
    道具测试:可消耗道具和不可消耗道具
    类型划分法比较适用于一个功能种类相对独立,种类之间关联度较低的情况。
2.3 模块划分注意事项
  • 不同的划分方法适用不同的场景,要具体问题具体分析
  • 有时候一个功能选哟结合多种方法进行划分
  • 划分方法不重要,划分原则更重要一些
  • 划分完毕后,要结合需求文档重新梳理,确保模块清晰、覆盖完整。
3. 测试用例编写
3.1 格式
  • 一个清晰的格式很重要
    1 让用例的脉络更清晰明了
    2 方便需求变化后的更新维护
    3 方便执行人员快速入手

  • 首页内容
    1 用例名称
    2 用例对应的游戏版本
    3 编写人、编写日期、备注
    4 修改人、修改日期、修改备注
    5 需求文档的链接或地址

  • 关于格式的一些注意点
    1 尽量保证逻辑清晰
    2 尽量保证一个输入只对应一个输出
    3 保证每次更新用例后都有明确的记录标注
    4 尽量保证一个用例内格式统一

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

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

3.3 测试用例编写注意事项
  • 输入条件要单一明确,尽量不用容易引起误解的词,比如可能,大概等。
  • 输出要可判断且明确。最好不用“显示正确”这种词汇
  • 测试步骤要可执行
  • 保持尽量高的覆盖度
  • 能抽象的尽量抽象出来,避免无意义的冗余。
4. 测试用例整理与维护
  • 需求变化后需要及时更新老的测试用例,并写清修改情况的备注(修改内容,产品和开发负责人)
  • 测试用例应该尽量避免冗余,如果遇到重复的用例,需要根据实际情况进行修改
  • 注意测试用例的备份,写完后最好自己本地也备份一份,避免线上被人误删

2. 游戏测试bug详解

2.1 BUG详解:
  • 发现bug仅仅是测试工作的开始
2.2 BUG的鉴定标准:
  • 与需求设计不符
  • 违背常识
2.3 BUG的生命周期:

发现bug –> 提交给开发 –> 开发修复 –> 测试验证 –> 通过后关闭–> 上线前回归
测试验证如果不通过 –> 不通过继续指派给开发

2.4 BUG的等价划分:
  • P0:致命错误,需要立即修复,如宕机,重起性 错等
  • P1:严重错误,需要紧急修复,如功能流程错误、数值错误等
  • P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等
  • P3:无关紧要的错误,允许延期修复,如错别字、某个像素点缺失等等
2.5 BUG的提 标准
  • 标题:【模块名称】+ 简短描述
  • 测试环境:标明测试用的版本,系统,服务器,账 等。
  • 描述:bug的详细描述,卡住可继续前进,卡住不能走
  • 重现步骤:重现bug修复后的结果
  • FPS(举例)

    游戏测试用例
    使用emmagee或GT模拟工具,顶部会出现一些使用信息

    5. 客户端性能测试–ios

    xcode –> open developer tool –>instruments –>
    测cpu和内存: instruments –> Activity Monitor
    连接手机,选好app后点recode
    测FPS:instruments –> core animation
    连接手机,选好app后点recode

    6. 游戏接口测试

    接口:代码暴露出来的属性和方法

    6.1 常见的接口分类
    • 程序自身内部的模块接口
    • 程序暴露给外部其他程序调用的接口
    6.2 游戏接口测试的主要内容
    • 客户端与服务器之间的 络接口测试
    6.3游戏接口测试常用工具

    使用Jmeter或者脚本语言自己写

    声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年4月22日
下一篇 2021年4月22日

相关推荐