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