第二章：软件缺陷与缺陷管理

什么是软件缺陷?

如何管理软件缺陷？

Bug的由来：海军少将Grace Hopper

2.1 缺陷定义与分类

2.1.1 软件缺陷

• 定义

  • 存在于软件（文档、数据、程序）之中的那些不希望，或不可接受的偏差，导致软件产生的质量问题。

• 如何判断软件存在缺陷？

• 未实现产品说明书要求的功能

• 实现了需求中未提到的功能

• 软件难以理解、不易使用、运行缓慢或者最终用户会认为不好

• 软件出现了产品说明书指明不应该出现的错误

• 产生软件缺陷的原因

  1. 需求
  2. 设计
  3. 编码
     

• 软件缺陷在不同阶段的分布

  

  需求设计一般来说造成更多缺陷，在真正的程序测试之前，通过审查、评审可以发现更多的缺陷。

  规格说明书的曲线会在需求分析审查、设计、编码、测试等过程中逐步发现。
  
  早期阶段修复缺陷成本更低，越往后修复缺陷成本越高。

2.1.2 软件缺陷的描述与分类

• 软件缺陷的描述是软件缺陷报告中测试人员对问题的陈述的一部分并且是软件缺陷报告的基础部分。

• 软件缺陷的描述也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。

• 一个简单的缺陷报告一般要包括：

  • 标题

  • 前提

  • 测试环境

  • 操作步骤

  • 期望结果

  • 实际结果

  • 出现的频率等

    

• 由三部分组成：操作/重现步骤、期望结果、实际结果：

  • “步骤”提供了如何重复当前缺陷的准确描述，应简明而完备、清楚而准确。
  • “期望结果”与测试用例标准或设计规格说明书或用户需求等一致， 达到软件预期的功能。验证缺陷的依据。
  • “实际结果”测试人员收集的结果和信息，以确认缺陷确实是一个问题，并标识那些影响到缺陷表现的要素。

