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官网客服哦