测试：快来看看，我发现bug了，这怎么回事？
　　开发：来了来了……哪里？
　　测试：嗯？怎么没了？
　　开发：下次看清楚点再说。
　　……片刻……
　　测试：现在出现了，快来看看！
　　开发：好，马上过去……哪？
　　测试：怎么又没了！
　　开发：……

　　这种情况我以前遇到太多次了，写过程序的人都有这个体会，有些bug的出现机会是非常非常宝贵的，因为程序运行总是带有很大的随机性，也许这个bug在某个时间才会被触发，或者根本就是低概率随机，特别是用C++写的程序，这种问题尤其多，当然随着我经验的不断上升，我以前曾经写出过的bug，现在是越来越少了，我知道如何从代码这个层面上避免出现这种问题，（这个不在本文讨论之列）但即便如此，我也难保证到了测试人员手里一定不出现。反应测试人员水平的还有一个重要指标：就是重现bug的能力。水平高的测试人员能很好地记录bug出现地条件，就好像每次空难的时候，黑匣子总是能很好地帮助事后处理人员找出空难当时的飞机运行情况以及环境参数，以此推测，为什么会出事。如果真的是一个很难重现的bug，就像前面说的，根本就是低概率随机的，那怎么办？那就想办法把bug描述清楚，以截图的形式记录出错现象，用清晰简要的文字，描述清楚当时的运行情况，这是测试人员该做的事情，而不是bug“跑过去就没了”。有些问题确实很难发现，甚至解决了都不知道其所以，我最近写了一个程序，这个程序会加载若干个模块，从模块中调出资源，将资源存入内存中，按道理，这个时候我可以卸载模块了，因为我要的资源已经到位了，接下去我要使用这些资源，就是把它们转变为流，再去调用别的接口，但出现问题了，在加载/卸载若干次之后，Allways出现一个错误，通过调试，这个错误发生在CreateWindow这个Windows API的内部，如果从表面上看，这已经是超出了我的能力范畴，但我知道，这仅仅是表面，其实质一定是在调用到CreateWindow之前，就出现了内存越界之类的错误，但我细心测试了我的程序，所有可能出错的地方都排除了，我的代码既没有越界，也没有泄漏，但问题最后还是解决了，很简单，就是把卸载模块这行代码，挪到使用完内存中的资源之后，就没再出现过这个问题，按照逻辑，我一直想不通为什么会这样，我使用的资源是已经调入我的程序动态分配的内存空间中了，应该跟模块没有什么联系了，可经过大量的测试，发现这么改之后就没再出现过问题，我知道我还是没法完全理解这个复杂的系统，尽管我尽了最大努力。测试人员也是这样的，不能重现所有bug，但他们可以尽量去记录bug发生的各种情况，对于修正bug的开发人员来说，当然是越详细的信息越好。

　　“你相不相信我的测试结果？你的程序在所有使用华硕主板的机器上会死掉，其它的就没事。”

　　相信不？不相信？亲眼看看后，我还真的相信了，但一直不知道原因，这个问题确实是我曾经遇到过的问题，也是我遇到过的所有问题中最怪的问题之一，这还真的被一个测试者“总结”了出来，对他来说，能总结出这个问题，非常不容易，为了验证是否的确如此，我还找了一台华硕的笔记本电脑来测试，还真的如此！我也很想知道原因，可我现在还是不知道，而我离开那家公司很久了，我也许之后也永远不知道了，我说这个例子，目的是想告诉大家，有时候真的没有什么“不可能”，所以请不要随便怀疑测试人员总结出来的那些稀奇古怪的bug，表面上的一个bug，也许可以牵扯到非常深层次的问题。

　　我也不知道再谈点什么好，测试工具，测试流程，这些我想别的地方讲得太多了，但，软件业有一条黄金法则，那就是“没有银弹”，再好的测试工具，再精密严谨的流程，最终都是人在使用，人在执行，没有一种足够强大的工具来完全替代开发人员的工作，对于测试人员来说，也是这样的！除了对工具的引进，流程的改进，更应该重视人员自身能力的提高，我想这也不光是软件行业了。