游戏中难以复现bug的探究

       测试人员都会遇到一时难以复现的bug，而游戏因为其千变万化吸引了众多玩家的同时，也给测试人员提出了更高的要求，尤其是面对这些难以复现的bug。

      笔者所在的项目刚刚做了一轮版本对外测试，主要内容是新手教学关卡。在这次的版本测试中，QA发现了几个难以复现的bug，这几个bug，有最终被复现出来的，也有没有被复现出来的。但不管怎么样，都给团队带来了些许不安的情绪，万幸的是，在最后的对外测试中，都没有在玩家层面出现这些不可复现的bug。

      那么为什么会出现难以复现的bug呢？

      最大的原因就是：测试人员对被测物的了解还不够深入。不可复现bug的原因大致可以分为下面5类：

      1：环境的变更造成了bug难以重现。手游的话，比如手机型号不一样、网络情况不一致等；端游的话，比如操作系统不一样，杀毒软件开启不一致等。

      2：没有找到真正引发bug的操作。这些操作往往是一些不怎么显而易见的操作，测试人员在不经意间完成，而又忽略了这一操作，以致难于重现bug。

      3：没有找到真正会引发bug的操作序列。很多bug的重现需要满足多个条件。在满足多个条件的状态下，你做了对应的操作，bug才会被触发。

      4：bug必须使用特殊的数据才会出现，测试人员没有意识到他使用的数据的特殊性。

　　5：测试人员由于错误操作，出现了误报（这很常见）。比如，记得自己执行了step3，其实没有，或者没有正确执行step却觉得正确执行了。

      回头看我们的项目，对于不可复现的bug，几乎没有任何流程规定和工具辅助，既然已经发现了存在的问题，那么就去解决吧。这也是本文产生的原因。下面我将从流程和工具两个方面去探讨今后我们项目组对于不可复现bug的处理。

      1：流程方面

      对于测试人员而言，出现了不可复现的Bug，实际上是一次很好的锻炼和提高机会，如果只是提交缺陷报告将这个皮球踢给开发人员，不仅丧失了一次提高测试水平的机会，还有可能破坏和开发人员之间的关系。所以，我要求当发现不可复现的bug时，按照如下流程进行：

      首先一定要仔细观察和反思当这个不可复现bug发生时，自己进行了哪些操作，操作序列又是如何的，当下的测试环境是怎么样的。

      其次一定要详细记录。在Redmine单子上详细的记录你的操作步骤以及当时的环境情况，千万不要觉得只是一个不可复现的小问题，就没有进行记录。同时，在记录的时候，多使用截图、log等利于后期分析的内容。

      然后是 科学分析。bug难以重现有很大一部分原因是因为“没有找到真正引发bug的操作序列“。 但不管怎么样，分析的方法无非就是从环境、代码和数据三个方面去着手。当有一个QA发现不可重现bug的时候，可以号召其他QA一起来分析问题，人的思维方式会有不同，经过集体的严密推理和大胆假设，就有可能发现一些蛛丝马迹。同时，也可以叫上相关模块的开发人员一起参与进来，他们可以站在不一样的角度去看待问题和分析问题，通过大家的沟通和协作就能更容易去复现了。

      当然在分析的过程中，我们一定要善于去利用现有的资料，避免脱离信息的毫无章法的空想。这里提到的信息资料，可以包括客户端、服务端的log，先前操作的录像等。那么合理的采用一些工具来保存和展示这些信息是十分有必要的，它将帮助我们去复现这些bug。在后面的章节中，我将对这些工具有所介绍。

      最后，不得不承认，有时候对于不可重现的bug的解决，还需要一点儿运气。所以，记得平时多做善事，多请客。如果最后能复现这个bug，一定要记住回顾和检查目前的测试用例，看看是否需要更新！

      在每一个周版本或者月版本的回归测试中，我们都需要对剩余的不可重现的bug进行一次回顾和尝试，如果依然不能复现，那么就依次往以后版本中顺延，并且每轮测试时都要尝试再次复现。那何时可以关闭呢？也许3，5个版本发布后，没有出问题就可以决定关闭它了。这个没有明确的时间规定，看自己的把握，以及这个bug的严重程度。

      2：工具方面

      我觉得在周版本等重大版本回归的时候，录屏是一个很有效的手段，当出现难以复现的bug时，可以通过反复观察录像去定位bug发生的原因。在端游方面，录屏软件有很多，在这里我就不说明了，大家自行google一下就可以了。这里重点说下移动端录屏。

      1：有数据线连着手机

      这种情况下也是非常便捷的，比如iTool等工具都有现成的录屏功能，这里也不多说了。而且这也是今后我们项目组在周版本等重大版本回归的时候，推荐使用的方法。

      2：没有连接电脑的情况

      当我们在会议室进行集中测试等无法让手机连接电脑的情况下，怎么才能录屏呢？

      目前我们项目没有录屏的功能，如果我硬要实现一个录屏的功能，那必然得在目前的客户端中，添加相关第三方sdk，这其实就违背了我们测试的原则，对原有的系统造成了破坏。这是不推荐的。

      回顾项目，我发现还是存在一些相似的功能可以一定程度上替代录屏功能，帮助我们QA面对不可重现bug时定位。

      首先在我们游戏的pvp中，程序实现了基于RPC的录像回放功能，虽然相对于我们想要的录像功能存在两点缺陷：

      1：回放只能在对应的游戏客户端上进行

      2：回放没有ui层相关的显示

      但总比没有强，通过服务端保存的录像回收，当出现难以复现的bug的时候，还是给我们QA提供的很大程度的探索空间和思考方向。

      其次，在我们游戏中有一个截图的接口，虽然还没有在实际的玩法或者功能中运用，但至少是在代码层面存在这样的接口的。于是，通过和程序的协商，在这个接口上，增加了暴露给QA使用的参数，同时，自定义了开始截屏和停止截屏的功能，这样当我们在困难的环境中，如果依然想录像的话，可以通过客户端命令开启每隔N秒截图的功能。如果出现不可复现的bug，可以在一定程度上帮助我们去分析和定位。

      这里说下遇到的一个问题。unity的截屏方法一般有3种，第一种是CaptureScreenshot接口，但在移动平台上基本不用；第二种是通过读取屏幕缓存然后转化为Png图片进行截图，这方法的缺点是只能截屏整个屏幕，如果我们想要截取某一部分，比如除去UI层的截图，那么这个方法就不行了；第三种是RenderTexture来实现分层截图，这也是我们项目目前采取的截图方式，但目前在真机上发现，当执行ReadPixels方法的时候，会出现顿卡现象，查了很多资料，也尝试了几种解决方法，但都没有很好的效果。目前就这么将就的用着，如果有朋友有相关解决方案，多谢告之。

      3：log方面

      当出现bug的时候，查看log总是一个非常好的习惯和方法，对于难以复现的bug，log更是非常重要的存在。但目前，我们的服务器架设在linux上，log的显示和追踪不是非常方便，于是我们使用flask+websocket的方法，实现了将linux日志实时的、分类的展现在web页面中，并增加了可视化过滤、定时统计报警等功能。一定程度上对于bug，包括不可复现bug的定位起到的一些作用。

      以上就是这次对外测试过程中，我对于不可重现bug的一点思考和反馈，可能有些想法比较幼稚，希望可以和大家多多探讨。

本文来自网易实践者社区，经作者朱洁授权发布。