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

司格特

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

2、软件缺陷管理基本流程
下图是一个简单的BUG跟踪流程图：
  1）椭圆形中标示的都是角色（测试人员、BUILDER人员、开发人员、专家会诊）
  2）柱状图1：发布服务器，一般存放当前最新的软件版本
     柱状图2：RAID/BMS，是Bug的管理系统，测试人员发现问题都要提交到这个系统上
     柱状图3：邮件服务器，测试人员、BUILDER人员、开发人员、专家之间发邮件进行交流。
3、软件缺陷管理的目的
  1）保证信息的一致性；
  2）保证缺陷得到有效的跟踪和解决，缩短沟通时间，解决问题更高效；
  3）获取正确的Bug信息，利于缺陷分析、产品度量，使项目情况可视化加强。
4、软件缺陷的相关属性
@1、缺陷发现人
在提交缺陷的时候，测试人员一般是测试的发现人，便于统计分析测试人员的能力，方便公司进行
绩效考核。
@2、缺陷发现时间
缺陷发现时间是一个统计的计数点，或者数据点，便于企业负责人选择合适的产品发布时间。
@3、软件缺陷的状态
  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状态。
@/4、缺陷的严重程度(Severity)
是站在用户的角度，指Bug出现后对用户和系统的影响程度。
软件缺陷的严重性指软件缺陷对软件质量的破坏程度，即软件缺陷的存在对软件的功能和性能产生
怎样的影响，我们可以简单地将软件缺陷的严重性划分为4个等级：致命、严重、一般、提示。
  1）致命缺陷：例如软件的意外退出甚至操作系统崩溃，造成数据丢失。
  2）严重缺陷：系统无法满足基本的商业要求且没有便捷可用的工作区。性能、功能或使用方面严
重不达标，例如由于单功能失效引起多个功能失效。
  3）一般缺陷：系统能够满足商业要求。有快捷方便的工作区可供使用。性能、功能或使用方面并
不是严重不达标，例如软件单个功能失效。
  4）提示：微小修改，希望提出建议，最好能够修正，但不是必需的。在发布准确性或实用性方面
不会产生重大影响
@5、缺陷的优先级（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的软件会“严重”影响项目进度，依次也能导致对“优
先级”重新评估和商榷。
@6、缺陷的类型
  1）从质量特性角度考虑有功能、性能、安全性、易用性、可靠性缺陷；
  2）从功能性角度考虑有：错误（Errors）、遗漏（Missing）、多余的（Extra）、可优化的（Impro
vement/Enhancement/Suggestion）缺陷；
  3）从缺陷产生的原因考虑有：需求规格说明书SRS、设计问题、编码问题、需求变更、设计变更、
配置问题、测试问题
@7、缺陷的版本
  1）发现缺陷的版本（必须说明）
  2）修改bug的版本
  3）回归测试的版本（一般是最新版本）
@8、缺陷修改日期
是主要对开发人员进行考核的参数。
5、缺陷报告单写作
@1、完整缺陷报告单内容
一个完整的、高质量的缺陷报告单包括三个方面：简单描述、详细描述、相关附件。
  1）简单描述
     用一句简单的，提携纲领的描述清楚问题
  2）详细描述
     *1*描述问题的基本环境，包括操作系统、硬件环境、网络环境、被测试软件的运行环境
     *2*用简明扼要的语言描述清楚软件出现异常时候的测试人员的操作步骤及使用的数据
     *3*如果从GUI上可以反映出软件的异常，采用拷屏的方式截取界面，粘贴在问题单中
     *4*被测试软件运行时的相关日志文件
     *5*测试人员根据上述信息可以给出对问题简单的分析
     *6*被测试软件的版本
     *7*状态、严重级别
     *8*提交日期、提交人
  3）相关附件
     *1*GUI的拷屏图片
     *2*被测试软件运行的相关日志文件
@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*变换格式之后的文档
@3、缺陷报告的写作要点
  1）缺陷标题
  2）缺陷重现步骤（尽量3次重现故障）
  3）缺陷类型
  4）缺陷优先级
  5）缺陷严重程度