BUG的生命周期
上一篇 /
下一篇 2011-03-04 11:55:21
/ 个人分类:感受
转至 http://www.51testing.com/?uid-159327-action-viewspace-itemid-94172
首先测试发现Bug并提交bug(bug状态为new/Active),然后分配bug(bug状态为assigned),开发人员接收并修改bug(bug状态为fixed/Resolved),最后测试人员验证bug(bug状态为Closed)
此时肯定有人会发现问题,这么简单的流程图是太理想化了,无法满足实际。这是当然,Bug是可以‘死而复生’的,也许在下个版本问题有再次出现,又或许从测试人员角度讲,问题验证不通过怎么办?从管理及开发角度想,这不是bug又怎么办。带着这些疑问,我们进一步完善流程图。
基本可以满足一般的使用。但是我们忽略了一点,bug是有分类的“严重程度(Severity)和优先级别(Priority)”。在实际的应用中,很多项目的bug都比较多,而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架,会造成更多的潜在缺陷,在悲观点就是面对市场压力需要尽快发布的情况等。Bug是否被修改?什么时候修改?就是需要定夺的了。又想到一点,如果此项目是多个测试人员同时测试,那是否bug会提交重复呢?理清楚思路后,就可以在进一步完善我们的流程图啦!
收藏
举报
TAG: