一.人员构成
制作人:项目整体负责人
- 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%
八.游戏接口测试
- 什么是接口
常见接口分类
- 程序自身内部的模块接口
- 程序暴露给外部其他程序调用的接口
游戏接口测试的主要内容
——————
附:原文内容来自于慕课网《游戏测试入门》
在网络上看到,之前在开发中测试这个环节感觉没那么严谨。通过这个视频知道怎么自测,也清楚怎么和测试在工作上配合。