游戏开发团队及开发流程

安全测试

兼容测试

游戏测试，iOS和安卓端性能测试小工具

1、游戏开发团队：制作人、策划、程序、美术、测试

2、测试分类：功能测试、性能测试、压力测试、兼容测试、自动化测试、安全测试

3、游戏开发流程：

制作人：指定项目目标，规划

策划：讲项目目标拆解成细致的需求，丙烯画成文案

测试、程序、美术：将需求用代码和美术资源实现出来，测试写测试用例

测试：对项目的各个方面质量控制，将发现的缺陷反馈结果

BUG详解

发现BUG仅仅是测试工作的开始

BUG的界定标准：与需求设计不符；违背常识

BUG的生命周期：发现bug；提交给开发；开发修复；测试验证（不通过继续指派给开发）；通过后关闭；上线前回归

BUG的等级划分：

P0：致命错误，需要立即修复，如宕机、重启性报错等；

P1：严重错误，需要紧急修复，如功能流程错误、数值错误等；

P2：一般错误，允许一段时间内修复，如功能的简单错误、界面错误等；

P3：无关紧要的错误，允许延期修复，如文字错误、某个像素点缺失等等

bug的报错标准

标题：[模块名称]+简短描述

测试环境：标明测试用的版本，系统，服务器，账号等

描述：BUG的详细描述

重现步骤：重现bug的详细流程步骤及复现概率

期望结果：希望bug修复后的结果

备注：log，截图等

bug举例：

标题：〔士兵〕打开士兵技能升级页面报错

测试环境:内网测试服，V1.1.0版本，iOS系统，账号：ykl02

详细描述：当我们在游戏中打开士兵升级页面时，系统提示报错信息

重现步骤:1、进入游戏。2、打开士兵技能升级页面。3、系统报错。

期望结果：能够正常升级士兵技能，打开升级页面不报错

备注：报错信息见下面截图

BUG的验证标准：

严格按照复现步骤验证；

去除测试环境的影响，尽量使用提交BUG时的注明的环境；

验证标注：需要注明验证验证的版本、服务器等

拓展：是否对其它功能有影响，做简单回归

注意点：验证不能只看前端展现，更应关注后端数据

（比如购买道具，花了100，但是只扣了50；如果修复之后，前端确实显示扣了100，但是数据库中只扣了50，这就是“BUG的伪修复”）

BUG的跟踪与推动：

每个人都有责任跟踪自己的bug的修复状态；

及时与开发沟通，了解修复状态并提供修复过程中的支持；

久不修复的bug需要与开发和上级（需求人员）确认如何处理；

bug修复后，需要及时验证

BUG的数据分析：

根据bug优先级看各个优先级的bug数量；

根据项目人员看各个开发人员的bug数量；

根据功能模块看各个模块的bug数量

测试用例编写

格式：清晰的格式很重要

首页内容：（用例关键信息）用例名称；游戏版本；编写人，编写日期，备注；修改人，修改日期、修改备注；需求文档的链接或地址

正文页内容：功能逻辑图（若有，便于理解）、用例id、模块名称、测试先决条件（入口）、输入信息、输出结果、备注信息

注意事项：用例有清晰的逻辑、一个输入只对应一个输出、保证每次更新用例后都有明确的记录标注、保证格式一致

常用编写方法

等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据

有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程

无效等价类：是对输出来讲无意义的输入集合，验证特殊情况

边界值：对于输入或输出的边界值进行分析

边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据

适用：数值测试、字符串测试、数据类型测试等

因果图：输入与输出之间因果关系的一种关系图

适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况

方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来

判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在）

因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例

注意事项

输入条件单一明确，不用容易引起误解的词，比如可能大概等

输出要可判断且明确，不用显示正确这种词汇

测试步骤要可执行

保证尽量高的覆盖度

能抽象合并的尽量抽象合并，避免无意义的冗余

测试用例整理与维护

需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人）

遇到冗余的测试用例，根据实际情况及时修改

注意测试用例的备份，在公司服务器上写完后本地也备份一份，避免被人线上误删除

 0

采集 0

• 举报

查看TA的更多课程笔记

游戏测试入门

• 难度入门

• 时长 2小时35分

• 人数18129

• 评分9.8 

