软件测试之-软件缺陷管理

一、软件测试缺陷基本概念和相关术语

1）缺陷（Defect）：是指存在于软件之中误差，可被激活，以静态形式存在于软件内部，至关于Bug。
  2）故障（Fault）：当缺陷被激活后，软件运行中出现的状态，可引发意外状况，若不加处理，可产生失效，是一个动态行为。
  3）失效（Failure）：软件运行时产生的外部异常行为结果，表现与用户需求不一致，功能能力终止，用户没法完成所须要的应用。
  4）Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，均可以称之为“Bug”；有时也泛指因软件产品内部引发的软件产品最终运行时和预期结果的偏离。
  5）缺陷报告单：指测试执行过程当中，发现缺陷失效后，提出书面的报告，提供给开发人员做为定位缺陷的依据。

二、软件缺陷管理基本流程

下图是一个简单的BUG跟踪流程图：

1）椭圆形中标示的都是角色（测试人员、BUILDER人员、开发人员、专家会诊）
  2）柱状图1：发布服务器，通常存放当前最新的软件版本
     柱状图2：RAID/BMS，是Bug的管理系统，测试人员发现问题都要提交到这个系统上
     柱状图3：邮件服务器，测试人员、BUILDER人员、开发人员、专家之间发邮件进行交流。

三、软件缺陷管理的目的

1）保证信息的一致性；
  2）保证缺陷获得有效的跟踪和解决，缩短沟通时间，解决问题更高效；
  3）获取正确的Bug信息，利于缺陷分析、产品度量，使项目状况可视化增强。

四、软件缺陷的相关属性

@一、缺陷发现人

在提交缺陷的时候，测试人员通常是测试的发现人，便于统计分析测试人员的能力，方便公司进行绩效考核。

@二、缺陷发现时间

缺陷发现时间是一个统计的计数点，或者数据点，便于企业负责人选择合适的产品发布时间。

@三、软件缺陷的状态

1）New：缺陷的初始状态（发现问题，提交问题，提交问题后，这个缺陷就处于New的状态）
  2）Open：开发人员开始修改缺陷（测试人员提交问题，开发人员接受并开始修改问题）
  3）Fixed：开发人员修改缺陷完毕
  4）Closed：回归测试经过（测试人员进行回归测试，回归测试经过，该问题改成Close状态）
  5）Reopen：回归测试失败（测试人员进行回归测试，回归测试不经过，该问题改成Reopen状态）
  6）Postpone：推迟修改
  7）Rejected：开发人员认为不是程序问题，拒绝缺陷
  8）Duplicate：与已经提交的Defect重复
  9）Abandon：被Reject和Duplicate的Defect，测试人员确认后的确不是问题，将Defect置为此状态

比较理想的缺陷流程：从new状态——>open——>fixed——>closed状态。

@/四、缺陷的严重程度(Severity)

是站在用户的角度，指Bug出现后对用户和系统的影响程度。

软件缺陷的严重性指软件缺陷对软件质量的破坏程度，即软件缺陷的存在对软件的功能和性能产生怎样的影响，咱们能够简单地将软件缺陷的严重性划分为4个等级：致命、严重、通常、提示。

1）致命缺陷：例如软件的意外退出甚至操做系统崩溃，形成数据丢失。
  2）严重缺陷：系统没法知足基本的商业要求且没有便捷可用的工做区。性能、功能或使用方面严重不达标，例如因为单功能失效引发多个功能失效。
  3）通常缺陷：系统可以知足商业要求。有快捷方便的工做区可供使用。性能、功能或使用方面并非严重不达标，例如软件单个功能失效。
  4）提示：微小修改，但愿提出建议，最好可以修正，但不是必需的。在发布准确性或实用性方面不会产生重大影响

@五、缺陷的优先级（Priority）

是站在开发/项目的角度，综合权衡修改Bug的时间、成本、技术和风险，决定Bug修改的前后顺序。

