软件测试工作中的常见难题及对策

　　软件测试工作中的常见难题及对策

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

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

原文转自：http://www.ltesting.net