通过本课程的学习，大家首先会认识到游戏开发团队及流程，然后明白游戏测试主要工作内容，游戏测试基本工作流程，并学会需求文档分析，功能模块划分以及游戏测试用例之用例编写，整理与维护，接着你会了解到什么是Bug，如何鉴定Bug，以及如何在Mac环境下对弱网进行测试，最后你会学习到游戏客户端性能测试（安卓，IOS）以及游戏接口测试，希望通过这门课程的学习，能让你进入你期待的游戏测试领域。

详细了解此课程

ervinzhang软件测试工程师

微信公众号&知乎专栏：游戏测试风云录，

功能模块划分

划分原则：（博主自己的总结，不存在与任何软件测试书籍中）

1、高内聚，低耦合：模块内关联度高；模块间关联度低，无法合并成一个模块

比如一个货币购买的功能，月卡的购买和普通货币的购买可以划分成两个单独的模块，因为两者几乎不存在任何关联度，购买其中任何一个模块不会对另一个模块产生影响，符合低耦合的原则；

如果就月卡的购买进行分拆的话，显然没必要继续划分成功能和UI两个模块，因为月卡的购买流程非常简单，而且功能之间的关联度非常高，符合高内聚的原则。

2、重整体，轻局部：功能整体上关注模块构成、逻辑和覆盖范围，不用纠结较为具体的细节

还是以货币的购买功能为例，整体上可以划分为UI、购买与领取、特殊情况等大模块，或许也可以划分成一些子模块；不用太关注细节，比如页面上显示的倒计时、UI按钮的位置等等

划分方法：（博主自己的总结，不存在与任何软件测试书籍中）

1、功能流程法（小系统）：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查漏补缺

（银行取钱模块划分：插卡 -- 输密码 -- 输入金额 --取钱 -- 退卡）

2、层次划分法（大系统）：按照逻辑层次逐层细化出模块，直至不能划分

（dota游戏模块划分：见截图）

3、类型划分法：按照功能内容的不同类型进行划分（如按照道具的不同类型进行划分）

注意点

不同方法适用于不同场景

有时候一个功能要结合多种方法进行划分

划分方法不重要，原则更重要

划分完成后，结合需求文档重新梳理，确保模块清晰、覆盖完整、符合需求设计

游戏测试流程

游戏测试

游戏测试用例01 - 设计步骤

需求文档分析、功能模块划分、测试用例编写、测试用例整理与维护

需求文档分析：文档阅读、功能细节沟通探讨、逻辑梳理、功能拓展思考、兼容相关思考

文档阅读：切忌不阅读需求文档，上来直接写用例，至少读3遍文档

细致理解功能设计意图和设计思路

避免粗略理解带来的用例遗漏，保证测试用例的覆盖度

重要数据可能隐藏在不起眼的语句中

加深对功能的记忆，以免遗忘功能细节

思考功能有没有更好的实现方式

细节沟通探讨：

不明白的地方及时沟通，切忌脑补

尽早确认所有细节，最好在开始写之前就确认完毕

关注需求变更，需求变更后，一定要跟程序和策划确认

逻辑梳理：

文档不一定按照流程顺序写，而且经常存在功能交叉的地方，最好自己梳理逻辑

首先梳理出框架，然后梳理出细节

功能拓展思考：

设计缺陷思考（领取道具：数量、种类）

测试难点思考（领取道具：如何测试其刷新（调整服务器时间或修改配置））

关联度思考（领取道具：道具存储）

特殊情况思考（领取道具时断电断网服务器维护等特殊情况）

兼容相关思考：

版本兼容，同时存在多个版本时的兼容（交互是否有问题）

功能兼容，老功能中添加新内容（例如添加有不同属性的英雄）

操作系统版本兼容，不同操作系统版本

分辨率兼容

游戏测试主要内容（本节课主要以手游为例）：

功能测试、性能测试、压力测试、兼容测试、安全测试、接口测试、日志测试、弱网测试、gm工具测试、SDK测试

功能测试：

功能测试是游戏测试中最常见的模式，主要测试方法为黑盒测试；

功能测试主要用来验证功能是否符合需求设计；

功能测试主要考虑功能正确性，而不考虑游戏底层结构及代码错误；

功能测试通常从界面着手开始测试，尽量模拟用户可能出现的操作。

客户端性能测试：

客户端CPU使用率，客户端内存占有率，客户端网络流量使用情况，客户端耗电量，客户端帧频（FPS）

使用工具：

ios常用工具：xcode自带的instrument

安卓常用工具：emmage和gt

服务端压力测试：

服务器CPU使用率、服务器内存占用率、系统吞吐量（TPS）、事务响应时间、事务成功率

兼容测试：

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

安全测试：

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

接口测试：

