2007年测试经验总结之BUG的发现

2007年度测试经验总结51Testing软件测试网 @:H1k,v?(Y

BUG的发现51Testing软件测试网6^j`c4Q$Y,AW4E

分离和再现软件缺陷

BUG出现的时候，一定是在某些操作下、某些条件、某个环境下（暂时统称为条件）所产生出来的。把这些条件从复杂的环境中分离出来。那么怎么进行分离呢？就是找出不重现和重现所有操作步骤和条件的所有不同之处，考虑的越全面越好。然后针对这些不同之处，进行一一排除，让不重现的执行测试用例过程越来越接近可重现的执行用例过程。直到因为某个条件的不同，而导致重现或不重现，那么这个条件就是关键点。在描述BUG的时候，加上这个条件，说明这个条件的变化会影响到BUG的出现或不出现。开发人员方便定位问题。

一般来说，确定BUG的时候，会验证2遍以上，才会去告知开发人员或写进BUG管理器中，所以测试人员提出的每一个BUG都是经过多次确定后才会提交的。当软件的BUG越多时，反复确认问题的测试时间相应的也会增加很多，所以测试时间并不比开发时间短。51Testing软件测试网V%q~ F9r5_

《软件测试》书中18.2节是有关于分离和再现软件缺陷的论述，可以经常拿出来研究研究。51Testing软件测试网,g$@i\A

不要完全跟着开发人员的思路测试，BUG往往出现在他没有想到的地方

开发没有自测到的功能,往往是BUG最有可能出现的地方,所以测试人员要测试他们所没有测到的地方,这些地方也许是由于麻烦而没有被自测到,也许是开发人员对这块功能的影响没有想到,测试人员都要重点测试.测试人员就应该保持这种怀疑精神去测试,不要跟随开发人员的设计思路思考(当然你首先得理解它的设计),而要想象出其他更多的情况,因为正常情况下，开发人员能想到的都已经自测过了(除非测试很麻烦或没有时间自测),多多善用你的大脑,挖掘更多新奇的别人想不到的可能输入的条件,这样更能发现严重级别高的BUG.

这里有个例子，有一次的测试任务中只是测试1个功能点，3个测试用例。其中1个测试用例是这次的测试重点，也是修改的内容，所以这个测试用例通过，没有发现问题，但另1个非关键测试用例却发现了一个BUG，而这个BUG的重现步骤是开发人员没有预料到的。老实说，这个BUG的重现步骤也是我经过1个小时的反复尝试，让操作步骤和条件不断变化后，进行分离后才确定下来的，因为执行一次测试用例，就需要间隔15分钟进行一次。终于在执行4次测试用例后，找出了重新该BUG的所有步骤和条件。51Testing软件测试网v{!uXk|#g.S:`

发现了问题，开发人员给的理由是合情合理的，就可以接受

有时候，我很容易被开发人员说服，当然前提是开发人员给我的解释是合情合理的，比如说今天发现一个设计上的缺陷，如果按照开发人员的设计方法，有种情况发生时，会出现某种缺陷，这种情况发生的可能性并不高（不会超过1%），实际上我不能肯定可能性有百分之多少，而且一旦这种情况发生了，缺陷的严重性也并不高，加上开发人员认为没有比这个更好的实现方法，这种设计方法是最适合而且是最容易的，所以，我被开发人员说服了。当然，该缺陷还是被真实的记录进TD中。51Testing软件测试网_dTvp

 51Testing软件测试网1Q2SIEpx zLD!k\
hr

尝试自己定位问题产生的原因

我个人认为做测试，还是要把BUG的产生原因、开发人员是怎么修改的这两个问题弄个清楚明白才好，比如说今天下午，开发修改了1个BUG，但是这个BUG并不是每次都能重现，但开发人员一定明白什么原因导致的，所以如果这个时候不去问开发人员，就只有自己看代码哪个地方被修改了，然后思考为什么被修改，就能想明白为什么之前会出现BUG了。这样回归测试也有了目的性。回归测试的范围也有依据。51Testing软件测试网q@FR'FGfOx C6B

不管这个问题最后是不是能被确定是BUG，只要出现，就有去寻找原因的价值，有一次，出现了这样的一种情况，测试过程中发现一个程序出现了一个错误的结果，但不能确定这个错误什么情况下产生的，于是为了再次确定这个错误，又重新执行了一遍，结果和前一次出现一样的错误，这次能确定在什么步骤之后产生了什么错误，于是我能很肯定的对开发人员较好的描述这个BUG，开发人员想了一想，然后看了看后台某个配置文件，最后他告诉我，是因为另外有个功能导致了结果在预料外，于是他修改了一个配置文件，让我再测试一遍，第三次测试后，果然没有再出现这个错误。虽然最后确定这个问题不是BUG，而且也增多了不必要的测试工作量，但我感觉到还是很值得的。这种情况的出现，我是没办法避免的，只有开发人员先发现这个功能可能会影响到我的测试结果，早点改好环境，也就可以避免这种情况出现了。事出必有因，我始终坚信着，发现问题时，即使不是BUG，也可能是一个你不了解但应该掌握的原因产生的，所以耐心的多次尝试然后确定问题并且对开发人员清楚的描述问题的表象，让开发人员确定问题的实质。

有些BUG的原因不必深究,能理解大概意思就行了,毕竟还有很多其他更重要的事情需要去做.

 51Testing软件测试网I2s4R"]Hz

发现BUG过程中的乐趣

测试时间越多,我就测试的更深入更仔细,并能发现越多的BUG出来.测试的其中一个乐趣是,从感觉到奇怪现象开始,到找到问题根本原因并把原因/过程/结果整个串联起来的一瞬间,那种感觉真的太好了,仿佛在玩侦探游戏.51Testing软件测试网EwS(ii8aYL

 51Testing软件测试网k5QC6kR/j"i

对BUG进行总结

BUG从来没有总结过，以后发现的BUG进行规律的总结，以便以后的错误推断测试。（目前还没有做到，希望以后能养成总结BUG的习惯）

 51Testing软件测试网:n'G7^9{aDA/YkOj

分析漏测原因

每次的漏测，都能让我印象深刻，当漏测出现后，我会去分析为什么没有发现这个BUG？是测试用例考虑的不全？还是输出结果的检查不够细心和全面？经过分析和总结后，找出下次能发现同样类型BUG的方法，改进自己的测试用例设计模版，在当前的测试用例文档中写出漏测分析。所以，对我来说，每次漏测分析都是一次测试经验、都是一次提高测试能力的机会。51Testing软件测试网0RO4[p!y*c3[B