关于游戏测试

一.人员构成

制作人：项目整体负责人

• 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%

八.游戏接口测试

• 什么是接口

常见接口分类

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

游戏接口测试的主要内容

——————

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

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