服务器各个接口数据测试，主要通过工具来实现（比如用性能测试工具Jmeter只发送一个数据包）

接口安全测试，重复发送请求，查看接口处理情况

日志测试：

客户端日志、服务端日志

弱网测试：

不同网络情况，游戏的运行情况，如edge、2g、3g、4g情况

不同丢包率情况下游戏的运行情况

通过工具设置网络代理来实现，常用的fiddler（windows）、network link conditioner（MAC）

gm工具测试：

测试gm工具的功能实现，需要关注工具的设置是否在游戏中起作用

测试gm工具的数据读取、存储

SDK测试

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

BUG详解

发现BUG仅仅是测试工作的开始

BUG的界定标准：与需求设计不符；违背常识

BUG的生命周期：发现bug；提交给开发；开发修复；测试验证（不通过继续指派给开发）；通过后关闭；上线前回归

BUG的等级划分：

P0：致命错误，需要立即修复，如宕机、重启性报错等；

P1：严重错误，需要紧急修复，如功能流程错误、数值错误等；

P2：一般错误，允许一段时间内修复，如功能的简单错误、界面错误等；

P3：无关紧要的错误，允许延期修复，如文字错误、某个像素点缺失等等

bug的报错标准

标题：[模块名称]+简短描述

测试环境：标明测试用的版本，系统，服务器，账号等

描述：BUG的详细描述

重现步骤：重现bug的详细流程步骤及复现概率

期望结果：希望bug修复后的结果

备注：log，截图等

bug举例：

标题：〔士兵〕打开士兵技能升级页面报错

测试环境:内网测试服，V1.1.0版本，iOS系统，账号：ykl02

详细描述：当我们在游戏中打开士兵升级页面时，系统提示报错信息

重现步骤:1、进入游戏。2、打开士兵技能升级页面。3、系统报错。

期望结果：能够正常升级士兵技能，打开升级页面不报错

备注：报错信息见下面截图

BUG的验证标准：

严格按照复现步骤验证；

去除测试环境的影响，尽量使用提交BUG时的注明的环境；

验证标注：需要注明验证验证的版本、服务器等

拓展：是否对其它功能有影响，做简单回归

注意点：验证不能只看前端展现，更应关注后端数据

（比如购买道具，花了100，但是只扣了50；如果修复之后，前端确实显示扣了100，但是数据库中只扣了50，这就是“BUG的伪修复”）

BUG的跟踪与推动：

每个人都有责任跟踪自己的bug的修复状态；

及时与开发沟通，了解修复状态并提供修复过程中的支持；

久不修复的bug需要与开发和上级（需求人员）确认如何处理；

bug修复后，需要及时验证

BUG的数据分析：

根据bug优先级看各个优先级的bug数量；

根据项目人员看各个开发人员的bug数量；

根据功能模块看各个模块的bug数量

测试用例编写

格式：清晰的格式很重要

首页内容：（用例关键信息）用例名称；游戏版本；编写人，编写日期，备注；修改人，修改日期、修改备注；需求文档的链接或地址

正文页内容：功能逻辑图（若有，便于理解）、用例id、模块名称、测试先决条件（入口）、输入信息、输出结果、备注信息

注意事项：用例有清晰的逻辑、一个输入只对应一个输出、保证每次更新用例后都有明确的记录标注、保证格式一致

常用编写方法

等价类：一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，所以选取少量代表性测试数据代表整个数据

有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程

无效等价类：是对输出来讲无意义的输入集合，验证特殊情况

边界值：对于输入或输出的边界值进行分析

边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据

适用：数值测试、字符串测试、数据类型测试等

因果图：输入与输出之间因果关系的一种关系图

适用于：输入条件较为复杂，存在多种可能组合（笛卡尔积）的情况

方法：识别出因（所有输入）、中间节点、果（所有输出），并且根据关系连接起来

判定表：可以通过因果图来生成的一种结果判定表格（因、中间节点、果，01表示是否存在）

因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例

注意事项

输入条件单一明确，不用容易引起误解的词，比如可能大概等

输出要可判断且明确，不用显示正确这种词汇

测试步骤要可执行

保证尽量高的覆盖度

能抽象合并的尽量抽象合并，避免无意义的冗余

测试用例整理与维护

需求变化后及时更新并备注修改情况（修改内容、产品和开发负责人）

遇到冗余的测试用例，根据实际情况及时修改

注意测试用例的备份，在公司服务器上写完后本地也备份一份，避免被人线上误删除