软件缺陷分类和预防分析

• 软件缺陷分析

• 软件缺陷分析

1、软件缺陷的属性

表 1软件缺陷的属性

属性名称	描述
缺陷标识（id）	每个缺陷必须有一个唯一的标识，缺陷标识是标记某个缺陷的一组符号
缺陷类型（type）	缺陷类型是根据缺陷的自然属性划分的缺陷种类
缺陷严重程度（severity）	缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度
缺陷优先级（priority）	缺陷的优先级指缺陷必须被修复的紧急程度
缺陷状态（status）	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
缺陷起源（origin）	缺陷起源指缺陷引起的故障或事件第一次呗检测到的阶段
缺陷来源（source）	缺陷来源指缺陷产生的原由
缺陷根源（root cause）	缺陷根源指发生错误的根本因素

1. 软件缺陷的严重程度分析

对于缺陷的严重性，如果分为4级，则可以参考下面的方法确定：

（1）致命。如，软件的意外退出甚至操作系统崩溃，造成数据丢失；

（2）严重。如，软件的某个菜单不起作用或者产生错误的结果；

（3）一般。如，本地化软件的某些字符没有翻译或者翻译不准确；

（4）微小。如：某个控件没有对齐，某个标点符号丢失等。

1. 缺陷的状态

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

缺陷状态：激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息、重复、不是缺陷、需要修改软件规格说明书。

4、软件缺陷的产生原因分析

软件缺陷的第一大来源是产品说明书。产品说明书中具体描述了软件功能、操作、性能等规格，是开发人员在开发过程中的记录，是后期测试软件的重要依据。但是在许多情况下，项目根本没有需求说明书，项目负责人仅仅再跟客户沟通之后，通过一些邮件、会谈纪录或一些零碎的未整理的话，就确信大家已经完全理解了客户的需求了。却并未形成正规的文档，这肯定会产生大量的缺陷；也可能是说明书虽然有，但是描述不清晰、不准确导致设计目标与客户的需求不符，从而引起软件在功能上以及其他方面的缺陷；或者需求频繁变更，却与开发人员缺少及时沟通，导致开发人员不清楚应该做什么和不做什么的理解误差造成的。

缺陷的第二大来源是设计。设计软件需求环节是程序员规划软件的过程，就像盖房子打地基打框架一样，系统结构越来越复杂，而程序员可能限于自身的思维局限或技术局限，无法设计出一个很好地层次结构或组件结构，导致概要设计、详细设计、数据库设计文档等存在错误或不清晰，导致最后出现意料之外的问题或系统维护、功能扩充上的困难。为软件做设计是极其重要的，需要功底深厚的架构人员去做，如果底层架构出错了，软件缺陷就会大片地出现，而且该动起来尤为复杂，牵一发而动全身

第三来源才是程序代码。任何人在编程时都可能疏忽犯错，导致程序中有缺陷。除此之外，也有可能是因为如案件太过复杂，技术文档又普遍比较糟糕，文档本身就有缺陷，导致根据文档编写的代码产生更多的缺陷，另外人们也常处于进度的压力之下，匆忙之下也容易产生缺陷，实际上也是由于产品说明书或设计方案造成的,例如需求变更了却没人及时通知开发人员。

第四大来源是其他。硬件或软件可能存在错误；不同开发人员测试人员的不同理解产生了“缺陷”；以及同一问题引起不同位置的重复缺陷等。当然事实上这部分缺陷只占极小的比例，不需要过度注意。

图 1缺陷来源统计图

5、缺陷产生可能性

（1）总是：软件总是会产生这个缺陷，这种缺陷发生的频率是将近100%；

（2）通常：根据网络一般统计，通常情况下会产生这个软件缺陷，这种缺陷发生的频率在80%—90%；

（3）有时：根据网络一般统计，有时会产生这个软件缺陷，这种缺陷发生的频率是30%—50%；

（4）很少：根据网络一般统计，几乎不会发生这个软件缺陷，这种缺陷发生的频率低至1%—5%。