关于游戏测试

一.人员构成

制作人:项目整体负责人

  • 1.负责游戏研发环节
  • 2.负责游戏运营环节
  • 3.负责项目人员管理
  • 4.负责项目事务管理

策划

  • 剧情策划:负责规划游戏中的各种剧情、故事、背景等
  • 系统策划:设计游戏中各种系统的规则
  • 数值策划: 规划游戏中各种资源的产出、消耗等
  • 关卡策划: 设计游戏中各种关卡

    程序:代码实现人员,负责把策划的设计及美术资源等通过编码实现成可玩的程序

  • 客服端程序:实现游戏客户端的展现与逻辑
  • 后端程序:实现服务器端的逻辑、数据验证等

    美术:制作游戏中的各类美术资源

  • 场景
  • 原画
  • UI
  • 动画
  • 特效

    测试:项目的质量保证人员,主要工作是发现游戏中存在的缺陷并及时反馈出来

  • 功能测试
  • 性能测试
  • 压力测试
  • 兼容测试
  • 自动化测试
  • 安全测试

    二.游戏测试主要内容

  • 看这张示意图看到游戏开发的流程

    功能测试
  • 功能测试是游戏测试中最常见二的模式,主要测试方法为黑盒测试
  • 功能测试主要用来验证功能是否符合需求设计
  • 功能测试主要考虑功能正确性,而不考虑游戏底层结构和代码错误
  • 功能测试通常从界面着收开始测试,尽量模拟用户可能出现的操作
    客户端性能测试
  • 客户端CPU使用率
  • 客户端内存占用率
  • 客户端网络流量使用情况
  • 客户端耗电量
  • 客户端帧率(FPS)
  • ios常用工具xcode自带的instrument
  • 安卓常用工具emmage和GT
    服务器压力测试
  • 服务器CPU使用率
  • 服务器内存占用率
  • 系统吞吐量(TPS)
  • 事务响应时间
  • 事务成功率
    兼容测试
  • 机型适配测试
  • 操作系统兼容测试
  • 屏幕分辨率兼容测试
  • 游戏版本兼容测试
    安全测试
  • 内存修改测试
  • 客户端加密测试
  • 客户端反编译测试
  • 网络安全测试
    接口测试
  • 服务器各个接口数据测试,主要通过工具来实现
  • 接口安全测试,重复发送请求,查看接口处理情况
    日志测试
  • 客户端日志
  • 服务器日志
    弱网测试
  • 不同网络情况,游戏的运行情况,如edge、2g、3g、4g情况
  • 不同丢包率情况下游戏的运行情况
  • 通过工具设置网络代理来实现,常用的fiddler,network linj conditioner
    gm 工具测试
  • 测试gm工具的功能开发,需要关注工具的设置是否在游戏中起作用
  • 测试gm工具的数据读取、存储
    sdk测试
  • 用户数据测试
  • 充值、消费测试
  • 与各个渠道对接测试

    三.游戏测试基本流程

    功能会议
  • 了解功能需求内容
  • 提出可能存在的风险点
  • 思考功能的测试重点和难点,如需要工具辅助需提出开发需求
  • 思考可优化的地方,并提出讨论
    测试用例书写
  • 根据需求书写测试用例
  • 关注功能逻辑实现
  • 考虑各种特殊情况,如边界值、网络中断、进程中断等
  • 关注需求变更情况,需求经常发生变革,需要及时调整测试用例
    冒烟测试
  • 详细测试之前的一个环节
  • 快速发现比明显的bug
  • 快速确保主逻辑流程跑通
  • 快速明确功能开展状态
    详细测试
  • 细致的测试每个逻辑分支、资源、配置
  • 尽量模拟玩家的每一种操作可能
  • 测试异常情况,如断网、断电、事件中断、进程中断等情况
  • 测试数据读取、存储、网络等内容
  • 测试该功能对其他功能的影响
    回归测试
  • 测试已经被修复的内容
  • 测试需求调整后的内容
  • 再此详细测试各逻辑分支
    checklist检查
  • 简要快速的检查功能的主要逻辑点
  • 简要检查与该功能有关联的任何其他功能点

    四.游戏测试用例

    需求文档分析

    文档阅读:切忌不阅读需求文档,上来直接写用例,至少读3遍文档
  • 细致理解功能设计意图和设计思路
  • 避免粗略理解带来的用例遗漏
  • 一些重要数据可能隐藏在不起眼的语句中
  • 加深对功能的理解,否则随时间推移,可能会遗忘很多内容
    细节沟通探讨
  • 不明白的地方需要及时确认,切忌脑补想当然
  • 尽早确认细节,最好在开始写之前就确认完毕
  • 关注需求变更,需求变更后,一定要跟程序和策划确认
    逻辑梳理
  • 文档不一定是按照流程顺序写的,而且经常存在功能交叉的地方
  • 梳理出框架后,逐步细化
    功能拓展思考
  • 设计缺陷思考
  • 测试难点思考
  • 关联度思考
  • 特殊情况思考
    兼容相关思考
  • 版本兼容
  • 功能兼容
  • 操作系统版本兼容
  • 分辨类兼容

    功能模块划分

    模块划分原则
  • 高内聚,低耦合
  • 重整体,轻局部
    模块划分注意事项
  • 不同的划分方法适用不同的场景,要具体问题具体分析
  • 有时候一个功能需要结合多种方法进行划分
  • 划分方法不重要,划分原则更重要
  • 划分完毕后,要结合需求文档冲洗梳理,确保模块清晰、覆盖完整

    测试用例编写

    格式
  • 一个清晰的格式为何重要?
    • 让用例的脉络更清晰明了
    • 方便需求变化后的更新维护
    • 方便执行人员快速入手
  • 首页内容
  • 正文页内容
    • 功能逻辑图(如果有)
    • 用例id
    • 模块名称
    • 测试先决条件
    • 输入信息
    • 输出结果
    • 备注信息
  • 关于格式的一些注意点
    • 尽量保证逻辑清晰
    • 尽量保证一个输入只对应一个输出
    • 保证每次更新用例后都有明确的记录标注
    • 尽量保证一个用例内格式统一

      测试用例常用编写方法

  • 等价类:指的一个输入集合内,任何输入数据对于输出的验证来讲都是等效的,此时我们就可以选取少量代表性的测试数据来代码整体数据。
    • 有效等价类:是对输出来讲有意义的输入集合,可以验证程序的正常功能和流程
    • 无效等价类:是对输出无意义的输入组合,用于验证非正常流程输入对输出的影响
  • 边界值
    • 边界值:对输入或输出的边界值进行分析的一种方法
    • 边界值的确定:一般选取正好等于,刚刚小于和刚刚大于3种情况作为测试数据
    • 通常适用的范畴:数值测试,字符测试,数据类型测试等
  • 因果图&判定表
    • 因果图:简单来说就是输入与输出之间因果关系的一种关系图
    • 判定表:可以通过因果图来生成的一种结果判定表格
    • 因果图常常与判断表一起使用,通过因果图生成判定表,通过判定表来书写测试用例

      用例编写注意事项

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

    测试用例整理与维护

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

    五.BUG的界定标准

  • 与需求设计不符
  • 违背常识

    BUG的等级划分

  • P0:致命错误,需要立即修复,如宕机、重启性报错等
  • P1:严重错误,需要紧急修复,如功能流程错误、数值错误等
  • P2:一般错误,允许一段时间内修复,如功能的简单错误、界面错误等
  • P3: 一般错误,允许一段时间内修复,如功能的简单错误、界面错误等
  • P4:无关紧要的错误,允许延期修复,如文字错误,某个像素点缺失等等

    BUG的提报标准

  • 标题:[模块名称]+简短描述
  • 测试环境:标明测试用的版本,系统、服务器、帐号等
  • 描述:bug的详细描述
  • 重现步骤:重新bug的详细流程步骤及复现概率
  • 期望结果:希望bug修复后的结果
  • 备注:log,截图等

    BUG的验证标准

  • 严格按照复现步骤验证
  • 去除测试环境的影响
  • 验证标注:需要注明验证的版本、服务器等
  • 拓展:是否对其他功能有影响,做简单回归
  • 注意点:验证不能只看前端展现,更应关注后端数据

    BUG的跟踪与推动

  • 每个人都有责任跟踪自己的bug的修复状态
  • 及时与开发沟通,了解修复状态并提供修复过程中的支持
  • 久不修复的bug需要与开发和上级确认如何处理
  • bug修复后,需要及时验证

