偶然性不可重现BUG怎么处理?

一、一定要提交!!

1. 记得有这么个缺陷,以后再遇到的时候可能就会了解发生的原因。
2. 尽力去查找出错的原因,比如有什么特别的操作,或者一些操作环境等。
3. 程序员对程序比测试人员熟悉的多,也许你提交了,即使无法重现,程序员也会了解问题所在。
4. 无法重现的问题再次出现后,可以直接叫程序员来看看问题。
5. 记录bug要尽量描述清楚发生问题时的测试步骤、测试环境、测试数据。

二、尽量重现bug

对于整个项目或者产品而言,如果这些不可复现的Bug是很严重的Bug,比如导致系统崩溃等,如果不能及时、准确的定位和解决,最终发布出来的软件到达用户手中后,一旦出现势必会影响软件在用户心中的形象,严重的会“迫使”用户选择竞争对手的产品,这些显然都是公司所不愿看到的。而对于测试人员而言,出现了这些不可复现的Bug,实际上是一次很好的锻炼和提高机会,如果只是提交缺陷报告将这个大皮球踢给开发人员,不仅丧失了一次提高测试水平的机会,还有可能破坏和开发人员之间的关系。
要想复现不可复现的Bug,需要先提到一个概念就是ET(Exploring Test),也就是探索式测试,这种测试方法是由James Bach首先提出来的,在所掌握的被测对象的信息不是很充分的情况下,这是一种很有效的测试方法.当出现不可复现的Bug时,大家可以从以下五个方面来进行考虑:
1、被测对象的版本信息
我测试的到底是哪个版本,这主要是有两个作用:一是确认我测试的是正式的软件版本,如果不是就先记录下该问题,然后选择正式的版本进行测试(开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug);二是可以和其它版本进行对比,如果其它的版本没有类似的问题,就可以去对比这两个版本之间的区别。
2、环境
这里的环境是指出现不可复现的Bug时所对应的测试环境等,比如测试所用的计算机,如果出现不可复现的Bug,那我换一台机器是不是还会出现类似的问题,也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
3、模式
这里的模式是指我对这个Bug如何出现的一个理解,先给这个Bug设定一个模式,比如是不是[数据库](javascript:;)通信中断,然后再进行测试,收集更多的信息去修改和完善这个模式,这样不断进行,最终直到Bug能完全复现为止,这个时候只要使用这个模式就可以复现出Bug了。
4、人
这里提到的人有两个含义:一是测试是由人来进行的,人的操作、人的思维方式会有不同,通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹;二是想复现不可复现的Bug,往往需要多个人之间的相互协作,比如测试人员、开发人员等,通过大家的沟通和协作就能更容易去复现了。
5、测试工具
通过一些debug工具或者log工具等搜集内存等信息,根据这些信息来进行分析,找出不同信息之间的共同点,比如某一块内存始终都会被改写等,通过这种方式来去复现Bug。
上面的五个方面都是和ET的思想紧密相关的,通过不断的测试和不断的信息收集和分析,逐步的把模糊的、不确定的测试变成清晰的、确定的测试,这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。

三、实在没办法重现

问题无法重现,也要提出,程序员那里可以回复无法再现。问题放在那里,等到再次出现的时候,就立刻叫程序员过来查看。

实在没有再次出现,最后可以写到报告中,说出现了什么现象,但无法再现(比较严重的问题才如此处理,小问题经理之间商量商量可能就算了)。

你可能感兴趣的:(偶然性不可重现BUG怎么处理?)