《游戏测试精通》观后感

第I部分、游戏测试简介

第一章、游戏测试的两条原则：1.不要恐慌、2.不要相信任何人

在第一章第一节的学习中，我了解到了，作为一名测试工作者，不论是不是新手还是一个资深的“老人”，在处于以下场景时，都会或多或少的出现恐慌的情况：不熟悉环境或业务、未准备好、处于压力之下、不安、只能看见短期目标。

不论是在学习还是工作中，我们都会遇到不熟悉的情况，一个完全不同的项目、一个不熟悉的环境、与不熟悉的工作交接等等。当我们遇到这种情况时，心里感到些许恐慌是正常的情况，但是我们内心既不能太兴奋也不能太悲观，不要去做出头的“鸟”，也不能做缩头的“乌龟”，要依据我们自己的经验或判断来行事，要尽可能的为自己寻求足够的帮助；我认为这不仅包括来自同事的来自前辈老师们的，还要自己学会在网上在书籍中找出类似的问题的案例或者解答。我们得按部就班的一步一脚印的去了解问题熟悉问题。

而“未准备好”这个情况在我今后的工作中是肯定会出现的，这也是导致恐慌的一个重要的原因，我需要做的就是努力学习、多多实践、总结经验，不论是成功还是失败的经验都相当的宝贵，学习关于游戏项目和其他部分更多的知识和弄懂游戏代码的底层逻辑。

第三个造成恐慌的原因是处于压力之下，书中提及在游戏项目里压力主要来自于：进度表（规定的时间）、预算，和职员数，有时候在项目进行中，可能是上述某一个或多个资源处于缺少或缺失的情况造成压力。或者是另一种，当项目需求增多或者加入了一些没有列入计划的变化。而作为测试人员，我们无法控制压力的来源，但是为了平衡资源我们可以降低通常情况下的标准，来去优先做一些比较能影响需求的工作，然后就有时间去解决那些相对来说重要程度较低的问题。

书上写到第四个造成压力的原因是不安，不过我认为这个原因可以称为测试人员自己出现的错误，因为当我们测试人员在深夜进行工作或者长时间进行工作后，头脑难免会不清醒，如果此时我们上报了一个没有出现的BUG，反而会浪费开发人员的时间和精力，所以测试人员自己出现的错误也是导致压力的原因。书上提及解决或者说是缓解这个问题的答案是在每次测试前和测试后都列出一个清单，在测试前看看列出的清单里有哪些需要进行测试的需求或功能，测试完了之后也比较一下清单，检查一下自己在测试时出现的问题和清单上需要测试的内容。或者直接喊一位自己的同伴来帮助自己检查有没有出现错误。

第五个因素是只能看见短期目标，因为很多的游戏项目是需要花费数月甚至更长的时间来完成的，如果仅仅只是在意一个小的短期目标，那么很难做出一个好的游戏测试，一个短期的目标仅仅只是决定了今天需要干什么怎么干。书中提到，作为一个好的团队，当他们处于暂时的落后时，他们不会出现恐慌，而是倍感信心、镇定自若。总结昨天的工作内容，做好今天的工作内容，计划好明天的工作内容，按部就班的跟随领导的计划即可。

第一章第二节，阐述了游戏测试的第二条原则——不要相信任何人，这里的任何人代表着他人也包括自己，因为书中提及，在游戏测试中信任度和测试程度是成反比的，当信任度越高时，测试就会越低，而测试的降低则会导致测出游戏BUG变少，那么隐藏的BUG就越多，软件质量随之下降。在游戏测试中，在团队里，他人可能会处于好心，而给我们自己提出一些建议或者捷径，这虽然可以让我们的工作任务更快完成，但是同样的，也会导致测试程度下降，因为你的信任度提升了，这就意味着我们平时在工作学习中得尽量保持一颗理性客观的心。在自己的测试工作完成后在进行一次最后的检查，这也是对自己的不信任，在寻找缺陷的过程中也会增长经验，做出一个好的游戏测试。

第一章小结：本章讲述了当我们初入游戏测试时，应该具备的素养和品质，并且总结出了两个原则：不要恐慌、不要相信任何人，我们在工作中难免会出现自己所意料之外的情况，这时候我们不能紧张不能害怕，而是依据我们的经验，做出比较合理比较客观的判断，根据自己的实际情况来为自己寻求足够的帮助来应付所需挑战的问题，同时在工作中将自己的任务划分好优先级，先处理最重要的事情，主次分明。再是在测试过程中保持一颗怀疑的态度：“这些地方不用测了？真的没问题了吗？”，多练手多测试。

