问题描述:对于测试来说最怕遇到的就是不可重现的严重级bug,在执行的不经意间出现了一个crash的bug,然后无论如何尝试都无法重现,当遇到这种问题时作为一个测试应该如何处理?
精彩答案:
会员 Christina_LL :
在软件测试中经常会出现很多偶尔出现的缺陷,也就是说不是100%的能复现,对于这样的缺陷,该怎么处理呢?
先看看能复现的缺陷的处理流程是什么样的,能复现的缺陷处理流程是:
(1)考虑到各方面的因素来判断缺陷的优先级别和严重级别:
(2)根据缺陷的优先级别决定什么时候fix这个缺陷-〉
(3)集成fix的代码-〉
(4)验证fix是否成功,并试图验证这个fix是否有负面影响。-〉
(5)Fix是成功的,没有负面影响或者负面影响在可接受范围内,那这个缺陷就可以close了;如果fix不成功,或者有严重的负面影响,需要考虑是否 rollback。
其实能复现的缺陷处理流程同样适用于处理偶尔出现的缺陷,只是具体的操作有些区别而已。
(1) 考虑到各方面的因素来判断缺陷的优先级别和严重级别:
首先判断严重级别:严重级别比较容易判断,和其他能复现的缺陷一样处理。
然后判断优先级别,就需要看对用户的影响。对于能复现的缺陷,我们能很容易的知道用户碰到这个缺陷的概率,也就能很容易的判断这个缺陷对用户的影响,那对于偶尔出现的缺陷,同样需要判断这个缺陷对用户的影响。判断优先级别除了考虑缺陷的严重级别,还需要知道这个缺陷能被复现的概率,这就需要去复现这个缺陷。一个偶尔出现的缺陷在有限的试图复现次数里,比如试图复现10次,可能无法成功复现,但是如果试图复现10000次,可能能成功复现20次。这就需要搜集大量的数据 ,来发现这个缺陷的复现概率。怎么搜集复现概率呢,有很多种方法,可以暂缓处理这个缺陷,看后来这个缺陷是否能出现,如果从项目初期到项目结束,这个缺陷就出现一次,那完全可以忽略这个缺陷;可以刻意的安排测试员复现这个缺陷,不断重复的去复现这个缺陷,这个时候如果有开发人员来分析哪些操作容易导致这个缺陷出现,测试人员通常更容易成功复现,测试人员最好把软件连着trace来试图复现缺陷,这样如果成功复现了,就拿到有效的信息来给开发人员分析;也可以在终端用户测试的时候,让终端用户测试人员注意有没有碰到这样的缺陷,终端用户测试能最真实的模仿实际用户的行为,如果几个月的终端用户测试都没有发现这个缺陷,那大可以放心的忽略这个缺陷;相反,如果终端用户测试里频繁碰到这个缺陷,那这个缺陷对用户的影响就很大,就需要被重视。
(2)根据缺陷的优先级别决定什么时候fix这个缺陷
这一步和常规的缺陷处理流程一样,就是开发人员去分析得到的有效信息,然后找相应的解决方案。不过需要提醒的是,通常偶尔出现的缺陷不是一个一个分析处理的,而是一批同类型的缺陷一块处理。通常会等到不可重现的缺陷积累到一定的量的时候再成批的处理。只所以这样处理,是因为如果不可重现的缺陷没有积累到一定的量,很难找出根本原因,因为每个偶尔出现的缺陷只能提供很少的一部分信息,信息量没有累计到一定的程度,就找不出根本的原因。
(3)集成fix的代码
这一步和常规的缺陷处理流程是一样的,但是管理者需要注意,很多时候同一段fix代码解决的可能是一批偶尔出现的缺陷,这些fix代码改动通常比较大,或者改变的是底层的数据,或者是内存管理的优化等,反正都是些疑难杂症,所以不适合在重要的软件,比如,Sales candidate,上集成这些fix。
(4)验证fix是否成功,并试图验证这个fix是否有负面影响。Fix是成功的,没有负面影响或者负面影响在可接受范围内,那这个缺陷就可以close 了;如果fix不成功,或者有严重的负面影响,需要考虑是否rollback。
对于能复现的缺陷,验证fix是否成功是件很容易的事情,但是对于偶尔出现的缺陷,验证fix是否成功是件相当难的事情,因为本身缺陷就是偶尔出现的,不能复现了也不能说明fix是成功的。这依然需要长期观察、安排测试人员集中测试、或者让终端用户测试人员多注意。有时候不可复现的缺陷并不能完全fix,可能一个fix只能降低复现的概率,将到能接受的范围也是可以的,比如对于一个通话过程中经常掉话的缺陷,把复现率从百分之一将到万分之一,也是可以接受的。
通常偶尔出现的缺陷不是一个一个处理的,一般是一批一批处理的,偶然的现象联系起来,让开发人员分析,通常能发现根本原因是什么,这样对于试图复现偶尔出现的缺陷、对于开发人员分析这些缺陷、对于测试人员验证这样的缺陷的效率提高,是有很大帮助的。处理这样的问题很重要的一点是,不能因为这个问题出现的概率低,就随意的的忽略这样的问题。