缺陷管理总结篇

缺陷管理，是软件研发过程中的一项过程管理。它与配置管理都是CMM2级一个KPA（关键过程域）。
   
    一、明确几个缺陷管理的概念。
   
    缺陷（Defect），就是静态的存在于软件工作产品（文档和代码）中的错误，也指在软件运行期间，由于这些错误所激发引起的和软件预期属性相偏离的现象。
   
    错误（Error），代码中的错误。包括语法的错误（Syntax Error）和逻辑的错误（Logical Error）。
   
    故障（Fault），软件在运行期间发生的意外状况。
   
    失效（Failure），软件在运行期间发生意外状况，与用户的需求不符，导致功能不可用。
   
    狭义的Bug就是错误，广义的Bug就是缺陷，在实际的工作中，缺陷和Bug意思是一样的。错误可能会导致故障，故障可能会导致失效，但是都不是必然的。
   
    缺陷单（Bug Report）对于缺陷定位的书面报告，是修改、跟踪、证明、度量的依据。
   
    二、区分是缺陷还是改进
   
    缺陷就是被测试软件的实现与需求规格说明书描述的不一致，是由开发人员进行修改。
   
    改进（Enhancement）是指用户的需求与需求规格说明书描述的不一致，是由需求人员进行修改。二者的现实意义：
   
    （1）避免扯皮，明确责任
   
    （2）涉及到费用问题（缺陷不需要缴费）
   
    三、缺陷管理的目的：
   
    （1）保证信息的一致性
   
    （2）确保缺陷得到有效的跟踪和解决
   
    （3）获得正确的Bug信息，用作缺陷分析和产品度量。
   
    四、缺陷的管理工具
   
    缺陷的管理工具发展经历了三个阶段，缺陷跟踪数据库、缺陷跟踪系统和缺陷管理系统。缺陷跟踪的成本越来越低，相关人员的工作量越来越少。跟踪体现在事前，而管理涉及到事前、事中、事后的整个过程，强调对缺陷的度量和分析。
   
    第三代缺陷管理工具主要有，TD/QC（Mercury）、ClearQuest（Rational）、BMS（Microsoft）、Jira、SilkTest、Bugzilla、Butterfly、Mantis.
   
    缺陷管理工具是通过设置角色来管理的，不同的角色具有不同的权限，从而实现对所属不同角色的账户进行管理。TD/QC中默认角色主要包括：
   
    （1）developer 开发角色
   
    （2）project manager 项目负责人角色
   
    （3）QA tester 测试角色
   
    （4）TD admin 管理员角色
   
    （5）viewer 访客的角色
   
    默认的角色，不可以被删除和修改他们的权限。如果是具有管理员的权限，可以自己创造相应的项目所需要的角色，上述的角色的权限是可以被继承的。
   
    五、缺陷管理的流程
   
    反映了缺陷的生命周期从发现提交缺陷报告单，经过若干个环节到最终权限得以修复并关闭Bug单为止。一般情况都经历了提交、审查分配、修改、验证、关闭几个阶段。不同的软件组织和软件产品，要求的缺陷管理流程是不一样的。
   
    六、缺陷的属性
   
    缺陷的属性包括：缺陷的状态、缺陷的严重级别、优先级别、缺陷引入和发现的阶段、缺陷所属的版本和模块、缺陷提交人和提交对象、缺陷发现、修改的时间和预期关闭的时间等。
   
    缺陷的严重级别和优先级别没有任何的关系，是对缺陷从不同角度所进行的描述。
   
    缺陷的严重级别就是缺陷对系统的破坏程度，分为致命（软件异常退出、系统崩溃、重要数据丢失），严重（单个功能失效引发多个功能均失效），一般（单个功能失效），提示或者建议（轻微的缺陷，比如控件没有对齐，错别字等）。
   
    缺陷的优先级别就是缺陷修复的迫切程度，分为高（1-2个工作日解决），中（3个工作日内解决），低（方便时解决）。优先级可以有测试人员提交也可以由开发经理提交，但是建议由开发经理提交，因为可以从整个成本、工作量、风险、质量等因素综合考虑进行任务分配。
   
    缺陷的状态，就是缺陷在生命周期某个时间点上的生命体征。缺陷管理流程的推进就是由缺陷的状态进行驱动的。包括：
   
    （1）new,缺陷的初始状态。
   
    （2）open,缺陷被确认，进行修改的状态。
   
    （3）fixed（resolved），缺陷修改完成，等待验证的状态。
   
    （4）closed,验证通过，结束状态。
   
    （5）reopen,验证未通过，重新修改状态。
   
    （6）rejected,拒绝修改状态。由开发决定。
   
    （7）duplicate,重复缺陷，交回测试状态。
   
    （8）abandon,rejected或者duplicate确认之后，抛弃缺陷的结束状态。
   
    （9）postpone（delay），延迟修改的状态。开发和测试共同决定。
   
    1-6为常用的缺陷状态。
   
    七、缺陷单
   
    缺陷单的内容：标题（发现了什么？）、操作步骤（缺陷得以发现的步骤）、输入（使缺陷重现的数据）、环境、附件（不好表述时使用，截图）、缺陷属性。
   
    缺陷单书写的5C原则：
   
    （1）正确Correct,不会产生歧义。
   
    （2）清晰Clear,容易理解。
   
    （3）简洁Concise,没有多余的东西。
   
    （4）完整Complete,包含重现缺陷的完整数据。
   
    （5）一致性Consistent,缺陷单格式要统一。
   
    其他要领：
   
    （1）再现，缺陷要至少出现三次，如果是间断的，至少要写清楚出现的频率。如果不能重现就需要进行技术加压和重新的构造，使缺陷再现。
   
    （2）初步定位，提供影响缺陷得以重现的相关要素。
   
    （3）推广，确定系统的其他部分是否会出现相同的问题。
   
    （4）压缩，同简洁。
   
    （5）祛除歧义，同准确。
   
    （6）中立，要公正、客观的对缺陷进行描述，不应该用幽默或者讽刺的语言。
   
    （7）评审，至少有一个同行，比如高级测试工程师或者测试经理，在提交之前先阅读一遍。