软件缺陷分类标准

软件缺陷分类标准

1. 简介

1.1 目的

本文档的目的是为本公司软件测试提供缺陷分类的标准。

1.2 范围

本文档适用于使用RUP的软件项目的软件测试活动以及同行评审活动。

1.3 文档结构

第一部分：

简介，介绍软件缺陷分类的目的，本标准的适用范围，以及在本文档中使用的词汇的解

释。

第二部分：

描述软件缺陷的属性，各种属性的分类。

第三部分：

列出本标准使用的参考文献。

第四部分：

附录

1.4 词汇表

◆软件缺陷（Software Defect）

●软件缺陷是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。

◆检测缺陷（Detected Defect）

●检测缺陷是指软件在进入用户使用之前被检测出的缺陷。

◆残留缺陷（Residual Defect ）

●残留缺陷是指软件发布后存在的缺陷，包括在用户安装前未被检测出的缺陷以及

检测出但未被修复的缺陷。

◆软件故障（SoftwareFailure）

●软件故障是指用户使用软件时，由于残留缺陷引起的软件失效症状。

2. 软件缺陷分类标准

2.1缺陷属性

缺陷标识(Identifier)：缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识

缺陷类型(Type)：缺陷类型是根据缺陷的自然属性划分的缺陷种类。

缺陷严重程度(Severity)：缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。

缺陷优先级(Priority)：缺陷的优先级指缺陷必须被修复的紧急程度。

缺陷状态(Status)：缺陷状态指缺陷通过一个跟踪修复过程的进展情况。

缺陷起源(Origin)：缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。

缺陷来源(Source)：缺陷来源指引起缺陷的起因。

缺陷根源(Root Cause)：缺陷根源指发生错误的根本因素。

2.2缺陷标识(Identifier)

缺陷标识是按照问题的复杂度来排序，类型10~40是比较简单的编码缺陷，类型50~100是比较复杂的设计缺陷。

10 –- 文档：注释、消息需求、设计类文档；

20 –- 语法：拼写、标点、打字、指令格式；

30 –- 赋值：如声明、重复命名、作用域；

40 –- 接口：过程调用、输入/输出、用户格式与其他组件、模块或设备驱动程序、调

用参数、控制块或参数列表相互影响的缺陷；

50 —打包：由于配置库、变更管理或版本控制引起的错误；

60 —数据、函数：结构、内容、逻辑、指针、循环、递归、计算、函数缺陷；

70 —用户接口：人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等

方面的缺陷；

80 —性能：不满足系统可测量的属性值，如：执行时间，事务处理速率等；

90 –- 标准：不符合各种标准的要求，如编码标准、设计符号等；

100 —系统、环境：设计、编译、配置、计时、内存、其他支持系统的问题。

2.3缺陷类型(Type)

需求缺陷：需求有误、需求逻辑错误、需求不完备、需求文档描述问题、需求更改；

设计缺陷：功能的使用对用户带来不便及不符合行业标准的问题：设计不合理、设计文档描述的问题、设计变更带来的问题；

系统结构缺陷：操作系统引用或使用错误、软件结构错误、恢复错误、执行错误、诊断错误、分割覆盖错误、引用环境错误；

测试设计与测试执行错误：测试设计错误、测试执行错误、测试文档有误、测试用例不充分、其他测试错误；

功能类缺陷：影响了各种系统功能或逻辑的缺陷、重复的功能、多余的功能、功能实现与设计要求不相符、功能使用性（方便性、易用性）不够；

性能类缺陷：不满足系统可测量的属性值，如事物处理速率、并发量、数据量、压缩率、响应时间；

系统模块接口类缺陷：与其他组件、模块、设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突；

用户界面类缺陷：影响了用户界面、人机交互特性，屏幕格式、用户输入灵活性、结果输出格式等方面的缺陷，界面不美观，控件排列、格式不统一，焦点控制不合理或不全

面；

数据处理类缺陷：数据有效性检测不合理、数据来源不正确、数据处理过程不正确；

流程类缺陷：流程控制不符合要求、流程实现不完整；

提示信息类缺陷：提示信息重复或出现时机不合理、提示信息格式不符合要求、提示框返回后焦点停留位置不合理；

软件包类缺陷：由于软件配置库、变更管理或版本控制引起的错误；

建议类缺陷：功能性建议、操作建议、校验建议、说明建议；

常识类缺陷：违背正常习俗习惯，如日期、节日等；

文档缺陷：影响发布和维护，包括注释、用户手册、设计文档。

2.4缺陷严重程度(Severity)

系统崩溃：死机、数据丢失、主要功能完全丧失、用户数据受到破坏、系统崩溃等错误。修改优先级为最高，该级别需要程序员立即修复；

严重错误：系统的主要功能部分丧失、数据不能保存、导致严重的问题或致命的错误。

修改优先级为较高，该级别需要程序员尽快修改；

次要错误：系统的部分功能没有完全实现，但不影响用户的正常使用，如提示信息不太准确或用户界面差、操作时间长等一些问题。修改优先级别为中，该级别需要程序员

修改；

不合理或别扭：微小的问题，对功能几乎没影响，产品及属性仍可使用，如有个错别字、操作者不方便。修改优先级为低，该级别需要程序员修改或不修改。

先级(Priority)

高（严重）：立即解决，缺陷导致系统几乎不能使用或测试不能继续，需要立即修复；

中（较高）：缺陷严重，影响测试，需要优先考虑；

低（一般）：正常排队缺陷需要正常排队等待修复；

无（轻微）：缺陷可以在开发人员有时间的时候被纠正。

2.5缺陷状态(Status)

新建：问题还没有解决，存在源代码中，等待处理，如新报的缺陷；

打回：测试人员验证后依然存在的缺陷，等待开发人员进一步修复；

公认：根据目前项目进程或计划等情况，暂时延期的状态，缺陷可以在下一个版本中解决。

已确认：测试人员验证过，

已分派：已经分派解决Bug的程序员；

已解决：已被程序员检查、修改过得缺陷，通过单元测试，认为已解决，但还没有被测试人员验证的状态；

已关闭：Bug完全解决了，只供以后备查的状态；

3.参考资料

《软件测试与技术》清华大学出版社2009年5月

《Mantis使用手册》