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

4、  对于对系统不会造成危害的问题或虽然有微小的危害但修改成本过高而又可以人为避免，则可以将问题遗留到下一版本解决或关闭这个 bug ，并在 bug 报告中说明原因和注意事项。

5、  这个时候，测试人员的态度非常重要，在告诉开发这个问题一定需要解决的时候态度是温和的坚定，并让他意识到问题的严重性。试想想，如果你板着脸孔冷冰冰地丢给开发一句“这个问题一定要解决！”扭头就走，他会是怎样的反应呢？可以笑的时候就笑吧，大家都是工作，不要将工作的氛围搞得太僵，大家在一个和谐的环境中工作才会保持愉悦的心情。

6、  发现问题之后测试人员可能心里会嘀咕“反正这是开发的问题就让开发去折腾吧”，如果你一不小心这样想了，那就偷偷的想几秒钟好了，这个念头闪过之后，作为 bug 负责人的你怎么忍心看着开发一个人手忙脚乱呢？测试和开发其实是一个整体，在这个整体中的每个人都有责任去解决问题。

三、 测试工程师和开发工程师的意见不一致

1、  首先，客观地比较自己的建议和开发的意见哪个更好。

2、  如果开发的方法的确是比较优化，那就应该接受开发的意见；如果经过对比之后还是觉得自己的建议更好，那就坚持自己的建议，并详细给开发解释你的建议，通过对比两者之间的差别婉转地告诉开发你的建议值得采纳。

3、  如果双方还是对各自的意见相持不下，可以跟项目经理一起讨论，由项目经理衡量应该采取哪种处理方法。不过，有时候，项目经理也不一定站在你这边，你可能还需要花脑筋说服项目经理或被项目经理说服。

4、  当然，这个问题的讨论前提是问题值得花时间和精力去研究讨论，如果是一些比较简单或次要的问题，就没必要花那么长的时间去计较了，放过开发吧，也许他真的觉得这个问题没必要这样修改或者是他也修改到很累很烦了，这么简单的一个问题何不让开发轻松一下？

四、 开发工程师不配合工作

1、  先进行一个自我检讨：我的态度有问题吗？我报的 bug 是否都描述清楚了？我所发现的问题是否有价值？如果这些问题的答案是否定的，那么自己先改正了，开发会看大到你的改变，也会调整自己的态度的。

2、  在一个团队中有一、两个不合作的开发工程师是正常的，不可能每个人都那么配合那么好态度，也没必要自己觉得很难受，因为问题在于他的身上，你做对了自己该做的就行了。

3、  不要去逃避，双方之间换一种有效的沟通方法。比如，在 MSN 上交流不清楚，就换成电话或面对面，听到你愉快的声音或看到亲切的面孔，对双方之间的互动更加有帮助。但不要说着说着就火冒三仗，面红耳赤了哦！如果你也是火暴的脾气，面对面交流双方很容易争执起来，那么就通过 MSN 或邮件来交换意见吧！总之，交流的方式是很多的，选择双方更能有效沟通的交流渠道会达到事半功倍的效果。

4、  尽量避免与对方直接冲撞。人的自尊心都是很强的，学历越高或能力越强的人，通常自尊心也是越强，你尊重他他才会尊重你，说得通俗点，你给了他面子、给了他台阶，他才会给你面子给你台阶。即使双方之间发生了争执，也不要太过介怀，只是工作而已，大方点继续对他真诚的微笑。

5、  如果他实在不配合，必要的时候，可以适当表达你的立场，或者委婉地向他的领导反映或者将你们之间的交互邮件抄送给他的领导。这是一个有效的方法，但同时也是一个容易引发新的矛盾的方法，记住这样做是为了有效解决问题，而不是在别人背后“打小报告”。这是在工作，对事不对人。

在我的 team 中，有一个开发的态度非常不配合，不管是对我还是其它的测试人员。

五、 如何处理不能迅速定位的工程故障

