理论上，所有的软件 bug 都有其必然发生的路径，之所以我们称有些 bug 为偶发，究其原因是其发生的条件多，路径复杂，场景并不多见，测试人员难于发现。但，此类 bug 的场景一旦触发，往往风险很大，会涉及人的生命安全或财产严重损失等。
实际工作中，相信每个测试人员都或多或少遇到过它们，这些既让你爱，又让你恨的偶发 bug。爱是因为觉得自己运气好，无意之中发现了一个很有价值的 bug，恨是因为操作了 N 遍，但你依然无法抓住它。甚至，有可能给你带来一场恶梦。
一天， 在某公司的饭堂，一名叫老 K 的资深测试开发工程师，发现同事小 May 坐在一张凳子上，一边吃一边目光呆滞地望向窗外，深度郁闷的样子，于是走过去。
老 K：小 May,怎么啦，好像有事？
小 May：是啊，还不是因为那个后果可能很严重的 bug,反反复复操作了一天，累死宝宝了，但我还是没有重现；
老 K：什么样的现象。
小 May：机器人在进样器上抓取病人样本时，某种条件下会误抓，导致仪器测量结果错乱。
老 K：至今为止，出现几次了。
小 May：2 次。
老 K：开发人员已定位到问题了吗。
小 May：没有，就是因为没有，才让我郁闷。昨天曾重现过一次，但开发人员看了现场后没找到原因，而今天，我则压根没有重现出来。可是，主管安排我需要继续去重现 bug。这种问题就像大海捞针，太难了，这样配合开发人员，也太浪费我们的时间了。
老 K：是啊，偶发问题，条件复杂，靠测试人员手工反复操作重现问题，很难碰上。开发人员是否有提出增加什么方法，可以加快复现。
小 May：无助地摇摇头说，没有。看那开发人员的样子，他还是一头雾水，毫无头绪。
老 K：我们团队前些时间开发了一个专门跟踪测试人员执行软件过程的记录跟踪器，原理就是把测试人员在被测软件上实施的所有操作，按一定格式记录，并保存在文件中。只要测试人员记得问题发生的大约时间点，我们通过时间戳，则可以分析当时软件的运行轨迹，从而方便问题的分析与定位，现在团队成员每个人都在用。
小 May:是一个好方法，工具可以分享给我们用吗。
老 K：我们这套工具是运行在 windows 平台上的，你们的产品系统是 Linux 平台的吧。
小 May:是 Linux 平台。
老 K：不过 ，在 Linux 平台上，应也有类似的工具软件，例如 History 命令工具，建议你跟开发人员沟通，把你的需求提出来，或许他们并没有考虑到这一点。
过了 2 天，小 May 遇到老 K，说跟开发人员沟通过了并把此事很快推动起来。现在通过抓起测试人员的操作日志，开发人员在小 May 第 3 次重现 bug 时，终于通过操作日志的上下文，开发人员找到几处可能的原因了。
再过了一段时间，老 K 遇到小 May，问及日志工具的应用情况。小 May 说，那个机器人拿错样本的 bug 已解决了，开发人员还说 “好在有了测试的操作日志，为跟踪问题找到了突破口”。
小 May 继续说：现在，在我们产品线，各项目中正在应用此日志工具。其实，这正是测试大数据的应用场景之一啊。
老 K：使劲点头，并笑着说 “是，是，是，大数据其实没那么玄糊,软件运行过程中留下的数据能为我们所用，并发挥价值才重要。”
-- END --