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

有幸看到一位老师讲述的游戏测试课程,受益匪浅,再结合自己目前所做的工作,整理了本篇博客,了解游戏测试之后,真的会扩展一个人的思维。虽然本篇 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 conditionerCharles
  • Windows 系统可以借助Network Emulator for Windows ToolkitFiddler

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

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 数据分析
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