关于bug我们作为游戏测试人员来说，要说的可就太多了。
bug的一生可简短概括为发现bug--提交bug--验证bug--关闭bug这4个阶段，在bug的不同阶段我们需要做的事情也不相同。
发现bug时我们要多问问一些问题，比如说发现的这个bug复现的必要条件是什么？除了发现bug的这条路径，有没有其它更多的路径也会导致相同的问题？bug是否存在可能影响其它数据或者模块的副作用？其它相似的模块是否也有这样的问题？在测试用例中是否有这个bug复现的路径，能不能有借鉴的作用？在自己问了这些问题之后对我们发现对发现其它模块的bug也有一定的借鉴作用，通过定位bug，我们不仅可以确认bug出现的必要途径，找到bug出现的原因，帮助开发定位问题，快速的解决bug；而且能帮助我们发现更多隐藏的bug,将bug出现的地方补充到我们的测试用例中去。
提交bug阶段当我们确认发现的问题是bug之后我们就需要把bug提交到bug管理系统中，bug单主要包括标题、前提条件、详细描述、重现步骤、期望结果、实际结果、截图等要素。
在提交bug时当然也有一些需要注意的地方。首先要确保我们所提交的bug是有效的，怎样判定是有效的呢？要确保不是因为环境问题引起的，也不是之前已经提交过的重复的bug。在提交bug的时候最重要的就是对bug的描述没有歧义、描述精准、步骤简洁 （如果有歧义的话不仅造成修复bug的效率较低，而且有时候开发修复的bug或许并不是我们所提交的bug）；对于复现率低的bug可以附上一些截图、可能的步骤、可能的原因；对于特殊场景的测试要附上相关的数据； 总之，截图加标识是非常直观的方式让策划或者开发意识到问题出现在哪里。我们给开发人员（服务端、客户端）和策划提供的细节越多则越有利于bug的快速解决，而且还有可能让他们对我们刮目相看。
在验证bug的阶段中，我们需要提前准备验证bug产生的环境和条件以便可以节约验证时间。在开发告知我们bug修复完成之后我们需要进行验证来确保是否真正的解决，在大多数情况下我们按照正常的步骤进行验证之后没问题就将关闭了。
在这段时间的工作中我发现如果仅仅按照这种方式进行回归验证的话并不能100%的确认bug已经修复了，因此我们需要一些方法来帮助我们进行回归验证bug。首先确认好复现bug的前提条件和操作步骤，我们还需要多问问开发bug产生的原因以及bug的解决方案，知道bug产生的原因之后我们可能触类旁通分析其它模块是否也有类似的问题；知道bug的原因进行积累经验开阔自己的测试思路；通过了解解决方案之后来确认这个bug的修复会不会引起其它的问题；
我个人认为了解原因和解决方案最关键的一点就是我们的经验得到积累，在后续发现发现相关问题时能够快速定位bug提供解决思路。这就是我们测试小白在向前辈问问题时，为什他们能够很快的给我们提供思路的原因，这是一个日渐积累的过程，需要不断的积累在知道原因和解决方案之后，要思考相关的模块确定回归的范围，确保修复的bug没有引起其它的问题。在游戏测试的过程中在每一次发现bug并了解原因的话可以快速增加我们工作的经验，知道那些功能容易出现bug。
在bug解决之后我们就需要在bug管理系统（常用的禅道和jira）中将bug关掉，bug关掉之后一个bug的周期就结束了。若我们提交的bug没有解决，那我们再告知开发让他们重新修改bug，再按照正常的流程进行验证。
提到bug就不得不说在已上线的版本中出现bug应该如何解决，人无完人，在测试过程中难免会出现bug未被发现的情况，未发现的bug流转到玩家手中并被玩家提及，则需要我们快速的解决并弥补过失。若遇到严重的bug，不仅要快速解决，而且还要对玩家进行补偿，因此我们在内网测试时要尽力发现所有bug。
线上版本的bug和内网测试时的bug解决有所不同，以下就是线上bug的热更流程。
对于游戏中热更bug的流程上图就包含的很清楚了，在我们实际的工作中可以对其进行参考使测试工作进行的更加顺畅。