51Testing软件测试论坛

标题: 一个BUG引出的新问题 [打印本页]

作者: goopy 时间: 2009-7-9 10:21
标题: 一个BUG引出的新问题
开发人员将BUG修复后，又引出了新的BUG，不知道大家在工作中是怎么解决的，大家一起发表下意见吧

作者: 月上百合 时间: 2009-7-9 10:28
这种情况很正常哦，继续提，继续修改

作者: ly113 时间: 2009-7-9 10:51
很正常的情况，继续提BUG.
如果同一问题引起的连锁的话，就是开发有问题了~

作者: 天空下下雨 时间: 2009-7-9 11:32
继续提BUG.说明是修改什么引出的

作者: lg1318617 时间: 2009-7-9 11:56
我刚遇到这个问题，BUG都关闭了，我还是把它重新开了出来。

作者: 投缘 时间: 2009-7-9 12:11
不光要修改这个缺陷和引发的缺陷，最好对程序中这个方法整个进行查看，借口是否存在问题。而且其他地方有没有再引用这个方法的地方。

作者: 袁媛 时间: 2009-7-9 16:01
如果是同一原因引起的，可以将原bug激活，如果是其他原因引起的，可以提交一个新bug。

作者: 原点 时间: 2009-7-16 09:21
reopen

作者: stacy-2008 时间: 2009-7-16 12:15
我看了大家的回答，我想在这里谈谈我的观点。其实楼主想问的真正问题，从我自己的理解看来有这几方面：1、如何发现这些回归的bug（Regression Bug）；2、如何避免这些bug 的出现。
我们先谈第一个问题，那就是如何发现这些bug，我们进一步考虑，其实解决这个问题的核心是确定测试范围。如果测试范围确定了，那么就不怕这些bug会溜掉。那我们如何确定测试范围呢？方法有多种，但是最终是要确定修改bug所需要动到的代码，它的影响范围有多大。确定他的影响范围，可以要求开发人员协助，从和开发人员的沟通中获取相关的信息。如果测试人员对代码有一定的了解，这是最好的，可以通过自己的相关判断。（这一点在一般的公司里面的测试人员的技能都不是很具备）。还有一点就是我们从功能上去找到互相的关联。用以上这些方法来确定我们的测试范围，然后确定我们要执行的用例。这样遗漏这些bug的可能性就很小了。好了，我们现在再来讨论第二个问题，如何避免这些bug，其实这是对开发人员有一定的要求，要求开发人员在修改代码时比较清晰的知道相关的代码结构。尽可能少的修改底层的类和方法。对于测试人员来说，可以给开发人员的帮助是，告诉他们这个功能和哪些功能有关联，这样他们在修改的时候就会注意。还有一点就是要提醒他们他们自己修改完了，要看看这些相关功能是不是产生了影响。

作者: zjxyy88107 时间: 2009-7-16 17:26

原帖由 xuzhijun 于 2009-7-12 03:59 发表
这就是回归测试的意义所在了啊.......
关闭之前bug的同时，将新产生的bug提交

顶你！不是这样的话要回归测试干什么？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)