第二章、成为游戏测试员

第二章第一节述说了玩游戏和测试游戏的区别，当然想要成为一名好的游戏测试员，必须得先是一个游戏玩家，但是在形式上测试游戏没有像玩游戏那样自由且随意，更多的时候可能会更加的枯燥无聊。

在第二节中解释了测试员测试的目的——找出BUG和游戏哪部分可以正常运行，并且因为每一个测试员的性格的不同，找出的BUG的数量和种类也都各不相同，但是在测试工作中，没有哪个就是完全正确的，都各有利弊和长短。

身为一名游戏测试员，也得学会“放大”问题，即当你在测试时发现了一个问题，但是此时已经处于后期阶段，这个问题如果不是会使游戏崩溃，那么很可能就不会太受重视，那么此时我们就需要将这个缺陷“放大”，在其他有可能同样会出现这个问题的地方去测试，或者是在新项目添加时就对其测试，尽可能的早发现问题，早改正。

当我们发现缺陷发现BUG时，就需要去通报团队，但是这个通报也不是无章法的，首先要主义的就是对于缺陷的描述，要尽可能的包含：人物、事件、地点、时间、方式，如果可以加上问题的解决方法和其他有用信息那对于开发者而言再好不过了；而另一种描述缺陷的方式是提供发现缺陷的一步步的详细步骤。其次就是在上报缺陷时得清晰的注明缺陷的优先级（严重度），大体上分为：紧急、高、中、低四个层次，“紧急”优先级的缺陷通常会导致游戏的异常中断并且难以恢复，或者使玩家的某些信息丢失。“高”优先级的缺陷也会造成非常严重的后果例如无法获得自己正常可以获得道具奖励，不过测试员在定级时，得非常谨慎，因为有可能“高”优先级也可能会升级为“紧急”。“中”优先级的缺陷也会有严重的影响，不过不会影响玩家的游玩和奖励的获得，书中提及，“高”优先级的缺陷和“中”优先级的区别可能就在于查看和修复的先后顺序。最后则是“低”优先级的缺陷，这类缺陷通常情况下不会对游戏正常体验造成影响，或者只有在极少数情况下才会发现。当我们标注完缺陷的优先级，之后就是本次测试的“通过”和“失败”，书中表示，这两者在测试工作中都很重要，记录下测试的类型是“被阻碍”还是“无法获得”，这个信息将会传到测试主管那，也对后续的测试计划产生影响。

作为游戏测试员，当我们发现并上报BUG后，工作还没有结束，还需要对开发人员修复后的BUG继续进行测试，看看它是否符合正常游戏的需要，这也是上一章中“不信任”的体现之一。

第二章小结：本章说明了我们身为游戏测试员应当具备的责任和义务，以及工作时的要点和细节，尽管内容不多，但是却囊括了测试员工作的大部分内容。当我们发现BUG，时尽可能的去重现去重视它，描述时也得将标题写清楚写明白，让人可以一看见提交的缺陷报告就能够知道这个缺陷的优先级，严重程度；等到开发人员将BUG修复完后，再花些时间去重新测试一遍，保证这个问题今后不会再出现。

第三章、测试的重要性

之所以有游戏测试这一个行业，是因为它有着不可替代的重要性，不论是对于游戏出版

商还是游戏开发团队，甚至手机游戏对于手机厂商和无线运营商。这些人都无比的期望开发出来的游戏可以有一个好的质量，可以很少的甚至不出先问题，当然对于游戏的受众玩家而言更是如此，没有谁喜欢自己付出很多时间精力去玩的游戏是一个残次品。那么对于游戏软件本身，测试重不重要呢？依然十分重要！

软件是由人来开发的，那么或多或少的都会出现错误和BUG，当出现缺陷时，根据缺陷被引入、被发现、甚至在未来如何被避免来对缺陷进行分类是十分重要的，书中介绍了IBM公司的正交分类系统（ODC），并且按照八种缺陷类型来分类缺陷，主要有：功能、赋值、检查、时间控制、构造/包装/合并、算法、文档、接口。

