bug和\的具体处理流程是什么呀??
各个状态是如何转换的!!!

测试人员提交新BUG-》开发人员分析BUG，解决后，置BUG为RESOLVE-》测试人员收到BUG提交的通知，在下个新版本发布后-》测试人员在新版本上验证，如果OK，就CLOSE，没OK，就再重新提交给开发

找套BUG管理软件就行了

bug跟踪有几个状态
new:一个新bug
open:开发开始修改bug
fixed:修改bug完毕
closed:回归测试通过
reopen:回归测试失败
postpone:修改延后
rejected:开发拒绝修改bug，认为不是程序问题
duplicate:bug已重复
abandon:不需要修改，放弃bug
这个几个状态彼此有关联，可以自己画状态图

补充一下：
对于提交的bug，应当设置一个bug审核状态，测试负责人对此进行审核并分流

对于开发人员修改bug，有一个修改方案审核的状态，开发经理对此审核

当然，这是在bug处理流程相当细的情况下。但是作用很大，一方面能提高bug的有效性，减少在开发那把bug置为无效的可能性，另一方面，也能提高bug修改的正确性

根据bug的一些状态，我画了一个状态转换图，不知是否正确。大家看看啊。

Fixed为什么还要转到New咧？

回归测试失败，bug被重新打开，成为新的bug，所以流程又从new开始往下走。

恩 写的挺具体

不用又从NEW开始走,应该是再加一个新的状态REOPEN

先是测试人员new一个BUG，开发人员再查看BUG，若所提交的问题确实是一个BUG，则将其open，否则rejected，当开发人员修改完这个BUG并已经过内部测试，则将其fixed，这时测试人员将再次查验这个BUG，若这个问题确实已解决，则将其closed，否则reopen。如此循环。

BUG状态转换图挺具体的，不过流程图好像画的不是很正规哦。。。。

那你发个正规的.

不正规？我靠，我一直这个流程操作，把你的共享上来看看

引用:

原帖由 sxhangela 于 2007-12-4 13:17 发表
回归测试失败，bug被重新打开，成为新的bug，所以流程又从new开始往下走。

个人认为，不应该转向new，应该置为 reopen

加个reopen更好！