探索游戏中的Bug，带您了解游戏测试！

草帽路飞UU

一、什么是Bug？

       根据当代IT类行业，Bug通常而言指的是计算机软件与硬件的漏洞或缺陷，在游戏测试的领域中，也包括游戏玩家、测试人员所发现和提出的游戏体验问题或与策划案（需求文档）存在差异的功能实现等，那么如何区分它是否是Bug呢？

我们大致从以下几点得出结论：

  （1）策划案中所提及的内容，程序未实现。

 例如：策划案中说明玩家在商城充值10元后发放元宝至玩家账户，但程序未实现该功能

  （2）策划案中明确不要做的内容，程序已实现。

 例如：策划案中说明不可将商城充值的元宝发放至邮件，但程序实现了

  （3）策划案中未提及的内容，程序已实现。

 例如：策划案中没有说明要将元宝以道具形式发放至背包，但程序实现了

  （4）策划案中未提及但必须要做的内容，程序未实现。

 例如：策划案中未提及弱网环境下充值需要到账，但程序未实现该功能

  （5）游戏实现的内容难以理解、对新手不友好、运行缓慢等，测试人员站在最终玩家的角度看到的问题是平常的且不是正确的。

 例如：当玩家在充值系统进行充值时，展示发放元宝奖励，但未说明发放的具体数量让玩家难以理解或是在奖励发放过程出现卡顿现象

二、Bug分类

2.1 Bug的类型

  游戏测试中的Bug也分为很多种类型，我们在发现Bug的时候也要对Bug进行分类，游戏测试的Bug主要分为8大类型:

（1）功能错误：最常见的错误类型，功能错误即为功能性上的错误

例如：充值未到账、经验卡加成道具无法使用、无法接收到邮件等

 （2）代码错误：开发人员代码程序上的错误逻辑与漏洞

例如：服务器下发数据错误、if else等的逻辑错误，大小写、中英文符号错误等

 （3）配置错误：策划配置表上的配置错误，少配、多配、漏配以及不符合配置规范

例如：必填项的内容未配置、需要配置5个内容但配置了4个，要求填写的数值为1到100，但填写了1000等

 （4）设计缺陷：策划案中所描述的内容不正确、不合理或与其他系统、模块拥有明显冲突等情况

例如：结婚系统每日5点20分刷新情缘任务，但游戏的通用逻辑是6点刷新。社交系统可以让两个陌生异性结婚而没有好感度的培养等

 （5）安装部署：测试环境搭建错误、项目部署错误、打包地址无法登录等

例如：IP映射错误、测试环境并非纯净环境，夹杂了开发环境的因素，服务器到期、证书过期导致无法登录等

 （6）专项测试：专项测试领域相关的错误

例如：匹配队伍的性能卡顿、弱网络下无友好提示、商城界面适配排版错误，赛季刷新或排行榜的数据兼容错误等

 （7）界面错误：UI界面上的错误，UI展示不合理，对话框样式、文字描述错误

例如：社区界面的UI排版错误、商城界面的UI不合理、NPC对话文本偏离、运营活动的时间开放文字描述错误等

 （8）建议类型：通常指的是玩家或测试人员对于游戏内玩法、流程上等内容的一些体验建议

例如：攻击动作体验上不够流畅、玩法相对于单一，缺少玩家的交互性、团队协作性等的参考建议

  大部分情况下，游戏公司的测试组成员并不会在提交Bug单时附带上Bug的分类。部分公司受Bug管理工具的影响，会按照上述的方式内容进行提交，例如禅道系统。（如下图1-1、1-2所示）

                  

        

三、Bug严重程度与优先级

  在游戏测试的行业当中，会有许许多多的Bug，自然和软件测试一样少不了严重程度以及优先级的划分，对于Bug的严重程度通常而言划分为5个等级。

3.1严重程度等级划分

  （1）致命级：服务器宕机，无响应、客户端闪退，崩溃，核心内容阻塞，涉及高价值商业营收等金钱类计算内容、数据兼容错误等。

  （2）严重级：严重的功能错误、功能与策划案有严重出入，系统或模块中的重要功能失效、无响应等

  （3）一般级：普通的功能错误，功能与策划案有较小出入，影响面较小的问题，明显UI问题等

  （4）轻微级：轻微的UI问题、文本错误，色彩搭配违和等

  （5）建议级：某系统、玩法或者某一条需求上的易用性及建议性问题