功能错误会导致游戏性能异常并且影响用户的游戏体验，该错误可能是由于提供这一功能的代码错误或者遗失导致的。

赋值错误是当游戏中的某一个值被错误的初始化或设置，或者丢失了某一个参数值时，就叫做赋值错误。当我们在游戏时进入某个新的关卡或者新的游戏模式时，会容易出现。例如体育游戏的团队日程表、比赛的初始比分板，RPG游戏的开始时的状态、属性、技能点数等，当出现上述的赋值错误时，有时是对玩家有益，有时反而有害，因此我们游戏测试员在测试过程中时就得格外关注游戏中的数值平衡度，将数值稳定在策划所规划好的范围内。

检查错误是指代码中不能适当的验证数据，例如在代码中以赋值等号“=”替代比较等号“==”来对数据进行比较，或者没有关注边界值，将“<=”替换成了“<”，这些问题看似是小问题，但是在实际游戏体验中却可能会造成大灾难，因此必须得重视起来。

时间控制缺陷是在游戏里出现资源的管理和资源的调度时，出现的异常，有时也与用户的输入有关，例如用户连续的按下某个按键或者长按时出现的问题。

构造/包装/合并引发的缺陷可以简称为“构造缺陷”，是由于配置游戏源代码库，变更游戏文件管理，或者版本识别和控制引发的问题，当一个程序员想改变一个游戏的文件时，就就有可能会导致这个问题的出现。

算法缺陷是指玩家在游戏中遇到的不合理的计算数值或者一些游戏里的NPC或者其他物体的反常的行为，有时会影响玩家的游戏体验有时则会使玩家在游戏里获取一些不属于的权力和利益。例如体育游戏里的人机对战、电脑的应对政策，RPG游戏里的人物的对话或者一些举动，战斗时的伤害计算和战斗损耗等等。

文档缺陷是游戏中已经确定下来的，包括游戏的文本、音频、图形文件等，这种类型的缺陷不是游戏代码所导致的，而是在文件里获得数据或者被定义的常量。这种类型的错误通常会使游戏出现显示上的异常。

最后一个接口缺陷则是会发生在任何一个信息被转移或被交换的地方，统称为接口；在游戏代码里，当一个模块调用另一个模块出现错误时，接口缺陷就发生了。例如：使用错误的参数来调用函数、在参数顺序错误的情况下调用函数、在缺少参数的情况下调用函数等等。在测试时注意每一个参数的传递，以及函数的调用，就可以尽可能的避免接口缺陷的出现。

第三章小结：游戏测试在游戏中是极为重要的，因为游戏不可能不出现错误，要想游戏可以顺利的游玩下去，有一个较好的体验和一个较好的游戏质量，那么在游戏发行之前，就得做出充足的测试，排除掉绝大部分的错误和缺陷，是我们作为游戏测试员的责任之一。

 

第II部分、游戏制作

第四章、游戏团队

第一部分为开发团队，主要负责生产可以正确运行的游戏代码，并且将软件实现在可以在硬件上运行。开发团队内部主要有：

1. 开发主管，主要负责定义项目所需的开发活动，管理开发过程中出现的问题，指定开发中所需要执行的计划和规划。并且负责确立开发过程中的技术工具和标准。
2. 开发工程师，负责编写代码来制作游戏，一般分为前端（客户端）工程师和后端（服务器）工程师。
3. 构造工程师，对于一些较小的项目而言，项目的构建可能就由开发人员来完成了，但是在一些大型项目里，项目的构建则是由一个或多个专家来执行的。构造工程师的任务包括建立代码和游戏数据库素材库的结构、为每个游戏版本定义和维护说明等。

第二部分是测试团队，我们做测试时通常是为了保证某个物件的质量，做游戏软件尤其如此，在测试团队里，主要分有：

1. 测试主管，测试主管在功能上类似与开发主管，只不过测试主管主要是规划和协调测试行为，制定好一整个测试期间的计划。
2. 测试工程师，在之前的章节已经详细介绍了测试工程师的主要职责和工作内容，相比于开发工程师而言，测试工程师则更像是一个捣蛋者，需要去想方设法的在“鸡蛋里挑骨头”，但是相同是，两份工作都需要用热情来对待。
3. Beta测试员，这个测试员有些特殊，主要是在alpha测试之后进行，由玩家和使用者组成的一类测试员，以用户和玩家的视角来测试一款游戏，主要职责就是在游玩体验过程中记录下他们所遇见的任何问题。

