缺陷管理

软件存在缺陷，但是如何有效的管理缺陷是软件能不能正常提交的一个保障，这里引入缺陷管理的一些概念和方法。

 

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，汇报缺陷的一些建议

缺陷汇报是缺陷制造者和缺陷发现者之间沟通的桥梁，所以，缺陷必须被描述清楚，这里，有几点建议，

·         详细描述操作步骤

·         粘贴日志信息作为附件

·         对于界面测试，需要把错误界面捕捉下来，作为附件粘贴上

·         错误修改确认的时候，需要把软件版本号加上

·         测试数据描述

·         测试先决条件描述

mantis_1.0.8安装文件加安装说明加使用说明书

• 上传不了，以后再和大家分享吧！