缺陷管理内涵.doc

缺陷管理 缺陷管理/软件缺陷管理（Defect Management）是在软件生命周期中获取、管理、沟通任何变更请求的过程（从变更的建议到变更的解决）。可以确保你的问题如需求或者缺陷被跟踪管理而不丢失。如果用PVCS Tracker工具就可以成功地进行缺陷管理。 目录 背景介绍 缺陷管理的目标 缺陷的描述 软件缺陷的分类与管理 处理的方法 优点 缺陷 不同软件组织的缺陷管理过程 个体行为 项目行为 组织行为 量化管理 持续优化 综述 展开 背景介绍 缺陷管理的目标 缺陷的描述 软件缺陷的分类与管理 处理的方法 优点 缺陷 不同软件组织的缺陷管理过程 个体行为 项目行为 组织行为 量化管理 持续优化 综述 展开 背景介绍 软件中的缺陷（Defect或Bug）是软件开发过程中的副产品。通常，缺陷会导致软件产品在某种程度上不能满足用户的需要。 每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。可遗憾的是，并非所有的软件组织都知道如何有效地管理自己软件中的缺陷。 缺陷管理的目标 缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果，软件测试过程简单说就是围绕缺陷进行的，对缺陷的跟踪管理一般而言需要达到以下的目标： a,确保每个被发现的缺陷都能够被解决； b,这里解决的意思不一定是被修正，也可能是其他处理方式（例如，在下一个版本中修正或是不修正），总之，对每个被发现的BUG的处理方式必须能够在开发组织中达到一致； c,收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段；决定测试过程是否结束有很多种方式，通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式； d,收集缺陷数据并在其上进行数据分析，作为组织的过程财富。 上述的第一条是最受到重视的一点，在谈到缺陷跟踪管理时，一般人都会马上想到这一条，然而对第二和第三条目标却很容易忽视。其实，在一个运行良好的组织中，缺陷数据的收集和分析是很重要的，从缺陷数据中可以得到很多与软件质量相关的数据。 缺陷的描述 对缺陷的描述应该包含以下的内容： 可追踪信息 缺陷ID 唯一的缺陷ID，可以根据该ID追踪缺陷 缺陷基本信息 缺陷状态 缺陷的状态，分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭” 缺陷标题 描述缺陷的标题 缺陷的严重程度 描述缺陷的严重程度，一般分为“致命”、“严重”、“一般”、“建议”四种 缺陷的紧急程度 描述缺陷的紧急程度，从1－4，1是优先级最高的等级，4是优先级最低的等级 缺陷提交人 缺陷提交人的名字（邮件地址） 缺陷提交时间 缺陷提交的时间 缺陷所属项目/模块 缺陷所属的项目和模块，最好能较精确的定位至模块 缺陷指定解决人 缺陷指定的解决人，在缺陷“提交”状态为空，在缺陷“分发”状态下由项目经理指定相关开发人员修改 缺陷指定解决时间 项目经理指定的开发人员修改此缺陷的deadline 缺陷处理人 最终处理缺陷的处理人 缺陷处理结果描述 对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改 缺陷处理时间 缺陷处理的时间 缺陷验证人 对被处理缺陷验证的验证人 缺陷验证结果描述 对验证结果的描述（通过、不通过） 缺陷验证时间 对缺陷验证的时间 缺陷的详细描述 对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细 测试环境说明 对测试环境的描述 必要的附件 对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的 缺陷的描述项中用淡紫色描述的是缺陷在处理阶段填写的内容；用淡青色描述的是缺陷在验证阶段填写的内容。除上述描述项外，从统计的角度出发，还可以添加上“缺陷引入阶段”、“缺陷修正工作量”等项目。 软件缺陷的分类与管理 处理的方法 通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会挫伤测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。 陷管理 在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求