• 软件缺陷属性

  缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。

  • 缺陷类型

    缺陷类型	描述
    功能	影响了各种系统功能、逻辑的缺陷
    用户界面	影响了用户界面、人机交互特性，包括屏幕格式、用户输入 灵活性、结果输出格式等方面的缺陷
    文档	影响发布和维护，包括注释，用户手册，设计文档
    软件包	由于软件配置库、变更管理或版本控制引起的错误
    性能	不满足系统可测量的属性值，如执行时间，事务处理速率等
    系统/模块接口	与其他组件、模块或设备驱动程序、调用参数、控制块或参 数列表等不匹配、冲突。

  • 软件缺陷严重程度：是指因缺陷引起的故障对软件产品的影响程度，所谓“严重性”指的是在测试条件下，一个错误在系统中的绝对影响。

    缺陷严重等级	描述
    致命 (Fatal)	系统任何一个主要功能完全丧失、用户数据受到破坏、系统崩溃、悬挂、死机，或者危及人身安全
    严重 (Critical)	系统的主要功能部分丧失、数据不能保存，系统所提供的功能或服务受到明显的影响
    一般 (Major)	系统的部分功能没有完全实现，但不影响用户的正常使用
    较小 (Minor)	使操作者不方便或遇到麻烦，但它不影响功能的操作和执行

  • 缺陷产生的可能性：指缺陷在产品中发生的可能性，通常可以用 频率来表示。

    缺陷产生可能性	描述
    总是 (Always)	总是产生这个软件缺陷，其产生的频率是100%
    通常 (Often)	按照测试用例，通常情况下会产生这个软件缺陷，其产生的 频率大概是80-90%
    有时 (Occasionally)	按照测试用例，有的时候产生这个软件缺陷，其产生的频率 大概是30-50%
    很少 (rarely)	按照测试用例，很少产生这个软件缺陷，其产生的频率大概 是1-5%

  • 缺陷优先级：指缺陷必须被修复的紧急程度。“优先级”的衡量 抓住了在严重性中没有考虑的重要程度因素。

    缺陷优先级	描述
    立即解决(P1级)	缺陷导致系统几乎不能使用或测试不能继续，需立 即修复
    高优先级(P2级）	缺陷严重，影响测试，需要优先考虑
    正常排队(P3级）	缺陷需要正常排队等待修复
    低优先级(P4级）	缺陷可以在开发人员有时间的时候被纠正。

  • 软件缺陷状态：指缺陷通过一个跟踪修复过程的进展情况，也就是在软件生命周期中的状态基本定义。

    缺陷状态	描述
    激活或打开（Active or Open）	问题还没有解决，存在源代码中，确认“提交的缺陷”，等待处理
    已修正或修复(Fixed or Resolved)	已被开发人员检查、修复过的缺陷，通过单元测试，认为已解决但 还没有被测试人员验证
    关闭或非激活(Closed or Inactive)	测试人员验证后，确认缺陷不存在之后的状态。
    重新打开(Reopen)	测试人员验证后，还依然存在的缺陷，等待开发人员进一步修复
    推迟(Deferred)	这个软件缺陷可以在下一个版本中解决
    保留(on hold)	由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷
    不能重现(Cannotduplicate)	开发不能复现这个软件缺陷，需要测试人员检查缺陷复现的步骤。
    需要更多信息(Needmoreinfor)	开发能复现这个软件缺陷，但开发人员需要一些信息
    重复（Duplicate）	这个软件缺陷已经被其他的软件测试人员发现。
    不是缺陷（Notabug）	这个问题不是软件缺陷
    需要修改软件规格说明书（Spec modified）	由于软件规格说明书对软件设计的要求，软件开发人员无法修复这 个软件缺陷，必须要修改软件规格说明书。

  • 缺陷起源：缺陷引起的故障或事件第一次被检测到的阶段

    缺陷起源	描述
    需求	在需求阶段发现的缺陷
    构架	在系统构架设计阶段发现的缺陷
    设计	在程序设计阶段发现的缺陷
    编码	在编码阶段发现的缺陷
    测试	在测试阶段发现的缺陷
    用户	在用户使用阶段发现的缺陷

  • 缺陷来源：指缺陷所在的地方，如文档、代码等。

    缺陷来源	描述
    需求说明书	需求说明书的错误、或不清楚引起的问题
    设计文档	设计文档描述不准确、和需求说明书不一致的问题
    系统集成接口	系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷
    数据流(库)	由于数据字典、数据库中的错误引起的缺陷
    程序代码	纯粹在编码中的问题所引起的缺陷

  • 软件缺陷的根源：指造成上述错误的根本因素，以寻求软件开发流程的改进、管理水平的提高。

    缺陷根源	描述
    测试策略	错误的测试范围，误解了测试目标，超越测试能力等
    过程，工具和方法	无效的需求收集过程，过时的风险管理过程， 不适用的项目管理方法，没有估算规程，无效的变更控制过程等
    团队/人	项目团队职责交叉，缺乏培训,没有经验的项目团队，缺乏士气和动机不纯等
    缺乏组织和通讯	缺乏用户参与，职责不明确，管理失败等
    硬件	硬件配置不对、缺乏，或处理器缺陷导致算术精度丢失，内存溢出等
    软件	软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误， 千年虫问题等。
    工作环境	组织机构调整，预算改变，工作环境恶劣，如噪音过大。

• 软件缺陷报告

  

  

• 软件缺陷描述规则

  • 单一准确
  • 可以再现
    • 顺序正确
    • 内容正确
  • 完整统一
  • 短小简练
  • 特定条件
  • 不做评价
  • 发现导致错误的根本原因

2.2 缺陷管理流程

• 发现-打开：测试人员找到软件缺陷并将软件缺陷提交给开发人员。
• 打开-修复：开发人员再现、修复缺陷，然后提交给测试人员去验证。
• 修复-关闭：测试人员测试修复过的软件，关闭已不存在的缺陷。

2.3 缺陷度量和缺陷报告

• 对缺陷数据进行统计，从而判断软件质量、项目进展。

• 软件测试不仅是为了发现缺陷和错误，也是对软件质量进行度量和评估，以提高软件产品质量。

• 场景

  • 设计测试用例
  • 执行设计的测试用例
  • 记录缺陷以及执行失败的相关用例
  • 验证缺陷

• 测试指标主要分为两个类别：

  • 基础指标

    由测试分析师在测试用例编写和执行期间收集的数据派生来的指标。
    某一项目所开发的测试用例的总数、 需要被执行的测试用例的数量或是通过/失败的测试用例计数

  • 计算指标

    通过收集基础指标数据而派生的。这些指标通常由测试经理为测试报告等目的而进行追踪。
    缺陷密度=已知缺陷的数量/产品规模

• 测试指标

  • 需求个数
  • 平均每个需求所写的测试用例个数
  • 总的测试用例个数
  • 被执行的用例的个数
  • 通过的用例个数
  • 失败的用例个数
  • 中断的用例的个数
  • 没有被执行的用例个数
  • 确定的缺陷数
  • 严重的缺陷数
  • 优先级较高的缺陷数
  • 一般的缺陷数
  • 轻微的缺陷数

• 缺陷密度

  • 缺陷密度=已知缺陷的数量/产品规模
    产品规模度量单位：文档页、代码行、功能点（function point）
  

• 原因

  

2.4 缺陷管理工具

• 有利于软件缺陷的清楚描述，还提供统一的、标准化报告， 使所有人的理解一致；

• 允许自动连续的软件缺陷编号，还提供了大量供分析和统计的选项，这是手工方法无法实现的；

• 可快速生成满足各种查询条件的、所必要的缺陷报表、曲线图等，开发小组乃至公司的每一个人都可以随时掌握软件产品质量的整体状况、或测试/开发的进度；

• 提供了软件缺陷属性并允许开发小组根据对项目的相对和绝对重要性来修复缺陷；

• 可以在软件缺陷的生命期中管理缺陷，从最初的报告到最后的解决，确保了每个缺陷不会被忽略。

• 当缺陷在它的生命周期中变化时，开发人员，测试人员以及管理人员将熟悉新的软件缺陷信息。

• 在软件缺陷跟踪数据库中关闭每一份缺陷报告，它都可以被记录下来。

   ButRat （开源）
   Bugzilla（开源）
   Mantis（开源）
   IBM Rational ClearQuest
   TrackRecord