六.弱网测试要解决的问题

  • 网络信号差的情况下,对游戏运行的影响
  • 高丢包率的网络环境,对游戏运行的影响
  • 不同网络信号之间切换时,对游戏运行的影响
  • 断线重连对游戏运行的影响
  • 前后端数据一致的问题

测试方法

  • 不同的系统,使用的工具不一样
  • mac系统可以借组于Network Link Conditioner或Charles
  • windows系统借助于Fiddler这个工具

    七.客户端性能测试指标

    我们关注哪些指标:CUP,内存,FPS
  • 游戏进程所占用的cpu占用率
  • 抛开场景谈cpu性能无意义
  • 安卓设备,90%的场景cpu占用小于60%
  • ios设备,90%的场景cpu占用小于80%

    八.游戏接口测试

  • 什么是接口

    常见接口分类

  • 程序自身内部的模块接口
  • 程序暴露给外部其他程序调用的接口

    游戏接口测试的主要内容


——————

附:原文内容来自于慕课网《游戏测试入门

在网络上看到,之前在开发中测试这个环节感觉没那么严谨。通过这个视频知道怎么自测,也清楚怎么和测试在工作上配合。

文章目录
  1. 1. 一.人员构成
    1. 1.1. 制作人:项目整体负责人
    2. 1.2. 策划
    3. 1.3. 程序:代码实现人员,负责把策划的设计及美术资源等通过编码实现成可玩的程序
    4. 1.4. 美术:制作游戏中的各类美术资源
    5. 1.5. 测试:项目的质量保证人员,主要工作是发现游戏中存在的缺陷并及时反馈出来
  2. 2. 二.游戏测试主要内容
    1. 2.0.1. 功能测试
    2. 2.0.2. 客户端性能测试
    3. 2.0.3. 服务器压力测试
    4. 2.0.4. 兼容测试
    5. 2.0.5. 安全测试
    6. 2.0.6. 接口测试
    7. 2.0.7. 日志测试
    8. 2.0.8. 弱网测试
    9. 2.0.9. gm 工具测试
    10. 2.0.10. sdk测试
  • 3. 三.游戏测试基本流程
    1. 3.0.1. 功能会议
    2. 3.0.2. 测试用例书写
    3. 3.0.3. 冒烟测试
    4. 3.0.4. 详细测试
    5. 3.0.5. 回归测试
    6. 3.0.6. checklist检查
  • 4. 四.游戏测试用例
    1. 4.1. 需求文档分析
      1. 4.1.1. 文档阅读:切忌不阅读需求文档,上来直接写用例,至少读3遍文档
      2. 4.1.2. 细节沟通探讨
      3. 4.1.3. 逻辑梳理
      4. 4.1.4. 功能拓展思考
      5. 4.1.5. 兼容相关思考
    2. 4.2. 功能模块划分
      1. 4.2.1. 模块划分原则
      2. 4.2.2. 模块划分注意事项
    3. 4.3. 测试用例编写
      1. 4.3.1. 格式
    4. 4.4. 测试用例常用编写方法
    5. 4.5. 用例编写注意事项
    6. 4.6. 测试用例整理与维护
  • 5. 五.BUG的界定标准
    1. 5.1. BUG的等级划分
    2. 5.2. BUG的提报标准
    3. 5.3. BUG的验证标准
    4. 5.4. BUG的跟踪与推动
  • 6. 六.弱网测试要解决的问题
    1. 6.1. 测试方法
  • 7. 七.客户端性能测试指标
  • 8. 八.游戏接口测试
    1. 8.1. 常见接口分类
    2. 8.2. 游戏接口测试的主要内容
  • 9. 附:原文内容来自于慕课网《游戏测试入门》
  • |