游戏测试的目的：发现游戏中存在的缺陷。
一. 游戏测试主要内容
1. 功能测试
·功能测试是游戏测试中最常见的模式，主要测试方法为黑盒测试
· 功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试。
· 功能测试主要用来验证功能是否符合需求设计
· 功能测试主要考虑正确性，而不考虑游戏底层结构及代码错误
· 功能测试通常从界面着手开始测试，尽量模拟用户可能出现的操作。
· 从需求的角度来发现功能中的一些缺陷，并反馈
2. 客户端的性能测试
· 客户端CPU使用率
· 客户端内存占用率
· 客户端网络流量使用情况
· 客户端耗电量
· 客户端贞率(FPS)
· ios常用工具：xcode自带的instrument
· 安卓常用工具perfdog
3. 服务端的压力测试
· 服务器cpu使用率
· 服务器内存占用率
· 系统吞吐量(TPS)
· 事务响应时间
· 事务成功率
· 通常会写机器人模拟大量用户同时在线的情况来给服务端制造压力，也可以使用类似Jmeter工具来做压力测试
4. 兼容测试
· 机型适配测试
· 操作系统兼容测试
· 屏幕分辨率兼容测试
· 游戏版本兼容测试
5. 安全测试
· 内存修改测试
· 客户端加密测试
· 客户端反编译测试
· 网络安全测试：是否是明文，是否数据没加密，还要关注一些重复发包情况
6. 接口测试
· 服务器各个接口数据测试，主要通过工具来实现
· 接口安全测试，重复发送请求，查看接口处理情况
7. 弱网测试
· 不同网络情况，游戏运行情况，如edge、2g、3g、4g情况
· 不同丢包率情况下游戏的运行情况
· 通过工具设置网络代理来实现，常用的fiddler、network link conditioner
8. gm工具测试
· 通常是运营人员和客服人员使用的
· 测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用
· 测试gm工具的数据读取、存储
9. SDK测试
· 用户数据测试
· 充值、消费测试
· 与各个渠道对接测试
· 不仅要主要前端的功能，还要注意服务端的数据和日志信息
二. 游戏测试基本流程
1.需求相关流程
第一步_阅读策划需求：
阅读一份策划需求是测试人员在整个测试流程中最先碰到，也是测试工作的首要目标，我们可以通过阅读需求来了解即将要开发的功能、策划设计的思路与理念。
第二步_理解需求:
如何理解需求？与策划探讨沟通，再用现有的游戏逻辑与实际情况结合需求进行理解，从而考虑测试点、异常点，可能影响到其他模块的风险点（集成），能够大致通过需求阅读预估测试工时并制定测试计划
第三步_需求核对：
需求评审是测试流程中的重中之重，需求评审是需要多方评审（开发、策划、测试），需求评审也能保证测试质量？需求评审阶段测试人员应该做些什么：
需求评审阶段应该做些什么？
（1）熟悉该需求相关内容，提前考虑到需求风险，及时反馈需求风险，让开发人员在研发过程中注意，避免产生更多的Bug
（2）分析需求漏洞，及时反馈设计缺陷，需求评审会议时可以立刻修改策划案或会议后修改，避免研发后大量修改或重做
（3）在三方、四方人员对于需求看法的讨论过程中大致确认部分需求的负责人，明确处理人，方便后续的Bug提单
（4）在评审讨论的过程中通过开发人员、策划所描述的逻辑以及实现方式，考虑可能会出现的代码逻辑漏洞以及配置漏洞
（5）对于需求中存在疑问的地方及时提出，让策划方解答问题，为后续的测试用例编写以及测试做准备
（6）可以帮助策划提供一些需求上的建议内容、以及后续的优化，分析玩家群定位，也可以避免研发需求后大量修改或重做
（7）根据讨论的各类要素判定，从测试用例的编写以及测试流程的结束所使用的测试时长，以把控需求风险及测试质量
2. 制定测试计划
为何要制定测试计划？
制定测试计划的原因无非是为了保证测试工作能够如期进行，防止及规避需求所带来的发布风险，制定测试计划也能够避免我们手忙脚乱，能够井然有序的进行测试工作。
第一步_需求估时：
需求估时顾名思义是对需求进行充分性的评估所给出的预计测试时长，其中包括用例设计与执行的所需时间以及功能点划分等如何安排人力资源、所需的测试环境以及需要准备的测试设备
第二步_资源准备：
除了用例相关的测试时长预估，我们还需要准备测试环境以及测试设备，如果是管理人员还会涉及到人力资源的分配等（软件测试的标准流程对于测试计划制定非常严格，除了上述提及的以外，可能还需要测试工具、甚至是工具的版本等）
3. 用例相关流程
为何要进行用例设计及评审？
用例设计的目的主要是记录执行点，防止漏测，通过用例的形式进行管理与交叉测试执行，评审也是如此防止漏测，设计用例的根本目的还是为了保证产品质量
第一步_用例设计：
用例设计顾名思义就是使用所学的用例设计方法针对需求而设计的测试用例，这是在制定测试计划后的首要目标，用例设计一般用Excel编写。
第二步_用例评审：
用例设计后就是用例评审了，用例评审分为两种，一种是“组内评审”，一种是“三方评审”
组内评审：组内评审顾名思义就是由测试负责人完成用例设计后，由测试负责人在测试组内发起的评审，会由测试组成员进行组内评审
三方评审：通常由开发、策划、测试三方进行跨部门用例评审，评审主要的目的也是为了保障用例的完整性，避免遗漏设计导致漏测
通常而言先行进行组内评审，再进行三方评审，主要的目的是更加完善测试用例，在面对跨部门的时候可以节省一些沟通时间，其次嘛…怕遗漏太多，其他人会怀疑专业能力，组内评审过了，在进行三方评审，格局不就出来了嘛？
第三步_用例补充：
当测试用例评审完成后，测试负责人需要将用例进行完善补充，补充后不用特别再次同步，只要确保无遗漏补充即可（组内评审需要补充一次，三方评审需要补充一次）
4. 测试与跟进流程
第一步_执行测试用例
拥有一份完整的测试用例后，就可以直接开始正式执行，执行测试用例的过程中也需要注意及时同步测试进度哦~
第二步_记录执行结果
执行测试用例后标记执行结果，确保已执行的测试用例能够明确的给出执行结果，同时能够保证不会重复执行，标记方式可以随意使用，自己能记住即可，如果公司有用例管理平台就更棒了~
第三步_反馈并提交Bug
拥有执行结果后，确保Bug能够及时反馈提单，交付开发或策划进行修复，修复过程中无论执行工作进度是否为100%都应该给予一定精力进行Bug跟进，确保Bug能够及时修复
第四步_回归测试
在bug修复之后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
第五步_冒烟测试
冒烟测试其实是自由测试的一种。完成一个新版本的开发后，对该版本最基本的功能进行测试，保证基本的功能和流程能走通。如果不通过，则打回开发那边重新开发。
第六步_风险反馈及评估
执行测试用例后能够根据现有的Bug以及修复情况等综合来判断风险，进行简易评估，评估后及时反馈风险
5.输出测试报告
报告也不分步骤，通常而言包括几个重要内容即可，报告针对的项目或版本需求、所使用的测试环境、测试用例条数与执行条数，测试结果、测试质量情况、测试过程中遇到的瓶颈与问题，也会根据项目相关需求做出报告。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
