（1）功能测试：主要测试方法为黑盒测试。主要用来检验功能是否符合需求设计。主要用来考虑功能正确性，而不考虑游戏底层结构及代码错误。通常从界面着手测试，尽量模拟用户可能出现的操作。
（2）客户端性能测试：主要测试客户端的CPU使用率，内存占用率，网络流量使用情况，耗电量，帧率（FPS）。
iOS常用工具：xcode自带的instrument
安卓常用工具：emmage和GT
（3）服务端压力测试：服务器的CPU使用率，内存占用率，系统的吞吐量（TPS），事务响应时间，事务成功率
可使用工具：Jmeter
（4）兼容测试：机型匹配测试，操作系统兼容测试，屏幕分辨率兼容测试，游戏版本兼容测试。
（5）安全测试：内存修改测试，客户端加密测试，客户端反编译测试，网络安全测试。
（6）接口测试：主要测试服务端是否能正确分辨多个接口，接口安全测试，重复发送请求，查看接口处理情况。
测试工具：可用Jmeter工具实现或代码实现
（7）日志测试：客户端日志测试（通过玩家平时的日志，可以帮助我们排查游戏平时出现的bug），服务端日志测试（需要记录玩家平时详细的操作行为，方便我们根据玩家的行为作出数据分析）
（8）弱网测试：不同网络情况下，游戏的运行情况（如Edge,2g,3g,4g）。不同丢包率情况下游戏的运行情况（网络不好的情况下，丢包率严重）
可通过工具设置网络代理来实现，常用工具：fiddler,network link conditioner
（9）gm工具测试(一般运营人员和客服使用，方便规划游戏的活动或查询玩家数据)
（10）SDK测试（前端和后端数据库的存储及相关日志记录是否正确）：用户数据测试，充值、消费测试，与各个渠道对接测试
功能会议→测试用例书写→冒烟测试→详细测试→回归测试→CHECKLIST检查
功能需求会议(一般策划人员开)：测试人员需了解需求内容，提出可能存在的风险点，思考功能的测试重点和难点，如需工具辅助，需提出开发要求，思考可以优化的地方，并提出导论。
测试用例编写：根据需求书写测试用例，关注功能逻辑实现，考虑各种特殊情况（如边界值，网络中断，进程中断等），关注需求变更情况，需要及时调整测试用例。
冒烟测试（不能完全发现bug,特点是快速过一遍功能，把明显的bug告诉开发人员）：详细测试前的一个小环节，快速发现比较明显的bug以及确保主逻辑流程跑通，快速明确功能开展状态（比如是否有明显的功能缺失或者配置是否配全等等）
详细测试：细致的测试每个逻辑分支、资源、配置，尽量模拟玩家的每一种操作可能，测试异常情况（如断网，断电，事件中断、进程中断等），测试数据读取、存储、网络等内容。)
回归测试：测试已经被修复的内容，需求调整后的内容，再次详细测试各逻辑分支。
checklist（检查点，快速，不细测，可有可无，发布版本时测试）：简要快速的检查功能的主要逻辑点，检查与该功能有关联的任何其他功能点。
需求文档分析→功能模块划分→测试用例编写→测试用例整理与维护
需求分档分析：
文档阅读：细读需求分档，加深对功能的理解，理解功能的设计意图和思路
细节沟通讨论：
不明白的地方需要及时确认，尽早确认细节，关注需求变更，并在变更后与开发和策划确认
逻辑梳理：文档中的功能顺序有可能混乱，需梳理出框架后，逐步细化。
功能拓展思考：
a.设计缺陷思考（看看策划人员是否策划周全）
b.测试难点思考（比如刷新问题：时间太长，测试需借助手段）
c.关联度思考（比如领取道具存放背包中，需考虑背包存放有无上限，领取的道具是叠加在一个框还是排列，若叠加一个框，一个框课叠加多少道具等）
d.特殊情况思考（比日领取道具时断网等等情况）
兼容相关思考：
a.版本兼容（同时存在两个版本的情况下功能兼容问题）
b.功能兼容（新功能添加文题，比如增加英雄，会不会导致老英雄功能的改变等等）
c.操作系统版本兼容（安卓系统或者ios系统or其它系统兼容问题）
d.分辨率兼容（不同的分辨率显示的效果可能不一样）
功能模块划分原则：
a.高内聚，低耦合（模块内的功能紧密联合若尝试分拆则分拆后的内容很难单独继续存在。模块与模块间的联系关联度低无法合并为一个模块）
b.重整体，轻局部（在划分模块式须有大局观，从功能整体的层面上去关注模块的构成，如模块的逻辑，模块的覆盖范围等等。划分模块时不要纠结于某些具体的细节）
功能模块划分方法：
a.功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺。
举例：请就银行ATM的取款功能进行模块划分？
插卡->密码登录->输入金额->取出钱币->取卡
b.层次划分法：按照逻辑层次逐层细化模块的过程，比较适用于UI划分，大的系统模块划分等。
举例：请就Dota这款游戏进行模块划分？
->账号登录
->战斗外内容 …
->按键设置
DOTA
->英雄
->战斗内内容 …
->道具
c.类型划分法：按功能内容的类型划分。适用于一种功能的种类相对独立，而且种类间的耦合度较低的情况。
举例：兵种测试，道具测试等。
兵种测试分（可训or不可训）
道具测试分（可消耗or不可消耗）
PS：具体问题具体分析，有时候一个功能可结合多种方法划分，注重划分原则，划分完毕后结合需求文档重新梳理。
格式：清晰的格式很重要
首页内容：（用例关键信息）用例名称；游戏版本；编写人，编写日期，备注；修改人，修改日期、修改备注；需求文档的链接或地址
正文页内容：功能逻辑图（若有，便于理解）、用例id、模块名称、测试先决条件（入口）、输入信息、输出结果、备注信息
注意事项：用例有清晰的逻辑、一个输入只对应一个输出、保证每次更新用例后都有明确的记录标注、保证格式一致
等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据
有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程
无效等价类：是对输出来讲无意义的输入集合，验证特殊情况
边界值：对于输入或输出的边界值进行分析
边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据
适用：数值测试、字符串测试、数据类型测试等
因果图：输入与输出之间因果关系的一种关系图
适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况
方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来
判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在）
因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例
输入条件单一明确，不用容易引起误解的词，比如可能大概等
输出要可判断且明确，不用显示正确这种词汇
测试步骤要可执行
保证尽量高的覆盖度
能抽象合并的尽量抽象合并，避免无意义的冗余
需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人）
遇到冗余的测试用例，根据实际情况及时修改
注意测试用例的备份，在公司服务器上写完后本地也备份一份，避免被人线上误删除
1.Bug的界定准则：是否符合需求和是否违反常识
2.Bug的生命周期：发现bug->和开发人员反应，修复bug->验证bug->通过后 关闭bug意味bug死亡（若是在验收bug时bug仍未修复，则重复以上步骤）
3.Bug的等级划分：一般4或5个等级（P0致命错误P1严总错误P2一般错误P3无关紧要错误）
4.Bug的提案标准：
a.标题：【模块名称】+简短描述
b.测试环境:标明测试试用的版本，系统，服务器，账号等
c.描述：bug的详细描述
d.重现步骤（重要）：重现bug的详细流程步骤及复现概率，让开发人员节省时间
e.期望结果：希望bug修复后的结果
f.备注（不重要）：日志信息（log），截图信息等
5.Bug验收标准：
a.严格按照复现步骤验证
b尽量使用发现bug时的测试环境
c.验证标注：需要注明验证的版本、服务器等
d.拓展：尽量思考，是否对其它功能有影响，做简单回归
e.注意点：验证不能只看前端展现，更应该关注后端数据。（比如前端显示的数据正确，但后端的数据库不正确）
6.BUG的跟踪与推动：
a.每个人都有责任跟踪自己的bug的修复状态
b.及时与开发沟通，了解修复状态并提供修复过程中的支持（比如需要bug的详细信息）
c.久不修复的bug需要与开发沟通，如果开发认为bug问题不大可以和需求确认如何处理，若真的问题不大就可以直接关闭bug了
d.bug修复后，需要及时验证
6.最好课以做个bug的数据分析，比如项目中bug等级的统计，各开发人员中未修复bug的统计等等
网络信号差的情况下，高丢包率的网络环境，不同网络信号之间的切换，断线重连等对游戏运行的影响，前后数据一致的问题。
工具：macx系统：Network link Conditioner或Charles（Charles本是抓包工具但可以用于改变网络）
Windows系统：fiddler
常见性能测试指标：CPU 内存 FPS
CPU1、这里指的是游戏进程所占用的cpu占用率
2、抛开场景谈cpu性能无意义
3、安卓设备，90%的场景cpu占用小于60%
4、ios设备，90%的场景cpu占用小于80%
客户端与服务端之间的网络接口测试
常用工具：
Jmeter或者脚本语言自己写