所有的好书，读起来就像和过去世界上最杰出的人们的谈话。

有幸看到一位老师讲述的游戏测试课程，受益匪浅，再结合自己目前所做的工作，整理了本篇博客，了解游戏测试之后，真的会扩展一个人的思维。虽然本篇 Blog 主要分享的是游戏测试方面的测试，但是针对其他行业比如直播类的测试也是适用的。本篇文章适用于初入软件测试行业的小白。

1. 游戏研发团队介绍

1.1 制作人——项目整体负责人

负责游戏研发环节
负责游戏运营环节
负责项目人员管理
负责项目事物管理

1.2 策划——设计人员

剧情策划
	负责规划游戏中的各种剧情、故事、背景等。
系统策划
	设计游戏中各种系统的规则
数值策划
	规划游戏中各种资源的产出、消耗等
关卡策划
	设计游戏中各种关卡

1.3 开发——代码实现人员

负责把策划的设计及美术资源等通过编码实现可见的程序。开发也分为后端开发人员和前端开发人员
后端开发：实现服务器端的逻辑、数据验证等
前端开发：实现游戏客户端端展现与逻辑

1.4 美术

制作游戏中的各类美术资源
包括场景、原画、UI、动画等

1.5 测试

项目的质量保证人员，主要工作是发现游戏中存在的缺陷并及时反馈出来
测试也可分为功能测试、性能测试、压力测试、兼容性测试、自动化测试、安全测试

2. 游戏开发流程

1. 制作人：指定项目目标并规划目标
2. 策划：将项目目标拆解成细致的需求，并将需求细化成文案
3. 测试、开发、美术：将需求用代码和美术资源实现出来，测试写测试用例
4. 测试人员：对项目各个方面进行质量控制，将发现的缺陷反馈出来。

3. 游戏测试的主要内容

其他行业的测试内容，也涵盖其中

3.1 功能测试

• 是最常见的测试模式，主要测试方法为黑盒测试
• 主要用来验证功能是否符合需求设计
• 主要考虑功能的正确性，而不考虑游戏底层结构及代码错误
• 通常从界面着手开始测试，尽量模拟用户可能出现的操作

3.2 客户端性能测试

性能测试的一些指标

• 客户端CPU使用率
• 客户端内存占用率
• 客户端网络流量使用情况
• 客户端耗电量
• 客户端帧率(FPS)
• ios常用工具Xcode自带的instrument
• Android常用工具emmage和GT

3.3 压力测试

• 服务器CPU使用率
• 服务器内存占用率
• 系统吞吐量(TPS)
• 事务相应时间
• 事务成功率

3.4 兼容性测试

• 机型适配测试
• 操作系统兼容性测试
• 屏幕分辨率兼容性测试
• 游戏版本兼容性测试

补充：在无论是兼容性测试，还是平常的迭代测试，我们都要求机型覆盖，一般来说，我们会选择中高低机型作为测试，而中高低机型的判断，主要是通过处理器来决定，给大家推荐一个手机处理器天梯图

3.5 安全测试

• 内存修改测试
• 客户端加密测试
• 客户端反编译测试
• 网络安全测试

3.6 接口测试

• 服务器各个接口数据测试，主要通过工具来实现（工具：jmter）
• 接口安全测试，重复发送请求，查看接口处理情况

3.7 日志测试

• 客户端日志
• 服务端日志
  通过客户端和服务端的一些日志可以模拟出客户的使用姿势，或者可以模拟出玩家的行为。

3.8 弱网测试

• 不同网络情况下游戏的运行情况，如edge、2G、3G、4G等
• 不同丢包率情况下游戏的运行情况
• 不同网络信号之间切换时，对产品运行的影响
• 断网重连对产品运行的影响
• 前后端数据一致相关的问题。

3.8.1 弱网工具

• Mac系统可以借助于Network Link conditioner 或Charles
• Windows 系统可以借助Network Emulator for Windows Toolkit、Fiddler

针对弱网测试可以参考小编的另一篇文章。

3.9 gm工具测试

游戏中常用的工具

• 测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用
• 测试gm工具的数据读取、存储

3.10 SDK测试

• 用户数据测试
• 充值、消费测试
• 与各个渠道对接测试

4 游戏测试的基本流程

虽然本篇blog主要分享的是游戏测试方面的测试，但是针对其他行业比如直播类的测试也是适用的。

4.1 功能会议

• 了解功能需求内容
• 提出可能存在的风险点
• 思考功能的测试重点和难点，如需要工具辅助，需提出开发需求
• 思考功能可优化之处，并提出讨论

4.2 测试用例书写

• 根据需求书写测试用例
• 关注功能逻辑实现
• 考虑各种特殊情况，如边界值，网络中断，进程中断等
• 关注需求变更情况，需求经常发生变更，需要及时调整测试用例

4.3 冒烟测试

• 详细测试之前的一个环节，快速发现比较明显的bug
• 快速确保主逻辑流程跑通
• 快速明确功能开展状态

4.4 详细测试

• 细致的测试没个逻辑分支、资源、配置
• 尽量模拟用户的每一种操作可能
• 测试异常情况，如断网、断电、事件中断，进程中断等
• 测试数据读取、存储、网络等内容
• 测试该功能对其他功能对影响

4.5 回归测试

• 测试已经被修复等内容
• 测试需求调整后的内容
• 再次详细测试各逻辑分支

4.6 Checklist检查（非必要测试）

