本文共 1170 字，大约阅读时间需要 3 分钟。

无论对于开发人员还是测试人员，遇到无法重现的bug都是一件极其苦恼的事情，为了逃避责任，各个部门之间会互相推脱，长时间无法解决也会给开发人员很大的压力，然而对于一个工程来说，无法重现的BUG往往是非常严重的问题，因为这种错误被发布到用户的机器上，小概率会被放大非常严重的事故，甚至会变成影响公司声誉的灾难事件。     我曾经看过一些测试人员在对待这类问题上的一些经验，比如如严格版本管理，杜绝个人操作错误，收集用户信息等，但对于开发者来说，处理这种问题却棘手的多，由于软件的复杂性，当程序发生异常的时候，往往离真正引起错误的位置已经相差很远，比如我经历的游戏项目增经遇到这样一个问题，玩家的程序运行一段时间后，会莫名其妙发现背包里的物品少了一个，然后再过一段时间之后程序会出现一个非法内存访问的异常而崩溃，通过分析dump文件发现，程序的一个模块在试图访问一块已经被释放的内存，然而这块内存是如何被操作的则无从查起，更糟糕的是，QA在内网根本无法重现这个这个错误，必须连接上外网正式服务器才会出现，而且必须运行很长时间后才会出现问题。     由于版本已经发布，玩家不断地投诉让老板黑着脸，已经发话让所有的开发人员必须解决完问题才能回家，经过一番折腾，终于发现原因，原来是一个程序员在改进“TransferItem”这个模块时(就是通过聊天信息传送物品)犯了一个愚蠢的错误，会把背包里不该删除的物品删除，留下一个野指针在那里，当别的模块访问背包时就会出现异常，由于跟所在场景的聊天信息量相关，所以只有在玩家接收到足够的聊天信息后才会发生异常，错误解决了，庆幸之余，我又在想，毕竟开发人员的能力参差不齐，我们可能无法杜绝这种错误的再次出现，那有没有方法能更快的发现这种错误呢。     其实我曾经设想过，如果把我们的程序能够基于一种“可重现”模型的话，问题就会容易的多。     什么是“可重现”模型呢，简单的说，我们的程序可以看作一个盒子，它接收的输入无非就是玩家的操作（鼠标，键盘），网络消息包，窗口消息等，如果我们能把这些输入都记录下来，是不是意味着我们就能够一模一样的重现任何问题呢？          然而，事实上并不是这么简单，我们的程序还会调用一些其他系统的函数，比如我们会调用Api获得系统时间，会调用C运行时库获得一个随机数，会调用DirectX接口渲染等，运行环境的不同也会使我们的程序走不同的逻辑代码，最简单的例子，程序运行在一台烂机器上会导致两帧之间时间差变大，而这个时间差会导致我们的程序在运行时行为不一致，甚至走不同的switch/case，这是个难解决的问题，但我们并非需要严格意义上的重现，大部分时候记录输入已经足够能帮助我们找到问题了，比如上面举的例子，当时我就是记录下所有接收到的网络消息，然后让逻辑顺序执行，结果重现了这个问题，才最终定位错误的根源的。  

转载地址：http://rjzvb.baihongyu.com/