不可重现的Bug？
对于客户或者前端的实施人员来说，再没有比听到测试或者开发说“这个问题是不可重现的”更令人丧气的话了。不可重现，成了拖延、搁置、忽略甚至拉锯和愤怒的代名词，严重地影响了项目及团队。但有时候这种普遍的不负责的回答，就像一个医生说这个病人没有病症或者找不到病因一样。明明病人很痛苦，为什么找不到呢？中医大家指出，这是理论不扎实、辩证不仔细的结果。所谓不可重现的bug，与之相类。
一般商业应用和计算机基础中的算法特征是确切的输出，即使加入了随机的因素，这种随机行为也是确切的。似乎毫无规律的异常，在满足种种条件下，必然导致确定的异常结果。因此对于异常的追踪和分析，很大程度上是对情景的再现。这种再现的复杂，导致了开发、测试往往采取鸵鸟策略。因此，常见的对所谓不可重现的bug，其态度常常有：驳回，不认可；拖延，不解决；侥幸，假解决。
但高明的医生总能从千头万绪的蛛丝马迹中总结出病机所在。因此，测试人员在针对所谓不可重现的bug进行诊断时，如果能详细地分析当时环境下的每个具体参数、配置、环境、操作程序与方法等等细节，就会发现其实大部分都是能重现的。当然，从机械宇宙与量子力学的理论上，如果所有条件都是决定的，那么结果也是必然的，也就是说，100%的重现，但人类的认识离不开假定，这超出了人类的认识能力范围。从这方面来说，我们能重现大部分问题，也就很满足了。
所以，解决不可重现的bug问题，首先在于对环境（场景）的重现，必须有足够详细的描述和细节提供，在此基础上排除一部分问题使之重现，然后则是一系列的测试方法，走查，自动化测试工具的应用等。在人员安排上，尽量交叉测试，避免惯性思维。在确定的一个局部问题模块如果发现不了具体的原因或代价太大，则可考虑换人重新开发这个模块。
具体的管理上，首先则是对人员素养的养成，良好的质量素养能避免大部分所谓不可重现的问题——这些问题往往出现在不引人注意的主算法之外。强化质量控制，问题的记录及状态管理尤为重要。对于开发或测试常见的三种态度：驳回——提供详细的现场证据及可能原因的分析，使之不因惧怕而在心中直接拒绝；拖延——明确解决计划，测试计划，在比较完备的测试计划执行后仍不能发现问题，定义一种退出策略，评估影响，在何种条件下可以暂时搁置或者关闭，待重现时重新打开，或者重新开发局部模块；侥幸——明确制止这种行为，拒绝未经处理的假解决，重现打开问题，进行前两种策略的循环。
