概念

定义

• 从内部看，软件缺陷试产品开发或者维护过程中存在的错误、毛病等各种问题
• 从外部看，软件缺陷是系统所需要实现的某种功能的失效或者违背
• 总的来说，缺陷就是问题，最终表现为所需要的功能没有完全实现，没有满足用户的需求。

具体包含（程序、数据、文档）

• 未达到需求规格说明书中的功能
• 出现了需求规格说明数中指名不会出现的错误
• 功能超出了需求规格说明书的范围
• 未达到需求规格说明书中虽然没有指明，但应该达到的目标
• 测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好

表现形式s

• 未达到需求规格说明书中的功能
• 出现了需求规格说明数中指名不会出现的错误
• 功能超出了需求规格说明书的范围
• 未达到需求规格说明书中虽然没有指明，但应该达到的目标
• 测试人员或者用户认为软件难以理解、不易使用、运行速度慢或者最终用户认为不好

缺陷产生的原因

• 缺陷不可避免，主要原因如下

  • 需求解释或者记录错误
  • 用户需求定义错误
  • 需求说明存在错误
  • 编码说明、程序代码有无
  • 硬件或者系统存在错误
  • 文档错误、内容不正确、拼写错误

• 缺陷产生的根源

  • 交流不充分
  • 软件的复杂性
  • 开发任务的错误
  • 需求的变化
  • 进度压力
• 缺陷的修复费用

缺陷报告介绍

在测试后，如果发现缺陷，则应该进行缺陷报告。

• 缺陷报告的一些字段及说明

• 缺陷报告有如下作用：

  1. 记录测试结果
  2. 方便开发人员进行缺陷的定位
  3. 为后期统计缺陷提供依据

缺陷报告内容

​ 软件缺陷: 软件或程序中存在的各种问题及错误。软件缺陷的存在会导致软件产品在某种程度上不能满足用户的需求 执行测试用例时，【实际结果】与【预期结果】不一致

缺陷状态

• 状态变化

  1. new - 测试人员发现缺陷
  2. assigned - 由开发经理或者其他人员，将修复职责指定为某位开发人员

  3. 开发人员阅读缺陷报告，可能得到如下结果

     • open 测试人员是正确的，准备修复
     • duplicate 与其他bug为同一原因，修正好一个后，这个也就修复了
     • reject 测试人员理解错误，其实这不是bug
     • fixed 经过一段时间开发人员修复了bug，就会标记为此状态
     • postpone 小问题，目前没有时间修复

  4. 测试人员检验缺陷状态

     • closed 再次测试，发现错误已经修复。
     • closed reject的错误，经过沟通核实后，确认无需修复
     • reopen 原来修复后的缺陷，经过回归测试后又出现了，标记原先的缺陷为此状态
• 缺陷的跟踪

• 要点

缺陷从测试人员开始， 也应该由测试人员结束。

严重程度

• 严重程度分为五个等级：

  • Fatal 致命的缺陷 造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。
  • Critical 严重错误的软件缺陷 系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。 如系统资源占用过大、功能没有做完。
  • Major 一般的软件缺陷 次要功能没有完全实现但不影响使用。 如：提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等。
  • Minor 较小的软件缺陷 较小错误的软件缺陷，使操作者不方便或遇到麻烦，但它不影响功能性的操作和执行。 例如：对话框弹出位置，步骤较多，输入项太麻烦。
  • Enhancemental 建议问题 由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。 例如：错别字、颜色、按钮大小。
• 说明

严重程度的分级，并不统一，有的公司分为3个等级或者4个等级，都是可以的

优先级

• 说明

有的公司，也会把优先级分为3个或者5个，都是可以的。

表现形式

缺陷报告书书写规范

标题

• 简短
• 尽量能够体现 原因和结果
• 准确：避免使用模糊不清的词语
• 便于他人理解，不要使用俚语、方言词汇

原则

• 完整 他人按照步骤，即可复现问题
• 简明 不包含夸张、啰嗦的内容

