织雀教育软件缺陷管理.doc

软件缺陷管理
想获取更多测试资料，请访问织雀教育官网。
认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。
1、首先介绍软件缺陷的概念
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
2、软件缺陷的详细特征
a、单一准确
b、可以再现（要求软件缺陷具有精确的步骤）
c、完整统一
d、短小简练
e、特定条件
f、补充完整
g、不做评价
3、软件缺陷的属性
软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源缺陷原因。
下面详细介绍一下以上这些属性：
a、缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；
b、缺陷类型：功能、用户界面、文档、软件包、性能、系统"模块接口
功能：影响了各种系统功能、逻辑的缺陷；
用户界面：影响了用户界面、人机交互特性，包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷；
文档：影响发布和维护，包括注释、用户手册、设计文档；
软件包：由于软件配置库、变更管理或版本控制引起的错误；
性能：不满足系统可测量的属性值，如执行时间、事务处理速率等；
系统"模块接口：与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
c、缺陷严重程度：致命（Fatal）、严重（Ceritical）、一般（Major）、较小（Minor）
致命：系统任何一个主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机或者危机人身安全；
严重：系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响；
一般：系统的次要功能没有完全实现，但不影响用户的正常使用。例如：提示信息不太准确或用户界面差、操作时间长等一些问题；
较小：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
d、缺陷产生可能性：总是、通常、有时、很少
总是：总是产生这个软件缺陷，其产生的频率是100；
通常：按照测试用例，通常情况下会产生这个软件缺陷，其产生的频率大概是80—90；
有时：按照测试用例，有时候产生这个软件缺陷，其产生的频率大概是30—50；
很少：按照测试用例，很少产生这个软件缺陷，其产生的频率大概是1—5.
e、缺陷的优先级：立即解决、高优先级、正常排队、低优先级
立即解决：缺陷导致系统几乎不能使用或者测试不能继续，需立即修复；
高优先级：缺陷严重，影响测试，需要优先考虑；
正常排队：缺陷需要正常排队等待修复；
低优先级：缺陷可以再开发人员有时间的时候被纠正。
f、缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息
激活或打开：问题还没有解决，存在源代码中，确认”提交的缺陷”，等待处理，如新报的缺陷；
已修正或修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但还没有被测试人员验证；
关闭或非激活：测试人员验证后，确认缺陷不存在之后的状态；
重新打开：测试人员验证后，确认缺陷不存在之后的状态；
推迟：这个软件缺陷可以在下一个版本中解决；
保留：由于技术原因或第三者软件的缺陷，开发人员不能修复的缺陷；
不能重现：开发不能再现这个软件缺陷，需要测试人员检查缺陷再现的步骤；
需要更多信息：开发能再现这个软件缺陷，但开发人员需要一些信息，例如缺陷的日志文件、图片等。
g、软件缺陷的起源：需求、构架、设计、编码、测试、用户
在团建生命周期中软件缺陷占的比例：需求和构架设计阶段占54、设计阶段占25、编码阶段占15、其他占6.
h、软件缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码
需求说明书：需求说明书的错误或不清楚引起的问题；
设计文档：设计文档描述不准确。和需求说明书不一致的问题；
系统集成接口：系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷；
数据流（库）：由于数据字典、数据库中的错误引起的缺陷；
程序代码：纯粹在编码中的问题所引起的缺陷。
i、缺陷根源：测试策略，过程、工具和方法，团队"人，缺乏组织和通讯，硬件，软件，工作环境
测试策略：错误的测试范围，误解测试目标，超越测试能力等；
过程、工具和方法：无效的需求收集过程，果实的风险管理过程，不使用的项目管理方法，没有估算规程，无效的变更控制过程等；
团队"人：项目团队职责交叉，缺乏培训。没有经验的项目团队，缺乏士气和动机不纯等；
缺乏组织和通讯：缺乏用户参与，职责不明确、管理失败等；
硬件：硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失，内存溢出等；
软件：软件设置不对、缺乏，或操作系统错误导致无法释放资源，工具软件的错误，编译器的错误，千年虫问题等；
工作环境：组织机构调整，预算改变，工作环境恶劣，如噪音过大。
4、学会利用管理缺陷的工具
例如TD、bugfree、bugzille等
软件缺陷(software defect)是对软件产品预期属性的偏离现象。它包括检测缺陷和残留缺陷。每一个软件组织都知道必须妥善处理软件中的缺陷。这是关系到软件组织生存、发展的质量根本。
一、软件缺陷(software defect)分类标准
1.1 缺陷属性
属性名称 描述
缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识
缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。
缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。
缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
缺陷来源(Source) 缺陷来源指引起缺陷的起因。
缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。

1.2 缺陷类型（Type）
缺陷类型编号 缺陷类型 描述
10 F- Function 影响了重要的特性、用户界面、产品接口、硬件结构接口和全局数据结构。并且设计文档需要正式的变更。如逻辑，指针，循环，递归，功能等缺陷。
20 A- Assignment 需要修改少量代码，如初始化或控制块。如声明、重复命名，范围、限定等缺陷。
30 I- Interface 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷。
40 C- Checking 提示的错误信息，不适当的数据验证等缺陷。
50 B Build/package/merge 由于配置库、变更管理或版本控制引起的错误。
60 D- Documentation 影响发布和维护，包括注释。
70 G- Algorithm 算法错误。
80 U-User Interface 人机交互特性：屏幕格式，确认用户输入，功能有效性，页面排版等方面的缺陷。
90 P-Performance 不满足系统可测量的属性值，如：执行时间，事务处理速率等。
100 N-Norms 不符合各种标准的要求，如编码标准、设计符号等。
1.3 缺陷严重程度（Severity）
1.3.1 软件测试错误严重程度
# 缺陷严重等级 描述
1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。
2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法）
3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5 Other 其它错误。
1.3.2 同行评审错误严重程度
# 缺陷严重等级 描述
Major 主要的，较大的缺陷
Minor 次要的，小的缺陷

