游戏测试入门理论知识

对于怀揣游戏梦想，渴望投身这个充满创意与挑战领域的新人而言，游戏测试无疑是一扇极具吸引力的大门。它不只是简单地 “玩游戏”，而是融合了技术洞察、逻辑分析、细节把控以及对玩家体验深刻理解的综合性工作。每一款成功上线、收获无数赞誉的游戏，背后都离不开专业游戏测试人员的努力。他们如同游戏世界的 “质量守护者”，凭借敏锐的观察力和丰富的经验，在复杂的游戏代码与设计架构中穿梭，揪出那些可能影响玩家体验的细微瑕疵与潜在问题。

这本关于游戏测试入门知识的指南，将为你揭开游戏测试的神秘面纱。无论你是对游戏满怀热忱，想借此开启职业生涯新篇章的爱好者，还是在游戏开发领域初出茅庐，希望系统了解测试环节的新人，都能在这里找到清晰的方向。接下来的内容里，我们将从游戏开发团队的构成与协作讲起，逐步深入到游戏研发流程的每一个关键阶段，全面剖析游戏测试的主要内容与丰富多样的测试方法，最后详细解读如何设计精准有效的测试用例。

1.游戏研发团队介绍

1.1 制作人

作为项目的整体负责人，制作人承担着制定项目目标与规划的重任。他们需要把控游戏的整体方向，协调各个部门之间的工作，确保项目按照既定计划推进。

负责游戏研发环节

负责游戏运营环节

负责项目人员管理

负责项目事物管理

1.2 策划团队

策划团队将制作人制定的项目目标拆解为细致的需求，并以文案形式呈现。

系统策划，负责设计游戏的整体架构和各个系统的功能；

数值策划，精心调配游戏中的各种数值，如角色属性、道具数值等，以保证游戏的平衡性；

关卡策划，构建富有挑战性和趣味性的游戏关卡；

剧情策划，编织引人入胜的游戏剧情。

1.3 程序员团队

负责把策划的设计和美术资源等通过编码实现为可玩的程序，分为前端客户端程序员和后端服务器端程序员。

前端程序员负责打造玩家直接交互的游戏界面和操作体验

后端程序员则专注于服务器的搭建与维护，保障游戏数据的存储、传输和处理。

1.4 美术团队

负责创作游戏中的各种美术资源，包括角色形象、场景绘制、特效制作等，为游戏赋予独特的视觉风格。

游戏原画师

游戏建模师

游戏特效师

游戏动画师

游戏 UI 设计师

游戏场景设计师

游戏角色设计师

游戏灯光师

游戏渲染师

1.5 测试团队

在游戏开发中扮演着质量把关的角色，涵盖功能测试、性能测试、压力测试、兼容测试、自动化测试和安全测试等多个方面。他们通过各种测试手段，找出游戏中存在的缺陷和问题，为游戏的优化提供依据。

2.游戏研发流程介绍

制作人：[项目启动与规划] 制作人首先制定项目目标与规划，明确游戏的类型、受众、核心玩法等关键要素。
策划：[需求细化与传达] 策划团队将项目目标细化为具体需求，并以文案形式呈现。随后，策划组织会议，向团队成员传达需求。
开发、美术、测试：程序团队根据需求用代码实现游戏功能，美术团队同步制作美术资源。而测试团队则在需求传达后开始编写测试用例。在此过程中，测试人员需要深入了解功能需求内容，思考可能存在的风险点，确定测试重点和难点，例如是否需要工具辅助测试。同时，对于需求中可优化的地方，提出讨论。
开发与测试并行：在项目开发过程中，测试人员对项目的各个方面进行质量控制，及时反馈发现的缺陷。

3. 游戏测试主要内容

3.1 功能测试

功能测试聚焦于验证游戏各项功能的是否满足需求的设计，属于黑盒测试范畴，不关注底层结构与代码错误。

方法：从界面着手，模拟用户可能出现的操作

3.2 性能测试 PerfDog

性能测试围绕客户端展开，密切监测 CPU、内存、网络流量使用状况、耗电量以及帧率等关键指标

工具：IOS xcode自带的instrument

Android常用emmage和GT(GT 已经改名为PerfDog)

PerfDog跨平台工具

3.3 压力测试 Jmeter

压力测试着重考察服务器性能。在高并发场景下，测试服务器的 CPU、内存占有率，系统吞吐量 TPS（每秒事务处理数）、事务响应时间以及事务成功率

工具：Jmeter,模拟大量并发用户向服务器发送请求

3.4 兼容测试

