BUG的生命周期

上一篇 / 下一篇  2011-03-04 11:55:21 / 个人分类:感受

转至 http://www.51testing.com/?uid-159327-action-viewspace-itemid-94172

首先测试发现Bug并提交bugbug状态为new/Active),然后分配bug(bug状态为assigned),开发人员接收并修改bugbug状态为fixed/Resolved),最后测试人员验证bug(bug状态为Closed)

      此时肯定有人会发现问题,这么简单的流程图是太理想化了,无法满足实际。这是当然,Bug是可以‘死而复生’的,也许在下个版本问题有再次出现,又或许从测试人员角度讲,问题验证不通过怎么办?从管理及开发角度想,这不是bug又怎么办。带着这些疑问,我们进一步完善流程图。

基本可以满足一般的使用。但是我们忽略了一点,bug是有分类的“严重程度(Severity)和优先级别(Priority)”。在实际的应用中,很多项目的bug都比较多,而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架,会造成更多的潜在缺陷,在悲观点就是面对市场压力需要尽快发布的情况等。Bug是否被修改?什么时候修改?就是需要定夺的了。又想到一点,如果此项目是多个测试人员同时测试,那是否bug会提交重复呢?理清楚思路后,就可以在进一步完善我们的流程图啦!



TAG:

 

评分:0

我来说两句

Open Toolbar