淡了,散了,一点点;累了,睡了,呼呼中;懂了吗?是的
缺陷管理说明
上一篇 /
下一篇 2007-09-06 17:00:08
/ 个人分类:bug管理工具
缺陷管理
软件存在缺陷,但是如何有效的管理缺陷是软件能不能正常提交的一个保障,这里引入缺陷管理的一些概念和方法。
1,概念
缺陷管理需要遵循一个流程,也就是缺陷的生命周期。粗略的划分,缺陷的生存周期可以分为这么一些阶段,
缺陷汇报(submitted)
缺陷确认(accepted)(TobeCorrected)
缺陷修改(Corrected)
缺陷修改确认(Validated)
不是问题(not a problem)
此外,有一些附加状态,比如,暂不修改(derogation),继承(inherit)
缺陷级别也是个很重要的概念,同时存在两种级别,一种是从测试人员角度定义的级别,另一种是从开发人员角度定义的级别,两种级别在大多数时候都是一致的。简单来讲,缺陷级别可以分为以下几种:
非常低(very low)
低(low)
重要(important)
非常重要(severe)
同时,由于产品的决策或者设计问题,有的缺陷也会以一种建议的方式出现,这个时候,也许所汇报的缺陷根本就不是缺陷,而更多的是对于产品能够更加友好的一种建议。
2,缺陷在项目和产品当中的管理异同
由于项目和产品在用户影响方面的差异,缺陷也会在其中表现出一些不同的地方,比如说,在产品当中,用户友好性差一点,可以被当成一种建议来做,但是在项目当中,这个就成为了一种缺陷,有的时候甚至是很严重的缺陷。那么总体来讲,有那么一些不同。
- 级别定义不同
- 确认方式不同(产品修改确认需要的是一个官方的发布版本,但是项目的确认方式也许就是一个补丁)
- 修改方式不同(项目的缺陷无沦巨细,都是需要在提交给用户之前修改的,但是产品的缺陷却可以延迟到下一个版本)
- 缺陷转换(缺陷是可以由项目转换到产品,然后由产品统一控制,管理的,因为项目组的侧重点和产品组的侧重点是不一样的,很多问题在项目当中出现,但是项目组没有能力修改,那么就需要产品组予以帮助)
3,却陷管理工具
缺陷需要管理,但是如果单纯的靠纸和笔进行管理,显然是不能够满足需要的,简单来讲,却陷管理工具至少能够满足以下特点,
- 以项目为基础的管理方式
- 严格的用户权限管理(不同的角色应该具备不同的权限)
- Email通知机制(当状态改变以后,相关人员能够被通知到)
- 从不同的维度进行缺陷的统计
- 全方位的缺陷查询
- 项目缺陷级别可定义
- 软件模块定义
现在,有很多业界比较认可的缺陷管理工具,包括Test Director, ClearQuest等等,免费的工具有Bugzilla也很好。不妨下载一个使用版本来玩玩。:)
4,却陷统计报表
缺陷报表之所以重要是因为,报表能够为我们提供事后统计,而定期的报表也能够为我们提供项目管理的支持,我们能够根据缺陷的汇报以及分布情况来判断当前的项目进度情况,什么模块出现的缺陷最多。在项目完结的时候,缺陷报告也能够为我们提供当前的软件测试是不是已经达到了要求,是不是可以提交给客户。
一般情况下,我们会根据以下几种情况来定义缺陷情况,
· 缺陷分布情况:这里对于各种不同状态的缺陷的一个快照
图1
· 各种级别的缺陷的分布情况
图2
· 缺陷发展的趋势
图3
在项目完结的时候生成上面的图形,如果发现还存在打开状态的缺陷,就需要做出决策,这样的缺陷需要关闭吗?还是在下一个版本当中修改或者别的解释。总之,在提交软件产品的时候,是不能存在一个开启状态的缺陷存在的。
4,汇报缺陷的一些建议
缺陷汇报是缺陷制造者和缺陷发现者之间沟通的桥梁,所以,缺陷必须被描述清楚,这里,有几点建议,
· 详细描述操作步骤
· 粘贴日志信息作为附件
· 对于界面测试,需要把错误界面捕捉下来,作为附件粘贴上
· 错误修改确认的时候,需要把软件版本号加上
· 测试数据描述
· 测试先决条件描述
收藏
举报
TAG:
bug管理工具