看这一篇就可以入门了——游戏测试

来源：好游戏攻略时间：2024-11-22 05:27

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

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

目录 1. 游戏研发团队介绍1.1 制作人——项目整体负责人1.2 策划——设计人员1.3 开发——代码实现人员1.4 美术1.5 测试 2. 游戏开发流程3. 游戏测试的主要内容3.1 功能测试3.2 客户端性能测试3.3 压力测试3.4 兼容性测试3.5 安全测试3.6 接口测试3.7 日志测试3.8 弱网测试3.8.1 弱网工具 3.9 gm工具测试3.10 SDK测试 4 游戏测试的基本流程4.1 功能会议4.2 测试用例书写4.3 冒烟测试4.4 详细测试4.5 回归测试4.6 Checklist检查（非必要测试） 5 测试用例书写注意事项5.1 需求文档分析5.2 功能模块划分5.2.1 功能流程划分法5.2.2 层次划分法5.2.3 类型划分法 6 测试用例编写6.1 测试用例编写注意事项： 7 测试用例整理与维护8 Bug的界定标准8.1 Bug的等级划分8.2 Bug提报所要包含的内容8.3 Bug的验收标准8.4 Bug分析

1. 游戏研发团队介绍

在这里插入图片描述

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

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

1.2 策划——设计人员

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

1.3 开发——代码实现人员

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

1.4 美术

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

1.5 测试

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

2. 游戏开发流程

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

3. 游戏测试的主要内容

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

3.1 功能测试

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

3.2 客户端性能测试

性能测试的一些指标

客户端CPU使用率客户端内存占用率客户端网络流量使用情况客户端耗电量客户端帧率(FPS)ios常用工具Xcode自带的instrumentAndroid常用工具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 或CharlesWindows 系统可以借助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 数据分析