撰写了文章 更新于 2017-07-02 20:55:14
《游戏测试精通》 笔记
一
原则：
不要恐慌
不要相信任何人
习题：列举两个可以体现二原则的科幻类游戏
…………EVE？星际2？
测试清单
测试前
使用的测试版本正确吗？
测试版本：_________
使用的构造版本正确吗？
构造版本：____________
使用的硬件配置/设置正确吗？
描述：______________________
使用的游戏控制器和设置正确吗？
描述：
使用了什么安装选项？（如果有
描述：
在测试前，游戏处于初始状态吗？
描述：
测试后
按顺序完成所有的测试步骤了吗？
记录了测试的整个过程和测试结果了吗？
记录了所有你发现的问题吗？
如果报告了一个问题，填在规定的地方了吗？
小结：测试需要注意什么？
首先要注意将要进行测试的游戏版本，版本不对就是纯粹浪费时间，应该是属于低级错误
使用pc的话硬件配置种类繁多，也应该尤其注意配置和设置是否符合测试要求。
然后控制器也需要进行核对，是手柄还是键鼠，是什么型号都是要确认的
以及游戏是否是初始状态，是否已经不是默认设置？
测试后检查测试流程是否完整
是否记录了过程和结果以及发现的问题
还有报告是否规范，能否被认作是有效的报告
二
有些测试是非常具体的
包含对步骤的具体说明（先如何，后如何，是否会发生什么）：依赖于敏锐的观察和对细节的注意。
测试用户界面时，这种方法时很可取的。
有些测试任务仅仅有宽泛的指示
可能以清单或提纲的形式给出，这些测试更依赖个人的游戏知识、经验、技能。
比如格斗游戏的招式测试
作为测试记住：
- 知道自己在团队中的角色和负担的责任
- 快速而准确地执行任务
- 先做最重要的测试
- 经常做测试 以便能尽可能的发现缺陷
- 尽可能的做出不包含情感的客观决定
测试顺序优先级
如果执行基本的操作而找到一个使游戏崩溃的缺陷，则不需要再担心他是否会引起足够的重视。但如果缺陷存在的方式并不明显，那么相对于其他缺陷可能是次要的。有一些具体的方法能放大所发现的缺陷而使他们得到尽可能快的修复。
- 尽可能早的执行测试
- 新增游戏关卡 人物 道具 剪切镜头…… 一旦引入马上检查
- 新增的自动程序 灯光 物理反应 粒子效应……
- 增加功能或修复缺陷的新增代码
- 新对话 文本 翻译 等
- 新音乐 音像效果 声音分组 音频附件 等
- 或者搜寻每一个地方
- 所有游戏中能激活同样的错误行为的地方
- 所有代码中调用包含缺陷的关卡、功能、或子程序的地方
- 所有使用同一有缺陷的物品、场景等模块的功能
- 所有跟有缺陷的内容关联同一属性的 物品、关卡、人物（种族，武器类型，级别）
三
***通报团队***
一旦发现问题，且能够描述它影响游戏的方式，就需要记录此信息并就此向开发人员通报。
DevTrack 是游戏行业中常用的缺陷追踪和管理工具之一。不必了解但应该熟悉
- 如何使用缺陷追踪系统
- 一个好的缺陷报告应该包含的关键信息
- 一些典型的错误和遗漏
- 有助于你查看并确定缺陷的其他事情
描述字段
在描述时，请一定包括所有这些细节：
- 人物（战士
- 事件（内墙的上部
- 地点（训练厅
- 时间（拜访符咒训练者之后
- 方式（跳跃
然后：如果可以请描述问题可能的解决方法以及其他有用的信息。
这有助于项目领导评价bug的重要性
有助于给开发者提供有关该问题是怎样发生的和如何应对该缺陷的线索。
而另一种描述方法是提供发现缺陷的步骤，如
创建一个战士。让他来到训练厅并拜访符咒训练者。离开福州训练者的房间并从他的门那里跳到墙上去。该战士能在墙上走动。但是不能跳下来重新开始游玩游戏。
此外也应该将 该出现 而没有出现的地方的信息包括进来。
缺陷优先级
测试攻城狮也有可能被要求对缺陷的优先级（或严重性）或类型进行分类
建议 通过下拉式菜单为缺陷分配初始的优先级
高优先级
高优先级的bug通常是那些导致玩家经历某种严重后果的缺陷，例如成功的提交了请求后不能得到请求的东西。这种bug的优先级在有些情况下也可能晋升为 紧急 类型。于是 第一次记录这种bug时。尤其针对多玩家的游戏，你应该非常谨慎的定义它的优先级。因为要是在发布的游戏中有人发现了这个bug而它随之又被公开了，那么一些邪恶的玩家就能够利用这个bug是游戏对自己有利，而对他人不利
中等
中等缺陷会导致明显的问题，但是可能不会影响玩家的奖励或者关卡。
高缺陷和中等缺陷的区别可能就在于查看和修复bug的先后顺序有所区别，将其搁置一边以便在后面发布的补丁中修复，或让游戏保持原样，这是对中等缺陷的做法。
因此 如果不确定，尽量分配到 高优先级，除非你的项目主管有其他指示，这样能尽可能的让缺陷得到修复。但不要滥用这个策略，否则你发现的缺陷不会如其本身那样得到重视。
低
低优先级通常是针对非常微小的缺陷而言的，这些缺陷不会影响游戏机制，他们在不可能的情况下发生，或只是个别问题。
*在许多游戏公司，也有严重性等级是与优先级联合使用的。
在这种情况下，严重性字段描述了这个bug对玩家的潜在影响，而优先级字段则帮助团队确定哪些缺陷应该最先进行修复。
这样，当一个影响较小（严重性较低)的缺陷非常显著时，例如在主菜单中的游戏名称拼错了；或当一个非常严重的缺陷出现在玩家的时间线里时，例如控制台的时间滚到了3000年时就引发一次崩溃，有助于测试人员区别他们的不同。玩家从缺陷中恢复的能力及与修复一个缺陷相关的风险或困难程度也是决定优先级的因素。在这个排列中，严重性一般由记录缺陷的人分配，而优先级通过变更控制委员会（CCB）或项目经理分派。
*注意
在测试的过程中，应记录运行的游戏版本，你的电脑配置，外设等。最好能为游戏制作和保留各种“存档”文件，因为这样你就能重复运行旧的测试，或者在尝试新的测试时不用将游戏从头再玩一回，一般推荐测试员本人保留一份自己的bug列表，这样有利于子啊项目期间对其采取相当的措施，不然就会像作者本人一样“遗失”或“移除”了 bug报告，但bug仍然存在，请确保你能分辨出每个保存的文件时为哪个版本做的，否则在发布新游戏时你会因为使用旧的文件而得到错误的测试报告。
小结
一旦你发现一个bug，确认它，并尽力在更多可能的地方重视它。然后再缺陷追踪系统中 记录该缺陷。标题要具体，描述尽可能详细，应确保提供了包含该问题原因和有助于重新产生并追查该缺陷的内容。
一份记录得很差的bug报告会浪费许多人的时间
测试的重要性
测试为什么重要？
- 游戏软件容易出错
- 有许多机会导致出错
- 游戏软件复杂
- 编写游戏软件的是人，而人是会犯错误的
- 常常用软件工具来编写游戏，而这些工具并不完美
- 大量资金投入到游戏中，是期望游戏能成功
- 游戏必须采用不同的配置和设备在多种不同的平台上运行
- 人们期待从你编写的游戏中得到更多的满足
- 如果同时有10w人在线玩你的游戏，你的游戏最好能保持良好运行，那样玩家才会按月付费来玩你的游戏
- 评论家时刻准备在报纸和互联网上评价你的游戏以及为游戏排名
- 游戏要有趣，满足人们的需求并准时发布
一句话总结就是 因为游戏会出错，所以测试很重要。 如果你能分辨游戏出错的机制或类型，不妨将测试中发现的问题归纳总结。
是谁在关注游戏测试
出版商，供应商
开发团队
测试之所以重要是因为要是一切顺利，他可能会得到褒扬，要是不顺利，销售额和利润就会蒸发。
但记住一点：即使考虑了所有关于员工、投资和专注的事情，游戏仍然会出错。
***缺陷类型***
请记住每种要么是执行结果不正确，要么就是缺少代码。下面列举出来的类型总括造成游戏的代码的不同要素
- 功能
- 赋值
- 检查
- 时间控制
- 构造/包装/合并
- 算法
- 文档
- 接口
***游戏团队***
开发团队
- 开发主管
- 开发攻城狮
- 构造攻城狮
测试团队
- 测试主管
- 测试攻城狮（游戏测试员、QA游戏测试员或QA攻城狮）
- beta测试员
美工团队
- 艺术总监
- 美术
- 动画
- 关卡设计师
音频设计团队
- 音效攻城狮
- 音乐总监
其他技术人员
- 项目经理
- 游戏设计师
组织团队
缺陷触发
操作区域
游戏前操作域
用户可以改变操作系统或者硬件环境从而影响游戏的运行
游戏启动操作域
是玩家启动游戏到游戏真正开始这中间的操作，这中间的一些活动可以被中断，比如说介绍游戏特点或高潮的动画片段。其他的活动如屏幕上显示 loading，则即不能被加快也不能被中断。同时游戏软件执行一些对用户不可见但对游戏运行起关键作用的进程。最后游戏进入了 READY 状态，这时只要玩家按任意键就可以进入游戏了。
游戏中操作域
游戏中包括玩家在游戏时可以做的任何事。有些功能只有在游戏进行才可用，有些则可以在游戏的任何阶段使用。还有一些功能只有当玩家满足某些条件时才能可用。合并有NPC的游戏也可以在游戏运行时管理和控制这些资源。
游戏后操作域
玩家有很多方法来结束游戏。离开时不存档比存档要简单。游戏结束时玩家通常都有机会来保存自己的游戏数据。运行在机器上的游戏软件可以通过关机来结束。如果机器的开关是在软件控制下，则游戏可以在关机之前存档并结束。
当玩家完成整个故事类游戏的情节时，游戏会给玩家看结局动画并提高玩家信用。有些游戏则对那些通关的玩家展示新情节以吸引玩家把游戏再玩一次。这是只有在游戏完成一次以后才可能激活的代码。
触发
有六种缺陷触发会出现在这寺中游戏操作域中。这些触发描述了在游戏测试中导致缺陷出现的原因。总之，这些触发考虑了 所有 可能出现的缺陷
配置触发
有些游戏配置是在游戏前设定。（SE：古墓丽影。 B社：辐射。等）
包括设备和环境的设定，比如说游戏软件的版本、数据和时间、显示设置、系统音量、操作系统版本、补丁和语言设置都是配置触发的例子。
配置还包括连接到游戏平台的外部设备。游戏控制器、键盘、鼠标、扬声器、显示器、网络连接、磁盘等 都是配置测试的一部分。
玩家可能在游戏中任何游戏运行域中断开一个或者多个设备或者改变设备。
连接设备能纠正一次意外的断开连接（比如宠物踢掉了连接线）
游戏设计和测试中都应该考虑到这些配置的改变。
启动触发
在游戏功能正在启动或代码正在初始化时所做的操作利用了 启动触发。应该高度注意这些活动，比如说屏幕显示 loading please wait... 而屏幕后面可能正在读取你要进入游戏的数据。
特定的代码弱点存在于启动过程，在游戏其他的运行阶段不会表现。因为代码变量已被初始化。图像信息已经被读取、缓存、呈现。信息已经从磁盘中读取或存入磁盘。
启动缺陷有游戏启动过程中的操作触发。这些操作可能是被用户发起的，也有可能是平台。中断启动顺序中的任意一部分都可能意味着一些关键操作无法完成它的工作或者根本就无法运行。启动缺陷说明是在游戏初始化和启动过程中对条件进行初始化时导致的错误结果。
举例来说，在你一开始使用游戏功能——新的地图，道具，回复生命值时出现的缺陷，都可被归为启动缺陷。
异常缺陷
游戏的特定代码需要通过异常触发来测试。游戏中的异常通常是由玩家发现的。“当”的一声警告或出现提示框通常是呈现游戏中问题的方法。一些异常处于游戏的控制下，比如说限制用户的输入选择。其他由于外部条件引起的异常则超出游戏软件的控制，比如说网络连接问题。异常可以出现在任何一个游戏操作域。
压力触发
压力触发是在极端的条件下测试游戏。这些条件可以施加在硬件或是软件上的。例如内存、屏幕、文件大小和网络速度都是游戏运行的条件，可以由用户指出或在测试中强调。仅仅强调一个限制并不构成压力条件。一旦强调了压力条件，就必须用一些方法对资源进行限制，这样在有压力的情况下才可能暴露出一些问题。
正常触发
正常的游戏操作属于游戏中操作域。这是在不考虑压力、配置、异常的情况下测试游戏，类似于测试一个demo或测试用户是如何玩游戏的情形。标准代码与处理异常的代码、处理配置的代码还有压力情况下工作的代码有明显的区别。
大部分的测试都是用正常触发。观察游戏在大多数时间是如何运行的 是正确的测试，因为测试并不仅仅是发现游戏的缺陷：他同样证明游戏功能可以如设想的一样工作。然而，仅仅使用正常触发的测试只能证明代码是否遵从脚本设计。他不能发现很多实际中的错误。
重启触发
重启触发对应的是玩家离开游戏、结束游戏。关闭游戏设备、弹出游戏磁盘，或以其他任何方法终止游戏时发生的错误。有些游戏做得很好，能提醒你要保存必要的数据，一般在你离开一个游戏场景，结束一个任务，或结束正在进行的一场战斗时出现这类提示。结束游戏时，有些数据需要保存而有一些则不需要。无论哪种情况不进行处理时，用户有可能收益但更可能失去之前的进度。
有些时候你可能马上会注意到结束游戏时再重启缺陷造成的后果，或者要等你下次进入游戏才会注意到这些后果，这些缺陷如果你不在存档后重新进入游戏，你是不会发现的，所以当你应用重启触发时你要记得也这么做。