软件缺陷定义

软件缺陷定义

软件缺陷概述

软件缺陷，通常又被叫做Defect或者Bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品在某种程度上不能满足用户的需要。

从产品内部看，缺陷是软件产品开发或维护过程中存在的问题、错误。

从产品外部看，缺项是系统所需要实现的某种功能的失效或违背。

软件缺陷属性

软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别（或严重等级）、缺陷产生可能性（或概率）、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源（原因）。

以上属性是为了准确描述缺陷而赋予的，这里分别作介绍：

1.缺陷标识：是标记某个缺陷的唯一标识，可以用数字序号表示；

2.缺陷类型：功能、用户界面、文档、软件包、性能、接口、兼容性等；

a)功能：影响了各种系统功能、逻辑的缺陷；

b)用户界面：影响了用户界面、人机交互特性的缺陷；

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

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

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

f)接口：与其他组件、模块、调用参数、控制块等不匹配、冲突；

g)兼容性：与工作环境、其他外设，如操作系统、浏览器、网络环境等不匹配、

冲突；

3.缺陷级别：致命、严重、一般、轻微；（举例）

a)致命：系统任何一个主要功能完全失效，用户数据受到破坏，系统崩溃、悬挂、

司机或者危机人身安全；

b)严重：系统的主要功能部分失效，数据不能保存，系统的次要功能完全丧失，

系统所提供的功能或服务受到明显影响；

c)一般：系统的次要功能没有完全实现，但不影响用户的正常使用。如提示信息

不准确或用户界面差、操作时间长等。

d)轻微：使操作者不方便或遇到麻烦，但它不影响功能的操作和执行，如个别不

影响理解的错别字、排布不整齐等。

4.缺陷产生可能性：必现、通常、有时、很少；

a)必现：按照一定路径必定出现，其产生概率为100%；

b)通常：按照测试用例（即已知步骤），通常情况下回产生这个缺陷，其产生频

率大概是80%；

c)有时：按照测试用例，有时候产生这个缺陷，其产生频率大概是30%；

d)很少：按照测试用例，很少产生这个缺陷，其产生概率大概是1%以下；实际

测试中，仅出现过一次后无法复现的缺陷也划分到此类；

e)缺陷优先级：参见“缺陷级别定义”章节；

5.缺陷状态：打开、已修复、关闭、拒绝、重复、重新打开、推迟、保留、不能重现；

（可根据实际情况增加或减少使用的缺陷状态）

a)打开：问题还没有解决，确认“提交的缺陷”，等待处理，如新报的缺陷；

b)已修复：已被开发人员检查、修复过的缺陷，通过单元测试，认为已经解决但

还没有被测试人员验证；

c)关闭：测试人员验证后，确认缺陷不存在之后的状态；

d)拒绝：开发人员认为不是缺陷；

e)重复：开发人员认为此缺陷与某打开的缺陷重复；

f)重新打开：测试人员验证后，确认缺陷仍然存在后的状态；

g)推迟：这个软件缺陷可以在下一个版本中解决；

h)保留：由于技术原因或者第三方软件的缺陷，开发人员不能修复的缺陷；

i)不能重现：开发人员不能再现这个缺陷，需要测试人员确认缺陷再现的步骤；

6.缺陷的起源：需求、架构、设计、编码、测试、用户；

在软件生命周期中，缺陷所占比例：需求和架构阶段54%、设计阶段25%、编码阶段15%、其他6%；

7.缺陷的来源：需求说明书、设计文档、系统集成接口、数据流（库）、程序代码；

a)需求说明书：需求的错误或不清楚引起的问题；

b)设计文档：设计文档描述不准确，与需求说明书不一致的问题；

c)系统集成接口：系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷；

d)数据流（库）：由于数据字典、数据库中的错误引起的缺陷；

e)程序代码：纯粹由编码引起的缺陷；

8.缺陷的根源：测试策略，过程、工具盒方法，团队/人，缺乏组织和沟通，硬件，

软件，工作环境；

a)测试策略：错误的测试范围，误解测试目标，超越测试能力等；

b)过程、工具和方法：无效的需求收集过程，过失的风险管理过程，不适用的项

目管理方法，无效的变更控制过程等；

c)团队/人：项目团队职责较差，缺乏培训，没有经验的项目团队，缺乏士气等；

d)缺乏组织和沟通：缺乏用户参与，职责不明确、管理失败等；

e)硬件：硬件配置不对、缺乏等；

f)软件：软件配置不对、缺乏，或操作系统错误导致无法释放资源，工具软件错

误，编译器错误等；

g)工作环境：组织机构调整，预算改变，工作环境恶劣等。

缺陷级别定义

按照CMM5，缺陷级别（严重等级）可分为3-5个等级，根据公司实际情况来决定缺陷级别的划分。

这里将缺陷划分为四级：致命、严重、一般、轻微。