3.2优先级划分

  （1）紧急：该问题需要立刻解决，问题需要立刻得到修复响应，关系到系统运作、收入等

  （2）高级：该问题急需解决，该问题的修复很有必要，应引起高度重视，关系到该系统的主要功能是否正确实现等

  （3）中级：该问题正常处理，问题未过于影响功能实现或与需求有明显出入，系统功能与需求有较小偏差

  （4）低级：该问题考虑时间可尝试性处理，问题不紧急，可延期、可后续关注，经确认与评估可不解决。

  （4）无关紧要：该问题几乎不涉及影响面，对于体验或需求而言微不足道，在空闲时关注

  值得一提的是，通常情况下优先级与严重等级相对应，但有时严重级别高，优先级不一定高，一些严重级别低的，优先级高的，反而要优先处理。

  例如：某款新手游即将在国庆期间上线，本意为国庆活动，活动的文案写成了11月1日-11月10日充值258元可以获得1次抽奖机会，100%抽奖获得实物活动。这种问题隶属于低级或中级，但它的优先级却是高级的，会影响到上线后众多玩家活动的参与、准备等内容，会直接或间接造成营收损失。

  例如：某款手游的登录界面的登录按钮偏移了，没有处于居中位置，它的严重级别定义为中级或低级，但优先级会定义为高级，可能按钮只有一点偏移或者有较为明显的偏移，但该问题影响的用户广泛（每一个玩家想玩这款游戏，就必须会经过登录界面），意味着这将影响到所有的游戏玩家，那也是需要引起高度重视的问题。

  例如：某款手游出现了客户端闪退的致命问题，但平均有10万名玩家才可出现一次或半年都没有第二次出现，该问题的定义为致命，但优先级会定位中级或低级。

  看到这里，大家也应该能够理解了，其实严重程度我们通常会按照问题去定义它的严重程度，但优先级我们主要是通过出现频率、时间、影响面去做定义的。

四、Bug修复的代价  Bug的修复代价与我们所处的条件息息相关，通常而言分为研发期间以及游戏上线，在各个所处场景下也分各种条件，具体如下图1-3所示

草帽路飞UU

五、Bug的生命周期     Bug与游戏、软件一样，也存在生命周期，Bug生命周期如下图1-4所示：

六、如何预防Bug的产生
    6.1认真对待需求评审 

  需求评审阶段应该做些什么？ 

（1）熟悉该需求相关内容，提前考虑到需求风险，及时反馈需求风险，让开发人员在研发过程中注意，避免产生更多的Bug

（2）分析需求漏洞，及时反馈设计缺陷，需求评审会议时可以立刻修改策划案或会议后修改，避免研发后大量修改或重做

（3）在三方人员对于需求看法的讨论过程中大致确认部分需求的负责人，更加明确处理人，方便后续提单

（4）在评审讨论的过程中通过开发人员、策划所描述的逻辑以及实现方式，考虑可能会出现的代码逻辑漏洞以及配置漏洞

（5）对于需求中存在疑问的地方及时提出，让策划方解答问题，为后续的测试用例编写以及测试做准备

（6）可以帮助策划提供一些需求上的建议内容、以及后续的优化，分析玩家群定位，也可以避免研发需求后大量修改或重做

（7）根据讨论的各类要素判定，从测试用例的编写以及测试流程的结束所使用的测试时长，以把控需求风险及测试质量

 很多测试人员认为需求评审只是简单的过一下需求，让测试人员大概了解接下来要做什么内容，应该如何准备，但其实远远不止如此，认真的对待需求评审，就可以在需求质量上“更胜一筹”，如果每个人都可以认真对待需求评审，测试质量以及测试效率就会大幅提高，让我们的游戏产品赢在“起跑线”上！
6.2认真对待用例评审 

  测试用例评审阶段应该做些什么？ 

用例评审前：

（1）认真梳理自行编写的测试用例，以准备测试用例评审，可以让参会人员在评审过程中思路更加清晰、明了。

（2）三方测试用例评审前（开发、测试、策划），应当先行进行测试内部评审，内部评审后用例会相对未评审时更全面，也许可以通过补充的测试点当中联想到更多的测试点并进行补充，以节省在三方评审会议的时间。

PS：标准的评审流程应当包括开发、测试、策划、美术等，但应至少包括上述所提及的三方。
用例评审时：

（1）先行向评审参会人员讲解用例编写的结构与框架，让大家清楚用例的基础结构，便于在接下来的讲解时能让大家快速进入状态聆听评审。（通常只适应于系统或玩法，优化类需求无需讲解）

（2）测试人员讲解自行所编写的测试用例时应当在这个过程中重点提及异常点、风险点的测试用例点，以补充可能在需求评审时漏掉的风险，开发、策划可以通过测试人员用例编写所提及的内容及时修复程序漏洞或配置漏洞。

（3）测试人员讲解用例时应当主动告知开发、策划等参会人员该系统可能存在的一些风险点、异常点，让大家提前预警，有心理准备。

（4）测试人员在评审过程中针对其他人员所提及的用例内容，及时记录或现场补充。

用例评审后：

（1）测试人员根据会议时的评审内容及时补充测试用例，完善测试用例。

（2）在测试过程中发现了Bug但确是用例中没有编写的用例点，应当及时补充至测试用例。

（3）当测试用例足够完善且有空闲时间时重新梳理测试用例，以便其他人更好的阅读理解，提高执行效率等。

（4）及时对测试用例进行维护，根据公司的项目以及管理工具，及时上传测试用例，对用例进行备份，以防丢失。

       用例评审与需求评审同样重要，测试人员对于测试用例的维护也很有必要，在测试过程中、后续测试等，均会有更高的工作效率，也会提高其他测试同学交叉测试时对于测试用例的理解、如果有新人入职时也会有更好的上手空间，对外而言会显得测试组内的基础水平扎实，表明我们的专业能力。

