文章目录
游戏测试的主要内容
功能测试
-
主要验证功能是否符合需求设计
-
主要考虑功能正确性，不考虑游戏底层结构及代码错误
-
通常从界面着手测试，尽量模拟用户可能出现的操作
性能测试
-
测试点
- 客户端CPU使用率
- 客户端内存占用率
- 客户端网络流量使用情况
- 客户端耗电量
- 客户端帧率（FPS）
-
测试方法
-
分析代码
-
工具监测
- iOS：xcode自带的instrument
- 安卓：emmage和GT（需要root权限）
-
-
压力测试
- 服务器CPU使用率
- 服务器内存占用率
- 系统吞吐量（TPS）
- 事务响应时间
- 事务成功率
-
兼容测试
- 机型适配测试
- 操作系统兼容测试
- 屏幕分辨率兼容测试
- 游戏版本兼容测试
-
安全测试
- 内存修改测试
- 客户端加密测试
- 客户端反编译测试
- 网络安全测试（用抓包工具测试 避免重复抓包）
-
接口测试
- 服务器各个接口数据测试，主要用工具来实现
- 接口安全测试，重复发送请求，查看接口处理情况
-
日志测试
- 客服端日志
- 服务端日志
- 弱网测试
-
测试点
-
不同网络情况下游戏的运行情况
-
不同丢包率情况下游戏的运行情况
-
通过工具设置网络代理来实现
- 常用的工具 win:fiddle、mac:network link conditioner
-
-
gm工具测试（运营、客服人员使用）
- 测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用
- 测试gm工具的数据读取、存储
-
SDK测试
- 用户数据测试
- 充值、消费测试
- 与各个渠道对接测试
游戏测试基础流程
流程
- 功能会议->测试用例书写->冒烟测试->详细测试->回归测试->checklist检查
-
冒烟测试
- 详细测试之前的环节
- 快速发现比较明显的bug
- 快速确保主逻辑流程跑通
- 快速明确功能开展状态
-
详细测试
- 细致的测试每个逻辑分支、资源、配置
- 尽量模拟玩家的每一种操作可能
- 测试异常情况，如断网、断电、事件中断、进程中断等
- 测试数据读取、存储、网络等内容
- 新功能对原功能的影响
-
checklist检查（用于上线,，可通过代码提交记录进行简单测试，确定最终包含有所有功能及bug修复点）
- 简要快速的检查功能的主要逻辑点
- 简要检查与该功能有关联的任何其他功能点
游戏测试用例
-
设计步骤
- 需求文档分析->功能模块划分->测试用例编写->测试用例整理与维护 需求文档分析
- 文档阅读（至少读三遍，注意细节）
- 功能细节沟通探讨
- 尽早确认细节
- 不明白的地方不能脑补想当然
- 关注需求变更，跟程序和策划确认
-
逻辑梳理
- 梳理出框架后，逐步细化
功能拓展思考
- 设计缺陷思考
- 测试难点思考
- 关联度思考
- 特殊情况思考
兼容相关思考
- 版本兼容
- 功能兼容（新增的功能和以往）
- 操作系统版本兼容
- 分辨率兼容
功能模块划分
-
模块划分原则
- 高内聚、低耦合
- 重整体、轻局部
-
模块划分方法
-
功能流程法
-
将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，再细化和查漏补缺（不要纠结细节）
-
-
层次划分法
- 按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等。
类型划分法
- 按照功能包含内容的不用类型进行划分
- 适合功能种类比较独立，种类之间的耦合度比较低的情况
测试用例编写
-
格式
-
一个清晰的格式为什么很重要
- 让用例的脉络更清晰明了
- 方便需求变化后的更新维护
- 方便执行人员快速入手
-
首页内容（用例的纲要）
-
用例名称
-
用例对应的游戏版本
-
编写人、编写日期、备注
-
修改人、修改日期、修改备注
-
需求文档的链接或地址
-
-
正文页内容
- 功能逻辑图（可有可无）
- 用例id
- 模块名称
- 测试先决条件
- 输入信息
- 输出结果
- 备注信息
关于格式的一些注意点
- 尽量保证逻辑清晰
- 尽量保证一个输入只对应一个输出
- 保证每次更新用例后都有明确的记录标注
- 尽量保证一个用例内格式统一
测试用例常用编写方法
-
等价类
-
边界值
-
因果图&判定表
-
注意点
- 输入条件一定要单一明确，不用引起误会的词
- 输出要可判断且明确，不用“显示正确”这种词
- 测试步骤要可执行
- 保持尽量高的覆盖度
- 能抽象的尽量抽象出来，避免无意义的冗余，用比较有代表性的数据
测试用例的整理和维护
- 需求变化后需要即使更新老的测试用例，并写清修改情况的备注（修改内容，产品和开发负责人）
- 测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改
- 注意测试用例的备份，写完后最好自己本地备份，避免线上被人误删除
游戏bug
发现bug仅仅是测试工作的开始
-
bug的界定标准
- 与需求设计不符
- 违背常识
-
bug的生命周期
-
发现bug->提交给开发->开发修复->测试验证->通过后关闭->（上线前回归）
-
发现bug->提交给开发->开发修复->测试验证->不通过->重复流程->通过后关闭
bug的等级划分
-
-
p0：致命错误
- 需要立即修复，如宕机、重启性报错等
-
p1：严重错误
* 需要紧急修复，如功能流程错误、数值错误等
-
p2：一般错误
- 允许一段时间内修复，如功能的简单错误、界面错误等
-
p3：无关紧要的错误
- 允许延期修复，如文字错误、某个像素点缺失等
bug的提报标准
- 标题：[模块名称]+简短描述
- 测试环境：表名测试用的版本，系统，服务器，账号等
- 描述：bug的详细描述
- 重现步骤：重现bug的详细流程步骤及复现频率
- 期望结果：希望bug修复后的结果
- 备注：log，截图等
bug的验证标准
- 严格按照复现步骤验证
- 去除测试环境的影响
- 验证标注：需要注明验证的版本、服务器等
- 拓展：是否对其他功能有影响，做简单回归，因为系统间的逻辑耦合性很高
- 注意点：验证不能只看前端表现，更应该关注后端数据
bug的跟踪与推动
- 每个人都有责任跟踪自己的bug修复状态
- 及时与开发沟通，了解修复状态并提供修复过程中的支持
- 久不修复的bug需要与开发和上级确认如何处理
- bug修复后，需要即使验证
bug的数据分析
- 项目各个bug等级数量的矩形图
- 项目各个开发者bug数量的饼图
- 项目各个功能模块bug数量的矩形图
游戏弱网测试
要解决的问题
- 网络信号差的情况下，对游戏运行的影响
- 高丢包率的情况下，对游戏运行的影响
- 不同网络信号之间切换时，对游戏运行的影响
- 断线重连对游戏运行的影响
前后端数据一致的问题
-
测试方法
- mac：network link conditioner或charles
- win：fiddle
游戏功能性测试
客户端性能测试指标
-
CPU
- 指游戏进程所占用的cpu占用率
- 抛开场景看cpu的性能没有意义
- 安卓设备，90%的场景CPU占用率小于60%
- ios设备，90%的场景cpu占用率小于80%
-
内存
- FPS
游戏接口测试
常见接口分类
- 程序自身内部的模块接口
- 程序暴露给外部其他程序调用的接口
游戏接口测试内容
-
客户端与服务端之间的网络接口测试
- 修改传输参数
- 大量发送数据 游戏接口测试工具
-
jmeter（基于Java，需要安装Java环境）
-
自己写脚本语言