当然还有其他的团队例如美工、音效团队、项目经理和游戏策划等等，都是完成一款精良的英雄所不可或缺的一部分。

第四章小结：在本次章节里，我跟随这书中的内容学习了一个游戏团队都有那些成员组成，包括开发、测试、美术、策划等等，一款精良的好玩的优秀的游戏绝对不是任何一个人或者几个人就可以完成的，必须得是一个完整的有纪律的团队花费一定的时间去慢慢打磨慢慢修正出的一个产品。在这个团队里每个人都有着不可替代的位置，只要团队里每个人都努力，相信一定可以研究出一款优秀的游戏。

第五章、游戏生产周期

一款游戏的开发从0到1，不管是需要多长时间，都需要经历过一系列的在行业内已经标准化的阶段，书中也详细介绍了游戏开发周期所对应的九个阶段，分别是：概念开发阶段、试生产阶段、开发阶段、alpha阶段、beta阶段、代码冻结阶段、生产发布阶段、补丁阶段、升级阶段。

当我们团队内的某个人对游戏有了一些新的想法，一些新的灵感，并且这些巧思足以撑起一个游戏的制作的时候，那么一个游戏的概念开发阶段就开始了。这是游戏生产周期的第一个阶段，也就是一款游戏从无到有的一个起点。在这个阶段里，主要目标就是根据刚刚的灵感，来构思出游戏的大主题，即表明了一个游戏要怎么去玩，玩些什么。将这个主题记录下来，并且还得一目了然，清晰可见，让别人一看就知道，“哦！原来这个游戏是这么玩的。”不仅仅是主题，在概念开发阶段，还需要提出一款游戏的中心概念、游戏的种类、游戏机制、游戏特征、游戏背景和目标受众。一款游戏首先想要做好，那就必须得是“专一”的，如果不清楚自己的定位，那么从一开始就注定这款游戏就只能是泛泛之辈，随大流的产物。

经过了概念开发阶段的游戏定位，就到了游戏生产周期的第二个阶段——试生产阶段，也被称为概念验证阶段，顾名思义，这个阶段就是为了验证上一阶段的思路是否可行，游戏是否值得玩家去玩，是否值得一做。这个阶段的目的是完成游戏的设计，确定游戏生产路线和项目计划。试生产阶段结束时，我们需要拿出的成果有：游戏设计文档、艺术生产计划、技术设计文档和项目计划。游戏设计文档详细讲述了所有发生在游戏里事儿，包括游戏的完整信息，用户界面、故事、人物、怪物以及其他细节。最好可以将这份文档以网页的形式保存，不仅可以随时进行更新，也可以方便的供他人观看。艺术生产计划包括了游戏的画风、游戏的美术风格、游戏的表现形式等，是一款游戏的外貌设计。技术设计文档由技术主管负责，决定了在试生产环节所需要使用的哪些技术，哪些工具。而项目计划则是规划好了如何去构造游戏，如何可以更好的将游戏开发出来，包含了一款游戏的开发中的各方各面。

如果一款游戏通过了试生产环节，那么就表明这款游戏是值得开发的，于是就进入到了开发阶段。在开头就有提及，一款游戏的开发时长是不确定的，因为有了一个好的计划不意味着可以事事都跟着安排走，看上去在计划的安排下一切都井井有条，但是就和小孩子过暑假一样，看似把一切都规划好了，可是当暑假结束的日子越来越近时，才发现之前的时间都去哪了？为了解决这一情况，书中提到了一个解决办法，那就是将一些较大的任务全都分解成一些较小的任务，小到方便处理，并且在完成这小小任务之后记录下来，这样就可可以清晰的知道自己是否落伍，使用的技术和硬件设备是否落后了。

Alpha阶段也叫做alpha测试阶段，主要是在公司举行的一次测试，当游戏的开发进行到这个阶段时，大体上的工作也已经开发完成，包括玩法、引擎、用户界面等，进入alpha阶段后，工作的重心任务也从构造游戏转变为了完善游戏。

Beta阶段，beta测试是继alpha测试之后又一次的大型测试，但是测试人员从公司内部转为了公司外部的玩家来进行测试，到这一阶段开发已经基本结束，游戏的内容也已经基本完备。目的就是在上线之前尽可能的发现更多的BUG，来稳定该游戏项目。