• 快速的检查功能的主要逻辑点
• 检查与该功能有关联的任何其他功能点

5 测试用例书写注意事项

5.1 需求文档分析

• 文档阅读
  首先要对需求分档进行分析，找负责人进行细节沟通、逻辑梳理，功能扩展相关的问题还有兼容性，针对兼容性，可以问最低和最高机型支持情况。需求文档至少要阅读三遍，这样可以加深对功能的理解。
• 细节沟通
  不明白的地方要及时确认，千万不要脑补想当然。如果需求文档有变更，一定要跟程序员和测试再三确认。
• 逻辑梳理
  虽然我们测试很少写代码，但是我们也需要了解下功能实现逻辑，需求有些需求文档不一定是按照流程写的，可能会出现功能交叉的地方，所以要梳理出框架后，逐步细化。
• 功能扩展思考
  可以看看功能设计思路是否有缺陷，测试难点思考，关联度思考，特殊情况思考。
• 兼容相关思考
  版本兼容、功能兼容、操作系统版本兼容、分辨率兼容

5.2 功能模块划分

功能划分的原则：高内聚低耦合、重整体轻局部。大概就是根据功能内部之间和模块与模块之间。
不用的划分方法适用于不同的场景，要因具体问题具体分析

5.2.1 功能流程划分法

将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

5.2.2 层次划分法

按照逻辑层次逐层细化出模块的过程，比较适用于UI划分和比较大的系统模块划分

5.2.3 类型划分法

按照功能包含内容的不同类型进行划分

6 测试用例编写

在编写测试用例时，我们需要注意格式，格式的话可以选择表格或者流程图的方式，哪个熟悉用哪个，最主要的是能覆盖全功能即可，能够让人一目了然。测试用例需要包含以下内容：

• 用例名称
• 版本
• 编写人、编写日期、备注（编写人和编写日期一定要写，别人这一点不起眼，有用到的时候）
• 需求文档的链接或者地址（和本次测试有关的信息，都要放上去，可以充当为背景资料，测试来源）
• 模块信息
• 输入信息、输出结果
• 备注信息

补充：
我们肯定听说过测试用例常用的编写方法：等价类、边界值、因果图和判定表。

• 等价类
  指的是一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，此时就可以选取少量代表性的测试数据来代表整体数据。等价类又分为：有效等价类和无效等价类。
  等价类示例：假如购买一个商品，商品的价格是12块钱，那么我们就需要取 11、12、13 3个数据去测试验证，即可代表所有数据测试，从而节省很多时间。
• 边界值
  对输入和输出的边界值进行分析的一种方法，边界值的确定,一般选取正好等于，刚刚小于和刚刚大于的情况，通常适用的范畴：数值测试，字符串测试，数据类型测试等
  边界值示例：范围2000-3000，那么我们需要对边界值进行测试，测试取值：1999、2000、2001、2999、3000、3001
• 因果图和判定表
  两者是息息相关的，通过因果图生成判定表，通过判定表来书写测试用例。因果图是输入和输出之间因果关系的一种关系图
  判定表：可以通过因果图来生成一种结果判定为表格，

6.1 测试用例编写注意事项：

• 输入条件要单一明确，尽量不用容易引起误解的词，比如可能，大概等
• 输出要可判断且明确。最好不用“显示正确”这种词汇。
• 测试步骤要可执行
• 保持尽量高的覆盖度
• 能抽象的尽量抽象出来，避免无意义的冗余

7 测试用例整理与维护

• 需求变化后需要及时更新老的测试用例，并写清楚修改情况的备注
• 测试用例应该尽量避免冗余，如果遇到重复的用例，需要根据实际情况进行修改
• 注意测试用例的备份，写完后最好自己本地也备份一份，避免线上被人误删除

8 Bug的界定标准

• 与需求设计不符
• 违背常识

8.1 Bug的等级划分

• P0：致命错误，需要立即修复，如宕机、重启性报错等
• P1:严重错误，需要紧急修复，如功能流程错误，数值错误等
• P2：一般错误，允许一段时间内修复，如功能等简单错误，界面错误等
• P3：无关紧要的错误，允许延期修复，如文字错误，某个像素点缺失等等。

8.2 Bug提报所要包含的内容

有的公司使用Jira、有的公司使用邮件或者表格，这都没有关系，重要的是要包含以下信息。

• 标题：模块名称+简短描述
• 测试环境：标明测试用的版本，系统、服务器、账号等
• bug详细描述
• 重现步骤：重现Bug的详细流程步骤及复现概率等
• 期望结果：希望Bug修复后的结果
• 附件：log、截图、视频等

8.3 Bug的验收标准

• 拓展：是否对其它功能有影响，需要简单回归
• 注意点：验证不能只看前端展现，更应关注后端数据
  Bug的跟踪与推动
• 每个人都有责任跟踪自己的Bug的修复状态
• 及时与开发沟通，了解修复状态并提供修复过程中的支持
• 长时间未修复的bug需要与开发和上级确认如何处理
• bug修复后，需要及时验证

8.4 Bug分析

针对Bug的分析我们可以从以下几个纬度

• 根据 Bug 等级分析：罗列出 P0、P1、P2、P3 类型的 Bug 加以分析
• 根据项目人员Bug数据，这里面可以包含两种方式，第一种方式是根据测试人员检出的Bug数进行分析，第二种方式是根据分配给开发的 Bug 数进行进行
• 根据功能模块 Bug 数据分析