1）优先级0（Priority 0）
     这类软件缺陷必须在24小时以内被解决
  2）优先级1（Priority 1）
     这类软件缺陷必须修复而后才能发布产品或者才能达到用户体验所包含的最主要目标，须要在1—2天内修改
  3）优先级2（Priority 2）
     软件缺陷应该在2—4天内被修复
  4）优先级3（Priority 3）
     若是修复这个缺陷会比较好，最好在一周内修改
  5）优先级4（Priority 4）
     发布周期内修改或者不修改

Severity（严重性）与Priority（优先级）之间的区别

1）软件里的Bug所产生的效果不会自动的与修复它的优先级相关联。一个严重的Bug多是那种对1%的用户来讲也是不太会发生的使软件崩溃的bug。那它的优先级也比那些误操做致使的须要对每一个用户每次须要从新键入一部分输入的Bug的优先级要低。
  所以：须要分别跟踪Bug优先级和严重性，而后进行适当的修复。Bug的重要性是由项目来决定的，不一样于客户对Bug的感知。某些状况下，分别跟踪急迫的或是按照客户观点定义的Bug也是颇有意义的。
  1）优先级与项目日程相关，严重性与标准相关。优先级表示须要优先考虑和注意的对象；由重要性顺序构建成优先级；严重性暗示须要严格遵守标准或者是高层原则，好比，一个严重的代码行为。优先级和严重性这2个词出如今Bug跟踪里。某种商业化的，问题跟踪及管理的软件工具是可行的。这些工具，随着测试工程师们逐条的输入，给予团队完整的信息，以至开发人员能明白Bug，明白Bug的严重性，重现它，并修复它。修复创建在优先级和严重性的基础上。严重性的问题按照客户的风险评估来定义，并记录于被选择的跟踪工具中。多Bug的软件会“严重”影响项目进度，依次也能致使对“优先级”从新评估和商榷。

@六、缺陷的类型

1）从质量特性角度考虑有功能、性能、安全性、易用性、可靠性缺陷；
  2）从功能性角度考虑有：错误（Errors）、遗漏（Missing）、多余的（Extra）、可优化的（Improvement/Enhancement/Suggestion）缺陷；
  3）从缺陷产生的缘由考虑有：需求规格说明书SRS、设计问题、编码问题、需求变动、设计变动、配置问题、测试问题

@七、缺陷的版本

1）发现缺陷的版本（必须说明）
  2）修改bug的版本
  3）回归测试的版本（通常是最新版本）

@八、缺陷修改日期

是主要对开发人员进行考核的参数。

五、缺陷报告单写做

@一、完整缺陷报告单内容

一个完整的、高质量的缺陷报告单包括三个方面：简单描述、详细描述、相关附件。

1）简单描述
     用一句简单的，提携纲领的描述清楚问题
  2）详细描述
     *1*描述问题的基本环境，包括操做系统、硬件环境、网络环境、被测试软件的运行环境
     *2*用简明扼要的语言描述清楚软件出现异常时候的测试人员的操做步骤及使用的数据
     *3*若是从GUI上能够反映出软件的异常，采用拷屏的方式截取界面，粘贴在问题单中
     *4*被测试软件运行时的相关日志文件
     *5*测试人员根据上述信息能够给出对问题简单的分析
     *6*被测试软件的版本
     *7*状态、严重级别
     *8*提交日期、提交人
  3）相关附件
     *1*GUI的拷屏图片
     *2*被测试软件运行的相关日志文件

@二、优秀缺陷跟踪单范例及分析

1）简单描述
     -Arial、Wingdings和Symbol字体会破坏新文件。
  2）详细描述
     *1*软件测试环境为windows 2000 sp4
     *2*启动WordEdit编辑器，而后建立新文件
     *3*输入四行文本，重复输入“The quick fox jumps over the lazy brown dog”
     *4*选中全部四行文本，而后选择字体下拉菜单，并选择Arial
     *5*全部文本被转换成控制字符，数字和其余明显的随机二进制数据
     *6*重复3次，结果都同样
  3）相关附件
     *1*变换格式以前的文档
     *2*变换格式以后的文档

@三、缺陷报告的写做要点

1）缺陷标题
  2）缺陷重现步骤（尽可能3次重现故障）
  3）缺陷类型
  4）缺陷优先级
  5）缺陷严重程度