如果一个bug是偶发的,怎么做回归测试?

rj_zj

RT,如果一个bug是偶发的,怎么做回归测试? 请求各位达人

[ 本帖最后由 luming 于 2009-2-21 14:16 编辑 ]

wyalgl

个人认为偶发bug如果光靠测试人员是不够的，偶发bug大多数都涉及到内存、数据库等方面，要和开发人员共同从代码方面入手，这样容易解决问题。

心10310

顶楼主一个   呵呵






















爱拼才会赢!!金山毒霸新蛋凡客欢乐斗地主杀毒软件

zcliucw

寻找规律

kelly_yan

1.严格按照用例来执行，并且多次进行测试，把出现错误的次数和共测试的次数记录下来计算出现的频率。
2.如果是随机测试时出现的错误，需要多次进行测试执行，找到确定的错误点，对测试流程步骤进行记录。同样也要计算出出现的频率。
3.跟开发人员沟通，把问题描述清楚，请开发人员查找错误点，并进行改善。
4.进行缺陷管理进行记录，下次有相同的问题出现，可以作为参考。
5。软件上线以后，需要用户对测试出错误的流程重点进行应用，并且注意是否再次出现错误。

aux0

比较赞同且有效的做法
1.        严格按用例执行；
2.        如果是作随机测试时,把测试步骤的点进行速记;
3.        偶发BUG一般都是严重的,保留现场,让开发人员一起分析留下的现场(如数据的变化,界面窗口的变化等,找出问题的引子,那怕是千丝万缕,只要有一线希望,都要与开发人员一起分析,千万别关机(关机后再重启很多现场已破坏,不少数据是保存在闪存中的)。
4.        最好的做法：要求开发打开trace，测试版本在执行时能自动把测试的路径，或触发的消息等输出到文件，相当于软件的执行log，这个log对解决偶发问题将大有裨益。
5.        即使一时没有重现，一定也要录入故障库，并标明发生的概率。在日后不同的迭代版本中进行跟踪验证，并把验证的路径写上。
6.        事上没有那么侥幸的事,在公司内部出现过的BUG，在用户端一定也会发生，只是时间与频率的问题，所以要视其影响度，是否需考虑由专人处理这类问题。

chengxq

偶发的bug 可能重现比较困难，这部分可能和开发部门说明时比较困难，但是不能因为偶发而不说明
这里测试组做bug票时，最好要说明bug出现的概率！做好统计！
明确职责！

whaiya

公司里偶发的bug，在客户哪儿肯定能再次重现，这种现象频繁的在我们公司得到验证，在公司内发现的bug，如可能要经历一个月或更长的时间，那么公司外那么多客户，出现的频率可能就是一周。所以只要在公司内部发现的偶发的重大bug，即使版本已经发出，在公司内部肯定安排专人专职重现此bug，哪怕是一月两月。只要他能重现此bug的步骤，他的绩效就是优。
重现此问题：
1、跟开发沟通条件和路径覆盖率
2、平时记录每次操作步骤，最大可能缩小偶发bug再现步骤
3、在一段时间内安排专人专职此bug。
4、如跟通信有关，每次重现此bug过程中让开发把一些调试信息打印出来进行分析。

rj_zj

谢谢楼上的。
我昨晚回去想了想，在实际工作当中我们通常是这么处理的。
1. 找到一种相对容易重现的方法，然后就像您所说的收录到缺陷管理库。标明发生概率。
2. 对周围区域的测试用例进行Rerun
3. 围绕该缺陷的周边多做做探索性测试.

jasonxu

收入缺陷管理库，或者不断重复一定的次数，如果没有再出现的话，说明该bug不存在了。个人意见，仅供参考。