兼容测试致力于确保游戏在不同机型、操作系统版本、屏幕分辨率以及游戏版本间的兼容性

3.5 安全测试

安全测试涵盖多个层面，包括内存修改测试，防止玩家通过第三方工具篡改内存数据，破坏游戏公平性；客户端加密测试，确保用户账号密码、游戏内交易数据等敏感信息在传输和存储过程中加密有效，不被窃取或篡改；客户端反编译测试，检查游戏客户端代码是否易被破解，避免恶意用户获取内部信息；网络安全测试，抵御网络攻击，保障游戏网络通信安全，守护玩家账号和游戏数据安全

3.6 接口测试 Postman/Jmeter

接口测试针对服务器各个接口数据展开。测试内容包含接口安全测试，验证接口的身份验证、授权机制是否健全；重复发送请求，检验接口对并发请求的处理能力；查看接口处理情况，确保接口能正确接收、处理客户端请求，并返回准确响应数据。例如游戏的登录接口，要保证在高并发登录时，接口能快速准确地验证用户信息并返回登录结果

工具：可通过代码编写测试脚本，或利用 Jmeter 工具发送各类请求

3.7 日志测试

日志测试分为客户端日志与服务端日志测试。客户端日志记录玩家在游戏内的操作行为，如登录时间、地点，游戏内的移动、战斗、交易等操作；服务端日志则包含服务器运行状态、错误信息、数据交互记录等

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

3.8 弱网测试 Fiddler/Charles

弱网测试模拟不同网络情况和丢包率，检验游戏在弱网环境下的运行表现。关注游戏在弱网下的连接稳定性、数据传输准确性、操作响应及时性，以及错误提示和恢复机制是否有效，确保玩家在网络不佳时仍能有基本的游戏体验

工具：Windows:Fiddler 或者 network emulator for Windows Toolkit

MAC:Charles 或者 network link conditioner

3.9 gm工具测试（运营，客服人员使用的工具）

GM 工具供运营和客服人员使用，GM 工具测试主要验证工具功能的实现情况，如角色属性修改、道具发放、任务状态调整等功能是否正常运行；检查工具的数据读取和存储准确性，保证修改后的数据能正确保存并在游戏中生效；关注工具设置在游戏中的实际作用，确保运营和客服人员能借助 GM 工具高效管理游戏，处理玩家问题，维护游戏秩序

3.10 SDK测试

SDK 测试针对游戏接入的软件开发工具包。主要测试用户数据在 SDK 中的传输与存储是否安全、准确；对充值、消费等涉及支付功能的部分，确保支付流程顺畅，金额计算准确，支付结果反馈及时；还要测试游戏与各个渠道 SDK 对接的兼容性，保证游戏能在不同应用商店等渠道正常上线和运行，为玩家提供稳定的服务

4 游戏测试的基本流程

准备阶段：制定测试计划
初始测试：功能和性能验证
中期测试：游戏平衡和用户体验
后期测试：兼容性和稳定性验证
发布前测试：最终品质保证

功能会议-->测试用例书写--->冒烟测试--->详细测试---->回归测试--->CHECKLIST检查

4.1 功能会议

参与人员：策划组织，其余人参与
测试员的主要工作
- 了解功能需求内容
- 提出可能存在的风险点
- 思考功能的测试重点和难点，例如如需要工具辅助
- 思考可以优化的地方，并提出讨论

4.2 测试用例书写

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

4.3 冒烟测试

测试主要功能
详细测试环节的准入条件

4.4 详细测试

关注点：各个逻辑分支、资源、配置
尽可能模拟玩家的每一种操作
测试异常情况，如断网
测试数据读取、存储、网络传输等
测试该功能对其他功能的影响

4.5 回归测试

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

4.6 CHECKLIST检查

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

5. 测试用例编写流程介绍

编写测试用例流程：

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

5.1 需求文档分析

5.1.1 文档阅读

关注点
- 理解功能设计意图和思路
- 加深印象，避免用例遗漏
方法
- 至少读三遍
- 带着思考，想出更优选择

5.1.2 功能细节沟通探讨

关注点
- 不明白的地方及时确认
- 尽早确定细节
- 需求文档的变更
方法
- 跟有关程序、策划人员及时沟通

5.1.3 逻辑梳理

关注点
- 复杂的功能
- 乱序的需求文档、功能交叉的部分
方法
- 先梳理框架，逐步细化（场景法）

5.1.4 功能拓展思考

关注点
- 设计缺陷
- 测试难点
- 关联度
- 特殊情况

方法
- 参考类似案例
- 头脑风暴

