这篇文章主要介绍了游戏测试相关内容，包括游戏测试的主要内容（如功能、性能、压力、兼容、安全等测试）、基础流程（功能会议到 checklist 检查等环节）、测试用例（设计步骤、编写方法等）、游戏 bug（界定、等级、提报、验证等）、弱网测试、功能性测试、接口测试等方面。
关联问题: 游戏测试点有哪些 测试用例怎样算好 20 个测试点够吗
文章目录
游戏测试的主要内容
游戏测试基本流程
游戏测试用例
游戏bug
游戏弱网测试
游戏功能性测试
游戏接口测试
游戏测试的主要内容
功能测试
主要验证功能是否符合需求设计
主要考虑功能正确性，不考虑游戏底层结构及代码错误
通常从界面着手测试，尽量模拟用户可能出现的操作
性能测试
测试点
客户端CPU使用率 客户端内存占用率 客户端网络流量使用情况 客户端耗电量 客户端帧率（FPS）测试方法
分析代码
工具监测
iOS：xcode自带的instrument 安卓：emmage和GT（需要root权限）压力测试
服务器CPU使用率 服务器内存占用率 系统吞吐量（TPS） 事务响应时间 事务成功率兼容测试
机型适配测试 操作系统兼容测试 屏幕分辨率兼容测试 游戏版本兼容测试安全测试
内存修改测试 客户端加密测试 客户端反编译测试 网络安全测试（用抓包工具测试 避免重复抓包）接口测试
服务器各个接口数据测试，主要用工具来实现 接口安全测试，重复发送请求，查看接口处理情况日志测试
客服端日志 服务端日志 弱网测试测试点
不同网络情况下游戏的运行情况
不同丢包率情况下游戏的运行情况
通过工具设置网络代理来实现
常用的工具 win:fiddle、mac:network link conditionergm工具测试（运营、客服人员使用）
测试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环境）
自己写脚本语言
