游戏测试用例

最新推荐文章于 2025-02-14 15:53:03 发布

mercies

最新推荐文章于 2025-02-14 15:53:03 发布

阅读量3.4w

点赞数 73

分类专栏：游戏测试文章标签：软件测试

本文链接：https://blog.youkuaiyun.com/mercies/article/details/117219918

版权

游戏测试专栏收录该内容

2 篇文章

订阅专栏

游戏测试用例

1. 设计步骤

1. 需求文档分析

1.1 文档阅读

切忌不阅读需求文档，上来直接写用例，至少读三遍文档
1 细致理解功能设计意图和设计思路
2 避免粗略理解带来的用例遗漏
3 一些重要数据可能隐藏在不起眼的语句中
4 加深对功能的理解，否则随着时间推移，可能会遗忘很多内容
带着思考去阅读，如果让你设计这个功能，还有更优的选择吗？

1.2 功能细节沟通探讨

不明白的地方需要及时确认，切忌脑补想当然
尽早确认细节，最好在开始写之前就确认完毕
关注需求变更，需求变更后，一定要跟程序和策划确认

1.3 逻辑梳理

文档不一定是按照流程顺序写的，而且经常存在功能交叉的地方
我们需要先梳理出框架后，逐步细化

1.4 功能拓展思考

设计缺陷思考：升级；拆解；道具；领取道具的数量，次数
测试难点思考：领取次数，刷新（测试，不能直接等）
关联度思考：道具存储问题
特殊情况思考：断电，断网，服务器维护

1.5 兼容相关思考

版本兼容：同时存在两个版本时，不同的版本
功能兼容：老功能中添加新英雄
操作系统版本兼容：mac，windows
分辨率兼容：美术展示等

2. 功能模块划分

2.1 功能模块划分时应遵循什么样的规则？

高内聚，低耦合：购买月卡和购买单个分开
重整体，轻局部：从整体关注

2.2 功能模块划分有哪些比较好的方法

功能流程法：将功能的基本流程画出来，根据流程的每个大的环节进行模块划分，然后再细化和查缺补漏。
举例：请就银行ATM的取款功能进行模块划分：
插卡环节–>密码登录环节–>输入金额环节–>取走钱币环节–>取卡环节
层次划分法：按照逻辑层次逐层细化出模块的过程，比较适用于UI划分，大的系统模块划分等。
举例：请就dota这款游戏进行模块划分
dota–>战斗内的内容–>英雄–>动画；技能
dota–>战斗内的内容–>道具
dota–>战斗内的内容–>地图
dota -->战斗外的内容–>账号登录；按键设置
类型划分法：按照功能包含的内容的不同类型进行划分。
举例：兵种测试，道具测试等。
兵种测试：可训练兵种和不可训练兵种
道具测试：可消耗道具和不可消耗道具
类型划分法比较适用于一个功能种类相对独立，种类之间关联度较低的情况。

2.3 模块划分注意事项

不同的划分方法适用不同的场景，要具体问题具体分析
有时候一个功能选哟结合多种方法进行划分
划分方法不重要，划分原则更重要一些
划分完毕后，要结合需求文档重新梳理，确保模块清晰、覆盖完整。

3. 测试用例编写

3.1 格式

一个清晰的格式很重要
1 让用例的脉络更清晰明了
2 方便需求变化后的更新维护
3 方便执行人员快速入手
首页内容
1 用例名称
2 用例对应的游戏版本
3 编写人、编写日期、备注
4 修改人、修改日期、修改备注
5 需求文档的链接或地址
正文页内容
1 功能逻辑图(如果有)
2 用例id
3 模块名称
4 测试先决条件
5 输入信息
6 输出结果
7 备注信息
关于格式的一些注意点
1 尽量保证逻辑清晰
2 尽量保证一个输入只对应一个输出
3 保证每次更新用例后都有明确的记录标注
4 尽量保证一个用例内格式统一

3.2 常用的测试用例编写方法

等价类划分
等价类：指的是一个输入集合内，任何输入数据对于输出的验证来讲都是等效的，此时我们就可以选取少量代表性的测试数据来代表整体数据。
等价类分为有效等价类和无效等价类
有效等价类：是对输出来讲有意义的输入集合，可以验证程序的正常功能和流程。
无效等价类：是对输出无意义的输入组合，用于验证非正常流程输入对输出的影响。
边界值分析
1 边界值：对输入或输出的边界值进行分析的一种方法
2 边界值的确定：一般选取正好等于，刚刚小于和刚刚大于3种情况作为测试数据
3 通常适用的范畴：数值测试，字符串测试，数据类型测试等
因果图&判定表
1 因果图：简单来说就是输入与输出之间因果关系的一种关系图
2 判定表：可以通过因果图来生成的一种结果判定表格
3 因果图常常与判定表一起使用，通过因果图生成判定表，通过判定表来书写测试用例

3.3 测试用例编写注意事项

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

4. 测试用例整理与维护

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

2. 游戏测试bug详解

2.1 BUG详解：

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

2.2 BUG的鉴定标准：

与需求设计不符
违背常识

2.3 BUG的生命周期：

发现bug --> 提交给开发 --> 开发修复 --> 测试验证 --> 通过后关闭–> 上线前回归
测试验证如果不通过 --> 不通过继续指派给开发

2.4 BUG的等价划分：

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

2.5 BUG的提报标准

标题：【模块名称】+ 简短描述
测试环境：标明测试用的版本，系统，服务器，账号等。
描述：bug的详细描述，卡住可继续前进，卡住不能走
重现步骤：重现bug修复后的结果
备注：log，截图等

2.6 BUG的验证标准：

严格按照复现步骤验证
去除测试环境影响
验证标准：需要注明验证的版本、服务器等
拓展：是否对其他功能有影响，做简单回归
注意点：验证不能只看前端展现，更应关注后端数据

2.7 BUG的跟踪与推动：

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

2.8 BUG的数据分析：

1 从bug级别：P2等级bug比较多，P0、P1较少，说明项目可以
2 从项目人员bug数据：
3 功能模块bug数据：

3. 弱网测试

弱网测试指：在客户端和服务器之间进行数据传输时发生的情况。
弱网测试案例：地铁、火车、边远地区、高层建筑、汽车经过隧道，边远地区等等。通过特定工具模拟

3.1 弱网测试要解决的问题

网络信号差的情况下，对游戏运行的影响
高丢包率的网络环境，对游戏运行的影响
不同网络信号之间切换时，对游戏运行的影响
断线重连对游戏运行的影响
前后端数据一致的问题

3.2 测试方法

不同的系统，使用的工具不一样
mac系统可以借助于Network Link Conditioner或Charles
windows系统借助于Fiddler这个工具
xcode --> open developer tool --> more developer tools
登录 – > 找 Hardware IO tools for xcode下载好
打开，Network Link Conditioner安装，系统偏好设置

4. 客户端性能测试–安卓

4.1 客户端性能测试指标

CPU

这里指的是游戏进程所占用的cpu占用率
抛开场景谈cpu性能无意义
安卓设备，90%的场景cpu占用小于60%
ios设备，90%场景cpu占用小于80%

内存(举例)
在这里插入图片描述

FPS(举例)
在这里插入图片描述
使用emmagee或GT模拟工具，顶部会出现一些使用信息

5. 客户端性能测试–ios

xcode --> open developer tool -->instruments -->
测cpu和内存： instruments --> Activity Monitor
连接手机，选好app后点recode
测FPS：instruments --> core animation
连接手机，选好app后点recode