一、不能重现的bug该如何处理？

　　bug应该可重现，问题重现才可以让开发快速原因定位并解决问题。在测试的过程中偶尔会碰到一些不能重现的问题，对于这类型的问题应该：

　　1、首先，测试人员应该想办法重现，如果实在不行，也应该将bug产生的条件和出现的问题做一个记录，建议开发根据问题的描述来进行原因定位。当然了，即使开发解决了问题，如果不能重现，也不能有效地验证。

　　2、根据经验，一般的问题的产生都可以找到重现的规律的，只是看花的时间和成本。严重的bug一定要想办法找到原因，而优先级别低的问题可以考虑成本先将bug搁置，以后重现的时候再让开发解决。通常，不能很快找到规律的问题都是一些比较重要且奇怪的问题，开发一般不能根据描述进行定位，此时测试工程师应该有很强的责任心和信心想办法重现问题。

　　3、关于bug的重现，有一点非常重要的是，一定要开发人员与测试人员很好地配合，bug的重现效率才会更高，测试人员千万一个人不要闷头闷脑地在那冥思苦想，而应该及时把问题和看法与开发人员交流，毕竟程序是他们写的，大家一起探讨可以有效地促进问题的解决。复杂的问题并不是一个人就可以轻易就解决的，而是一个团队的结晶，要懂得充分利用团队的力量。

　　4、注意bug出现的时候的日志，通常程序日志都包含着很重要的信息，从那些信息中分析出现问题的条件，并尝试重现。

　　5、碰到问题时，应该尽量将出错信息作为关键字在互联网搜索，有可能别人也碰到了类似的问题并解决了，即使没有人解决过相同的问题，在互联网上也有很多资料，可以帮助你获取灵感。

　　6、必要时，写一些简单的测试程序来帮助重现问题。

　　下面我会讲一个在实际测试过程中不能重现的问题的解决方法与过程，可能这个问题对于刚入门的人来说有点难理解，不要紧，你不需要看明白问题的原因和代码，但需要学会这个复杂的问题的解决方法，并应用到实际的测试当中。

　　1、问题的描述：某短信发送模块出现core，但由于core信息紊乱不能定位到出错原因且无法重现导致core的规律。

　　2、问题重现过程：

　　（1）使用gdb对core原因进行追踪，发现core信息中含有的错误信息为：#0  0xff1c5a18 in _malloc_unlocked () from /lib/libc.so.1
　　#1  0xff1c57f0 in malloc () from /lib/libc.so.1

　　（2）以这两句core信息作为关键字在google上搜索，一些文章上类似问题的分析中获取经验，初步推断是由于内存溢出而产生的core

　　（3）将这些文章转发给开发负责人，并讨论可能导致的原因，开发从文章中获取灵感，写测试程序对推断进行测试

　　（4）同时测试人员详细分析程序运行日志，发现出现core之前，短信编码为平时少见的245，而短信的长度则是一个临界值140字节

　　（5）测试人员从程序运行日志中得到启发，发送一条短信编码为245且短信长度为140字节的短信，果然出现了相类似core

　　（6）开发人员分析根据测试结果分析导致core的原因： 调用sprintf打印短信内容的时候导致了内存溢出，而这样溢出会覆盖它后面的内存块的内存管理区域，在紧接着的malloc操作中就会发生段错误，从而导致了core的出现。

　　这个问题的原因，因为多人的参与，得到了准确的定位和解决，虽然原因是我最先发现的，但问题的准确定位和解决并不是归公到某个人，而是大家一起努力的结果，团队的结晶。

　　二、暂时无法解决的问题

　　在测试的过程中，开发可能会在bug回复的时候告诉你暂时无法解决该问题，这个时候作为测试的负责人，应该怎样处理呢？

　　1、首先，确实问题是否真的无法解决，解决需要付出的成本有多大。

　　2、其次，确认问题的严重性，如果此类问题不解决，是否会导致严重的后果。

　　3、对于会导致严重后果的问题，一定要坚持让开发解决，并且想办法帮助开发解决问题。测试人员应该主动协助开发人员找到问题的原因和解决方法，并充分利用团队的资源，请教对这个领域比较有经验的工程师，大家一起讨论问题的解决方法。