6.3依赖技术人员因素       

      为何依赖技术人员因素？ 

       正所谓人无完人，无论是开发、测试、还是策划，人的能力总是有限的，随着技术水平、工作年限、学习能力以及项目熟悉程度的各种因素影响，技术水平也会有所起伏，以测试举例，如果测试人员的基础功底不扎实或者没有做到足够的严谨，在外网上可能就会有Bug产生，当然了，谁又能保证自己所测试的内容是100%的完美呢？我们做不到完美，但可以无限接近于完美，开发与策划也是如此，不断提升自身的能力以及项目的理解程度，自然而然我们就会拥有更好的产品质量。

6.4测试应当尽早介入

  为何测试需要尽早介入？ 

  测试的尽早介入，是ISTQB中提倡的一个基本原则，游戏测试人员与软测人员大同小异，测试人员提前介入主要有以下几个优点：

（1）提高游戏测试中产品的测试质量

（2）提前发现需求设计缺陷以及开发风险，降低成本

（3）测试人员的提前介入可以加快测试进度以及项目进度的推动

（4）测试人员的介入可以提前给予建议性优化等内容以进行过程改进。

6.5熟悉游戏各类机制

  为何需要熟悉游戏的各类机制？ 

  在游戏测试的行业中与软件测试不同，游戏中各类模块、系统之中或多或少都会存在着些许牵连，以和平精英为例，玩家使用枪械射击敌方时敌方也会受击并扣除一定的血量，如果对方有防弹衣时那么就会存在一些交互，即枪械伤害与防弹衣防御的公式计算，那么测试枪械伤害的测试同学不仅仅要考虑到枪械本身的射击伤害，当然也需要考虑在敌方拥有不同等级防弹衣时受到的伤害，模块与模块或系统与系统之间的牵连测试，我们也称之为集成测试。

  在游戏测试的行业领域中，存在着太多的集成测试，无论是什么类型的游戏，都会存在集成测试，存在这些机制的同时，对技术人员更是一种考验，无论是开发、测试、策划、美术，都需要了解一定的游戏机制，当对于游戏有着一定程度的理解和熟悉程度时自然可以规避一些不必要的风险，从而预防Bug的产生。

  看到这里你是否已经知道了什么是Bug，且也清楚如何更好避免Bug产生的方式了呢？相信阅读此文章过后的你无论是从事游戏测试还是软件测试，都会对基础知识或多或少有进一步的了解啦~

七、知识小课堂

  问题一：我们公司的测试部门是按照提交Bug的数量以及严重程度来计算KPI的，如果我在需求评审阶段就告知开发让他们修复Bug，这样我的业绩可能就少了，我该如何做？

  答： 即使公司有KPI标准，我们也应当在需求评审阶段中提出相应的风险以及设计缺陷，告知策划以及开发，让他们提前避免。 无论是功能、性能、自动化测试，更多的价值并不是明面上的Bug，而是其他人没有发现，你却能发现的问题， 这可以充分的体现出你的能力，如果能发现一些其他测试、开发从来没有听说过的Bug，抛开测试部门不说，其他部门的同学一定会对你刮目相看。

  问题二：如果项目有紧急的优化或代码层次改动，且改动层次较大，来不及进行三方用例评审该如何应对？

  答： 有时候负责的系统、模块有紧急情况需要修改内容或新增内容，我们也需要进行用例评审，我们可以先行提供测试用例给到组内成员评审，在评审的过程中同时也进行测试用例的执行，当测试用例执行完成时，再通过测试组成员所提供的评审结果补充测试点进行测试，在执行测试的过程中也可以直接让大家进行风险评估，提供可能出现的异常点，简单梳理后执行测试，既节省时间又能达到效率。在度过紧急阶段后，应当重新完善用例，组织三方评审会议重新评估风险点，以更全面的保证游戏质量。

  问题三：如果用例不全面未测试到，在外网出现了Bug，应当如何应对？

  答： 当外网有Bug产生时应当先行判断该Bug的严重程度、影响面等内容，来综合判断该问题的优先级，根据该Bug的优先级选择对应的处理方式，如果有多条Bug出现，应按照优先级进行修复，在发现Bug直至修复发布的整个过程中，我们更值得注意，整个流程是为了解决问题，不应掺杂负面情绪或指责。

  问题四：我是新入职公司参与项目的技术人员，对于游戏的各方面都还不熟悉，我应当如何熟悉项目尽可能防止Bug的产生？

  答： 如果是开发人员熟悉游戏可以通过代码熟悉来了解游戏，测试人员可以通过测试用例来进行了解，策划可以通过配置表以及竞品来熟悉游戏，无论你的工种，都可以通过体验产品来熟悉游戏，多体验，多了解游戏中的逻辑，就可以更好的防止Bug的产生，开发可以在编码上有更多的考虑，测试可以考虑到更多的异常点以及测试点，策划也可以更加熟练的进行配置表配置等