对于一些不能迅速定位的工程故障，开发很自然 寄望于测试环境能将问题重现，如果能够轻易在测试环境重现，那肯定是一件好事，不过通常如果是一些简单的容易出现的问题，在测试的时候肯定就已经发现问题了；正是因为问题的复杂或者是一些测试时没有考虑过的问题，才遗留到工程上导致出现故障。

1、  查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找到问题的原因或相关线索。

2、  如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条件相同的测试案例测试，尝试在测试环境中将问题重现。

3、  如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维定势，想想为什么会出现这样的故障，可能导致的原因有那些，自己还有哪些测试点或异常没有考虑到，测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动 与开发负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。

4、  请工程实施人员将工程环境的配置文件和执行程序帮忙ftp到本地测试环境，在测试环境中使用实际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。

5、  在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境中将问题重现。

6、  问题重现后协助开发解决问题。

7、  验证解决后的程序是否仍然会出现类似故障。

8、  总结出现故障的原因并作记录，如果是配置的问题需要提醒工程人员在实施的时候注意，如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例，如果是某些异常开发没有考虑全面要总结类似的问题并提示所有开发注意。

下面是一个非常难定位的工程故障的实例，希望这个工程故障的解决方法和态度能够给你一些启示。

1、  问题描述：在某省某短信业务高峰期，实际处理的短信比接受到的短信少，也就是在系统处理某环节丢失了部分短信。

2、  问题进展：

A、 实际工程环境的日志没有任何错误提示

B、 相关模块的负责人进行代码白盒检查，也没办法从代码中看出缺陷

C、 测试环境没有出现工程所描述的故障

3、  问题解决：

A、  登录实际的工程环境，查看所有相关的程序日志，但程序的日志都正常，不能从中得到启示和帮助。

B、 根据推测可能的原因，在测试环境中试图使用大压力测试，但也没出现工程所描述的故障。

C、 与开发负责人、项目经理和工程人员讨论可能导致故障出现的原因，并根据讨论结果设计测试案例、测试方案。

D、 将工程实际环境的配置和执行文件拿到测试环境，并模拟工程环境搭建测试环境，发现其中配置存放短信的配置项比实际测试环境的大两倍。也就是：

; queue size, in byte, 20MB

QueueSize=20971520

; max ISMG queue length, 0 means no limit

MaxQueueLen=50000

E、 模拟出现故障时的业务压力，发现当发送队列 MaxQueueLen 超过了 46807 后，不会继续增大，永远不会到达 50000 ，也就是说永远不可能出现队列满的情况，模块永远不会报队列满的错误；所以系统只要接收到信息就往队列里放（只有该模块队列满或者连接不上等异常出现的时候才会存放到短信缓存器），而该模块共享队列最大只能存放 46807 条信息，多余的信息也便丢失了。

F、 建议开发人员修改程序，当短信存放超过了实际存放长度或配置长度，就提示错误并将短信存放到短信缓存器，确保短信在高峰期得到保障。

G、 给工程人员提供配置建议。共享队列大小、队列长度与网关连接个数之间的关系应该满足：对于共享队列大小为 QueueSize=20971520 ， MaxIQueueLen ，网关连接个数为之间的关系为：网关连接个数 *MaxQueueLen<=40000 。因此，若网关个数为 1 ，则 MaxQueueLen 的安全大小是 MaxQueueLen=40000 。

H、 开发人员修改程序之后验证问题：（ 1 ）、仍然保留 MaxQueueLen=50000 配置不变，压力测试，当短信发送队列 MaxQueueLen 超过了 46807 后，系统能够提示错误信息，并将短信缓存到短信缓存器。（ 2 ）、配置 MaxQueueLen=40000 ，压力测试，当短信发送队列 MaxQueueLen=40000 的时候，系统提示错误，并将短信存放到短信缓存器。

六、 资源不足该怎么办

1、  现有的资源是否能解决

2、  能否可以借用资源

3、  向领导反映并说明问题的严重性