代码冻结阶段，当游戏的开发处于这一阶段时，就表明游戏里的代码已经全部被送去测试，基本上如果不出现什么紧急的BUG导致游戏出现崩溃等现象的话，就不会再对游戏代码进行改动了。

当所有的测试已经彻底结束，一切准备就绪，那么就代表着游戏已经可以上线发布了！即生产发布阶段。

但是所有的游戏都不是一蹴而就，一挥即成的，公司内部的测试无法发现所有的缺陷，在游戏上线之后依然会存在很多BUG，甚至是“紧急”优先级的BUG，这时候就需要发布补丁，去修复问题。这一阶段被称为补丁阶段。

升级阶段代表着游戏发行之后后续的更新，有时候它是新的玩法，有时候它是新的地图，有时候它也有可能是对游戏某些内容的重做，当处于这一阶段时，即升级阶段。但是一次升级也是一个小的项目，依然需要对其进行测试以及其他的步骤。

第五章小结：在这个阶段，我了解到了一款游戏从0到1的全过程，从小到大，从一个小小的构思，到最后完成的一款大型的游戏项目，在这个过程中，时间或许有长有短，但是不会改变的是游戏团队对于一款游戏的认真和负责，不论是在哪一个阶段，每个人都需要保持热爱，接近全能的去付出，市面上任何一款成功的好玩的游戏，无一例外不是如此。

 

第III部分、测试基础

第六章、软件质量

游戏也是软件的一种，对于游戏这类软件而言，在软件质量上，不仅仅包含着一款普通软件所具备的高质量特性，还有一些其他的元素，例如：游戏故事情节、游戏机制、美术风格和音乐音效的质量、游戏内元素的体现、游戏内的AI的智能水平······；除此之外，不管是在什么软件中，都是最重要的一点：一个良好的体验。这不仅仅体现在一个易于理解和使用的界面，还包括流畅的使用等等一些在表面上无法直观看出来的东西。这也是测试人员在进行测试工作时的一个重要考量之一。

第一节讲述了影响一款软件或者说游戏的质量的因素有哪些，那么第二节，就是接着引出了游戏质量的鉴定；因为游戏软件的质量主要是靠游戏的代码来决定的，在鉴定时，如果只有测试人员来进行，那么不是最好的办法，书中提及，最好的办法就是在问题引进之前就把问题消除，意思就是在代码编写前或者编写时就检查出问题，及时解决。但是和棋局中的道理类似，“当局者迷，旁观者清”。在和同伴的讨论之中，往往就会把问题发现并修复。书中提及了几个同伴评论的形式：1、走查：这种形式主要是由部分主管完成，在一个房间内走动，对工作提出自己的看法和建议，并在出现疑惑时对参与者进行提问。2、评论：书中的标题写的是“评论”，不过我认为应该是“会议”更加好一些，因为在这种形势下，通常由4~6个人组成，或者在一间大的会议室内，一起讨论和讲解，在其他人对讲解者提出问题的同时，也会使其发现问题。3、基于清单的评论：这种形式的规模比起“会议”更加小一些，只在两个人之间进行，同伴对于讲解者举出一个清单来列出自己所想要提出的疑问和漏洞，来帮助讲解者更加清晰的认识到自己。4、检查：这种形式相对比较正式，用于通过一个完整的步骤来进行。

除了游戏质量的因素和检测之外，还需要QA（质量检测）团队在测试时，得有一个固定好的执行标准，通常分为两类：用户界面标准、编码标准。

用户界面就是玩家在游玩时所看见的界面，书上表明了在测试时应所执行的标准，例如：文本清晰、字符大小相同、使用大写字母、避免横向菜单、给文本定位留下足够的空间、将按钮功能与游戏中的特定功能分开等等，这些标准都是非常有意义的，在为了测试工作中提供了一系列指标，提供了项目要符合标准的理由，对于工作和游戏质量的提升非常大。

编码标准通常是指在编写时的规范，这能有效的阻止在编写代码时的缺陷的发生。主要有：文件命名惯例、头文件引入、注释和缩进格式、使用常量、使用全局变量。这些标准的指定通常会使一个公司的代码都变得更加整齐和统一，使得其他员工在检查和观看时都变得更加清晰易懂。