5.1.5 兼容相关思考

关注点
- 版本兼容
- 功能兼容
- 操作系统版本兼容
- 分辨率兼容

方法
- 制定兼容矩阵

5.2 功能模块划分

关注点
- 高内聚，低耦合
  - 模块内部紧密关联、各模块间关系尽可能少例如购买月卡模块、购买普通货币
- 重整体，轻局部
  - 大体框架，先别死扣细节例如购买货币-->UI 、购买、领取、特殊情况
- 积累的经验

方法
- 功能流程场景法：将功能的基本流程环节画出来，然后根据流程的每个大的环节进行模块划分，最后细化和查漏补缺
  - 举例：就银行ATM取款功能进行模块划分
  - 插卡环节--密码登录环节--输入金额环节--取钱环节--取卡环节
- 逻辑层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块的划分
  - 举例：请就dota这款游戏进行模块划分
- 功能类型划分法：按照功能包含的不同类型进行划分
  - 举例：测试兵种、测试道具
- 数据驱动划分法：依据游戏中处理的数据类型和数据流向来划分模块
  - 举例：任务系统进行功能划分
  - 战斗数据模块-->任务数据模块-->玩家数据模块

5.3 测试用例的编写

5.3.1 格式

首页内容
- 用例名称
- 用例对应的版本号
- 相关人员
- 编写人、编写日期、备注
- 修改人、修改日期、修改备注
- 需求文档的链接和地址

正文页内容
- 功能逻辑图（如果有）
- 用例编号
- 模块名
- 前置条件
- 输入数据
- 输出结果
- 备注信息---方便执行人员理解

注意点
- 逻辑清晰
- 一个输入对应一个输出
- 更新用例加上明确标记
- 保证一个用例内部格式统一

5.3.2 方法

游戏测试种常用的方法：等价类、边界值、因果图和判定表、场景法[可参考软件测试方法，不过常用的就是上述几种]

等价类
- 有效等价类：对于输出来说有意义的输入集合，用于验证正常功能流程
- 无效等价类：对于输出来说无意义的输入组合，用于验证非正常的情况

边界值
- 正好等于
- 刚刚小于
- 刚刚大于

边界值示例：范围2000-3000，那么我们需要对边界值进行测试，测试取值：1999、2000、2001、2999、3000、3001

因果图、判定表
- 因果图
  - 输入与输出之间因果关系的一种关系图
- 判定表
  - 通过因果图生成的一种结果判定表格

可参照博文：因果图法-CSDN博客

因果图判定表示例：一个自动售货机，处理单价为5角，售货机出售橙汁和啤酒，单价为5角，若投入5角硬币，按下对应饮料按钮则会投送饮料，若投入1元硬币，则透出饮料并退回5角硬币

5.3.3 原则

输入条件单一明确，避免使用容易引起误解的词
输出要可判断且明确，例如“显示正确”×
测试步骤要实际可行（玩家可能会做的），例如测试一秒点击一万次×
追求尽可能高的覆盖度
避免冗余，学会抽象表达

5.3.4 整理与维护

需求变化后需要及时更新老的测试用例，并写清楚修改情况的备注
冗余用例酌情修改
本地备份

6. 缺陷管理

6.1 BUG的界定标准

与需求设计不符
- 例如：某关奖励道具没有出现
违背常识
- 例如：明细战力数据异常

6.2 BUG生命周期

6.3 BUG等级划分

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

6.4 BUG提交标准--必填项

标题：【模块名称】+简短描述
测试环境：标明测试用的版本，系统，服务器，账号等
描述：BUG的详细描述
重现步骤：重现BUG的详细流程步骤及复现概率
期望结果：希望BUG修复后的结果
备注：日志，截图等

BUG例子

标题：[士兵模块]打开士兵技能升级界面报错

测试环境：内网测试服，v1.1.0版本，iOS系统，账号：zjf01

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

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

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

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

6.5 BUG的验证原则

严格按照复现步骤验证
去除测试环境的影响
验证标注：需要注明验证的版本、服务器等
拓展原则：该BUG是否对其他功能是否有影响，做简单回归
拓展原则：验证不能只看前端展现，更应关注后端数据，防止伪修复例如数据的增减

6.6 BUG跟踪与解决

原则
- 每个人都有责任跟踪自己BUG的修复状态
方法
- 及时与开发沟通，了解修复状态并提供修复过程中的支持
- 久不修复的bug需要与开发和上级确认
- bug修复后，需要及时验证

配套思维导图：入门游戏测试配套思维导图资源-CSDN文库

前言