1.4 缺陷优先级（Priority）
# 缺陷优先级 描述
1 Resolve Immediately 缺陷必须被立即解决。
2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。
3 Not Urgent 缺陷可以在方便时被纠正。

1.5 缺陷状态（Status）
缺陷状态 描述
Submitted 已提交的缺陷
Open 确认“提交的缺陷”，等待处理
Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷
Resolved 缺陷被修复
Closed 确认被修复的缺陷，将其关闭

1.6 缺陷起源（Origin）
缺陷起源 描述
Requirement 在需求阶段发现的缺陷
Architecture 在构架阶段发现的缺陷
Design 在设计阶段发现的缺陷
Code 在编码阶段发现的缺陷
Test 在测试阶段发现的缺陷

1.7 缺陷来源（Source）
缺陷来源 描述
Requirement 由于需求的问题引起的缺陷
Architecture 由于构架的问题引起的缺陷
Design 由于设计的问题引起的缺陷
Code 由于编码的问题引起的缺陷
Test 由于测试的问题引起的缺陷
Integration 由于集成的问题引起的缺陷
1.8 缺陷根源（Root Cause）

软件缺陷(software defect)管理指南

1、如何收集缺陷
缺陷既指程序中存在的错误，例如语法错误、拼写错误或者是一个正确的程序语句，缺陷也指可能出现在设计中，甚至在需求、规格说明或其他的文档中的种种错误。为了对缺陷进行管理，首先应对缺陷进行分类，通过对缺陷进行分类，可以迅速找出哪一类缺陷的问题最大，然后集中精力预防和排除这一类缺陷。而这正是缺陷管理的关键，一旦这几类缺陷得到控制，再进一步找到新的容易引起问题的几类缺陷上。

1．1 缺陷类型
缺陷类
型编号 缺陷类型 描述
10 F-功能 如逻辑,指针,循环,递归,功能等缺陷
20 G-语法 拼写、标点符号、打字
30 A-赋值 如声明、重复命名，作用域
40 I-接口 与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷
50 B-联编打包 由于配置库、变更管理或版本控制引起的错误
60 D-文档 需求、设计类文档
70 U-用户接口 人机交互特性：屏幕格式，确认用户输入，功能有效性
80 P-性能 不满足系统可测量的属性值，如：执行时间，事务处理速率等
90 N-标准 不符合各种标准的要求，如编码标准、设计符号等
100 E-环境 设计、编译、其他支持系统问题
1．2 了解缺陷
缺陷管理的第一步是了解缺陷，为此，必须首先收集缺陷数据，然后才能了解这些缺陷，并且找出如何预防它们，同时也能领会到如何更好地发现，修复甚至预防仍在引入的缺陷。可以按照以下步骤收集关于缺陷的数据：
◆ 为测试和同行评审中发现的每一个缺陷做一个记录
◆ 对每个缺陷要记录足够详细的信息，以便以后能更好地了解这个缺陷
◆ 分析这些数据以找出主要哪些缺陷类型引起大部分的问题
◆ 设计出发现和修复这些缺陷的方法（缺陷排除）
通常为了收集缺陷数据，可以采用缺陷记录日志来登记所发现的每一个缺陷
日期 编号 状态 类型 缺陷来源 排除阶段 修改时间 修复缺陷

描述：

描述：

描述：
对于缺陷记录日志中的描述应该足够清楚，以便今后可以看出该缺陷的起因。修复缺陷一栏说明此缺陷是由于修复其他缺陷而引入的。引入阶级表示该缺陷的来源，缺陷的来源可以分为以下几类：
缺陷来源 描述
Requirement 由于需求的问题引起的缺陷
Architecture 由于构架的问题引起的缺陷
Design 由于设计的问题引起的缺陷
Code 由于编码的问题引起的缺陷
Test 由于测试的问题引起的缺陷
Integration 由于集成的问题引起的缺陷
排除阶级表示发现和修复这个缺陷的阶级，通常分为如下：
排除阶段 描述
Requirement 在需求阶段发现的缺陷
Architecture 在构架阶段发现的缺陷
Design 在设计阶段发现的缺陷
Code 在编码阶段发现的缺陷
Test 在测试阶段发现的缺陷
2、如何分析和统计缺陷
为了更好地分析缺陷，需要对缺陷在严重程度、优先级以及状态上加以区分。

2．1 缺陷严重程度
# 缺陷严重等级 描述
1 严重缺陷（Critical） 不能执行正常工作功能或重要功能。或者危及人身安全
2 较大缺陷（Major） 严重地影响系统要求或基本功能的实现，且没有办法更正。
（重新安装或重新启动该软件不属于更正办法）
3 较小缺陷（Minor） 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法）
4 轻微缺陷（Cosmetic） 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。
5 其他缺陷（Other） 其它错误
2．2 解决优先级（Priority）
# 解决优先级 描述
1 立即解决
（Resolve Immediately） 缺陷必须被立即解决。
2 正常排队
（Normal Queue） 缺陷需要正常排队等待修复或列入软件发布清单。
3 不紧急
（Not Urgent） 缺陷可以在方便时被纠正。
6