内容

• 测试环境描述

• 步骤

  • 加上编号
  • 一个步骤不要包含太多步骤
  • 可能将多个步骤合为一个
  • 可以包含 该步骤后的一个中间结果
  • 可使用短语或者短句，不需要复杂句式
• 实际结果 清楚，不笼统
• 期望结果 根据需求文档，应该出现的结果
• 附件 截图、录屏、测试中需要的数据
• 解决方案/可能的原因（非必须） 如果测试人员能够给出解决方案则更好了。

常见错误

• 人称代词不明确
• 情绪化语言、强调符号
• 不确定词汇
• “幽默”、“梗”
• 不确定：对于缺陷，测试人员至少需要再次操作，来重现缺陷

缺陷报告统计

• 通过缺陷统计，我们可能得出以下信息

  • 缺陷分布：找出系统的薄弱环境
  • 缺陷状态：根据变化，检查测试和开发的工作情况
  • 人员水平：开发人员出错的数量，测试人员测出的数量
  • 比较历史：对人员水平有所把握
  • 模块难度：较难的模块出问题的可能较大
  • 修复时间：平均修复缺陷需要的时间，越短越好
  • 未修复的缺陷数目：

• 作用

  • 风险评估：能否在计划内的时间发布
  • 缺陷原因：避免反复出现同类型的缺陷
  • 员工技能提升：根据开发和测试人员表现出来的问题，可有针对性提升
  • 团队配置：根据缺陷修复时间，可知道团队配合强弱

• 指标

  • 单位时间（天/周）内报告的缺陷数目
  • 单位时间（天/周）内修复的缺陷数目
  • 累计缺陷报告数量
  • 累计缺陷修复数量
  • 不同严重性的缺陷数
  • 模块与缺陷的对应关系
• 缺陷密度

单位 缺陷数量/kloc ( kilo lines of code) 计算 总缺陷数量 / 总代码行数 / 1000

缺陷报告总结

缺陷报告的原则和重要性

• 重要性

  • 节省开发和测试人员的沟通时间
  • 提高缺陷修复速度
  • 提高测试人员的声誉
  • 加强协同工作

• 原则：

  • 5C准则

    • 准确：每个组成部分的描述准确不会引起误解。
    • 简洁：只包含必不可少的信息，不包括任何多余的内容。
    • 清晰：每个组成部分的描述清晰，易于理解。
    • 完整：包含复现该缺陷的完整步骤和其他本质信息。
    • 一致：按照一致的格式书写全部缺陷报告。

  • 一个缺陷一个报告

    • 便于分配
    • 便于验证

常见缺陷的查找方法

• UI （非重点）

  • 色彩
  • 大小
  • 布局
  • 图片
  • 字体

• 时间

  • 网络传输
  • 数据未压缩
  • 解析困难

• 文字内容

  • 描述不清
  • 描述不正确
  • 有语病、错别字
  • 太复杂
  • 乱码
• 容错处理

• 性能缺陷

  • 花费时间长
  • 资源占用多
  • 卡顿
  • 并发差
  • 延迟高

缺陷的修复

• 不是所有的“缺陷” 都是缺陷

  • 无法重现 或者 难以捕捉
  • 缺陷报告中没有复现步骤
  • 缺陷报告无法理解
  • 极少使用的功能，或者不符合用户习惯，或者惯例
  • 由不受信任的测试人员提出

• 不是所有的缺陷都会修改

  • 上线时间由限制
  • 不正确的操作
  • 涉及模块太多，可能导致按下葫芦浮起瓢的情况
  • 性价比太低
  • 极难重现

缺陷管理过程

CMM = Capability Maturity Model for Software = 软件能力成熟度模型

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：

• 初始级(initial)。

工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。

• 可重复级(Repeatable)

管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有重复以前成功项目的环境和条件。

• 已定义级(Defined)

开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。

• 已管理级(Managed)

产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，实现及时纠正。

• 优化级(Optimizing)

可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。