Bug生命周期
上一篇 /
下一篇 2008-10-18 20:45:44
/ 个人分类:软件测试管理
首先测试发现Bug并提交bug(bug状态为new/Active),然后分配bug(bug状态为assigned),开发人员接收并修改bug(bug状态为fixed/Resolved),最后测试人员验证bug(bug状态为Closed)
此时肯定有人会发现问题,这么简单的流程图是太理想化了,无法满足实际。这是当然,Bug是可以‘死而复生’的,也许在下个版本问题有再次出现,又或许从测试人员角度讲,问题验证不通过怎么办?从管理及开发角度想,这不是bug又怎么办。带着这些疑问,我们进一步完善流程图。
基本可以满足一般的使用。但是我们忽略了一点,bug是有分类的“严重程度(Severity)和优先级别(Priority)”。在实际的应用中,很多项目的bug都比较多,而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架,会造成更多的潜在缺陷,在悲观点就是面对市场压力需要尽快发布的情况等。Bug是否被修改?什么时候修改?就是需要定夺的了。又想到一点,如果此项目是多个测试人员同时测试,那是否bug会提交重复呢?理清楚思路后,就可以在进一步完善我们的流程图啦!
相关阅读:
- 一些与软件测试相关的英文网站 (yanming_huo, 2008-9-15)
- 测试团队金字塔型的发展模式 (fishy, 2008-9-16)
- 软件测试管理和测试流程 (caption, 2008-9-17)
- 测试团队发展中的尴尬 (fishy, 2008-9-18)
- Bug管理的一般流程 (wangLoveR, 2008-9-21)
- 性能测试流程 (王爬爬, 2008-9-24)
- 成功测试管理的九大原则 (caption, 2010-5-27)
- IBM Rational软件测试管理 (fishy, 2008-10-09)
- PC-lint---代码规范性检查工具 (lynmin, 2008-10-15)
- STi的一个bug? (travelinrain, 2008-10-15)
收藏
举报
TAG:
Bug
软件测试管理
流程