软件缺陷定义

软件缺陷定义.png

目录

  • 1 软件缺陷概述
  • 2 软件缺陷属性
    • 2.1 缺陷标识(Identifier)
    • 2.2 缺陷类型(Type)
      • 2.2.1 功能
        • 2.2.1.1 功能类
        • 2.2.1.2 数据类
        • 2.2.1.3 流程类
        • 2.2.1.4 信息类
        • 2.2.1.5 建议类
      • 2.2.2 用户界面
        • 2.2.2.1 界面类
      • 2.2.3 文档
      • 2.2.4 软件包
      • 2.2.5 性能类
      • 2.2.6 接口
      • 2.2.7 兼容性
    • 2.3 缺陷级别(Severity)
      • 2.3.1 致命
      • 2.3.2 严重
      • 2.3.3 一般
      • 2.3.4 轻微
    • 2.4 缺陷产生可能性
      • 2.4.1 必现
      • 2.4.2 通常
      • 2.4.3 有时
      • 2.4.4 很少
    • 2.5 缺陷的优先级(Priority)
      • 2.5.1 立即解决
      • 2.5.2 高优先级
      • 2.5.3 正常排队
      • 2.5.4 低优先级
    • 2.6 缺陷状态(Status)
      • 2.6.1 打开
      • 2.6.2 已修复
      • 2.6.3 关闭
      • 2.6.4 拒绝
      • 2.6.5 重复
      • 2.6.6 重新打开
      • 2.6.7 推迟
      • 2.6.8 保留
      • 2.6.9 不能重现
    • 2.7 缺陷的起源(Origin)
      • 2.7.1 需求
      • 2.7.2 架构
      • 2.7.3 设计
      • 2.7.4 编码
      • 2.7.5 测试
      • 2.7.6 用户
    • 2.8 缺陷的来源(Source)
      • 2.8.1 需求说明书
      • 2.8.2 设计文档
      • 2.8.3 系统集成接口
      • 2.8.4 数据流(库)
      • 2.8.5 程序代码
    • 2.9 缺陷的根源(Root Cause)
      • 2.9.1 测试策略
      • 2.9.2 过程、工具和方法
      • 2.9.3 团队/人
      • 2.9.4 缺乏组织和沟通
      • 2.9.5 硬件
      • 2.9.6 软件
      • 2.9.7 工作环境

1 软件缺陷概述

软件缺陷(Defect),常常又被叫做Bug。所谓软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。

IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。

在软件开发生命周期的后期,修复检测到的软件错误的成本较高。

2 软件缺陷属性

软件缺陷的属性包括缺陷标识、缺陷类型、缺陷级别(或严重等级)、缺陷产生可能(或概率)、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷根源(原因)。
以上属性是为了准确描述缺陷而赋予的,这里分别作介绍:

2.1 缺陷标识(Identifier)

是标记某个缺陷的唯一标识,可以用数字序号表示;

2.2 缺陷类型(Type)

缺陷类型是根据缺陷的自然属性划分的缺陷种类。
功能、用户界面、文档、软件包、性能、接口、兼容性等;

2.2.1 功能

影响了各种系统功能、逻辑的缺陷;

2.2.1.1 功能类

  • 重复的功能
  • 多余的功能
  • 功能实现与设计要求不相符
  • 功能使用性、方便性、易用性不够

2.2.1.2 数据类

  • 数据有效性检测不合理
  • 数据来源不正确
  • 数据处理过程不正确
  • 数据处理结果不正确

2.2.1.3 流程类

  • 流程控制不符和要求
  • 流程实现不完整

2.2.1.4 信息类

  • 提示信息重复或出现时机不合理
  • 提示信息格式不符和要求
  • 提示框返回后焦点停留位置不合理

2.2.1.5 建议类

  • 功能性建议
  • 操作建议
  • 校检建议
  • 说明建议

2.2.2 用户界面

影响了用户界面、人机交互特性的缺陷;

2.2.2.1 界面类

  • 界面不美观
  • 控件排列、格式不统一
  • 焦点控制不合理或不全面

2.2.3 文档

影响发布和维护,包括注释、用户手册、设计文档等的缺陷;

2.2.4 软件包

由于软件配置库、变更管理或版本控制引起的错误;

2.2.5 性能类

  • 并发量

  • 数据量

  • 响应时间

  • 执行时间

  • 事务处理速率

2.2.6 接口

与其他组件、模块、调用参数、控制块等不匹配、冲突;

2.2.7 兼容性

与工作环境、其他外设,如操作系统、浏览器、网络环境等不匹配、冲突;

2.3 缺陷级别(Severity)

缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。
致命、严重、一般、轻微;(举例)

2.3.1 致命

系统任何一个主要功能完全失效,用户数据受到破坏,系统崩溃、悬挂、 司机或者危机人身安全;
示例:

  • 系统无法安装、登陆或其他主要功能 不可用
  • 死循环或内存不足等原因导致程序 无法运行
  • 由于程序引起的系统无法启动、死 机、蓝屏、非法退出
  • 在数据或安全方面存在重大问题

2.3.2 严重

系统的主要功能部分失效,数据不能保存,系统的次要功能完全丧失, 系统所提供的功能或服务受到明显影响;
示例:

  • 基本功能存在部分问题或次要功能 无法实现或遗漏
  • 未进行异常处理
  • 性能与预期相差很大

2.3.3 一般

系统的次要功能没有完全实现,但不影响用户的正常使用。如提示信息 不准确或用户界面差、操作时间长等。
示例:

  • 次要功能没有完全实现,但不影响用户使用本产品
  • 界面存在明显缺陷,设计不友好
  • 提示信息不准确
  • 一般的性能问题

2.3.4 轻微

使操作者不方便或遇到麻烦,但它不影响功能的操作和执行,如个别不影响理解的错别字、排布不整齐等。
示例:

  • 界面格式显示不规范
  • 建议性的改进要求

2.4 缺陷产生可能性

必现、通常、有时、很少;

2.4.1 必现

按照一定路径必定出现,其产生概率为100%;

2.4.2 通常

按照测试用例(即已知步骤),通常情况下回产生这个缺陷,其产生频 率大概是80%;

2.4.3 有时

按照测试用例,有时候产生这个缺陷,其产生频率大概是30%;

2.4.4 很少

按照测试用例,很少产生这个缺陷,其产生概率大概是1%以下;实际测试中,仅出现过一次后无法复现的缺陷也划分到此类;

2.5 缺陷的优先级(Priority)

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

2.5.1 立即解决

缺陷导致系统几乎不能使用或者测试不能继续,需立即修复;

2.5.2 高优先级

缺陷严重,影响测试,需要优先考虑;

2.5.3 正常排队

缺陷需要正常排队等待修复;

2.5.4 低优先级

缺陷可以在开发人员有时间的时候被纠正。

2.6 缺陷状态(Status)

缺陷状态指缺陷通过一个跟踪修复过程的进展情况。
打开、已修复、关闭、拒绝、重复、重新打开、推迟、保留、不能重现; (可根据实际情况增加或减少使用的缺陷状态)

2.6.1 打开

问题还没有解决,确认“提交的缺陷”,等待处理,如新报的缺陷;

2.6.2 已修复

已被开发人员检查、修复过的缺陷,通过单元测试,认为已经解决但 还没有被测试人员验证;

2.6.3 关闭

测试人员验证后,确认缺陷不存在之后的状态;

2.6.4 拒绝

开发人员认为不是缺陷;

2.6.5 重复

开发人员认为此缺陷与某打开的缺陷重复;

2.6.6 重新打开

测试人员验证后,确认缺陷仍然存在后的状态;

2.6.7 推迟

这个软件缺陷可以在下一个版本中解决;

2.6.8 保留

由于技术原因或者第三方软件的缺陷,开发人员不能修复的缺陷;

2.6.9 不能重现

开发人员不能再现这个缺陷,需要测试人员确认缺陷再现的步骤;

2.7 缺陷的起源(Origin)

缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。
在软件生命周期中,缺陷所占比例:需求和架构阶段54%、设计阶段25%、编码阶段15%、其他6%;

2.7.1 需求

2.7.2 架构

2.7.3 设计

2.7.4 编码

2.7.5 测试

2.7.6 用户

2.8 缺陷的来源(Source)

缺陷来源指引起缺陷的起因。

2.8.1 需求说明书

需求的错误或不清楚引起的问题;

2.8.2 设计文档

设计文档描述不准确,与需求说明书不一致的问题;

2.8.3 系统集成接口

系统各模块参数不匹配、开发组之间缺乏协调引起的缺陷;

2.8.4 数据流(库)

由于数据字典、数据库中的错误引起的缺陷;

2.8.5 程序代码

纯粹由编码引起的缺陷;

2.9 缺陷的根源(Root Cause)

缺陷根源指发生错误的根本因素。

2.9.1 测试策略

错误的测试范围,误解测试目标,超越测试能力等;

2.9.2 过程、工具和方法

无效的需求收集过程,过失的风险管理过程,不适用的项 目管理方法,无效的变更控制过程等;

2.9.3 团队/人

项目团队职责较差,缺乏培训,没有经验的项目团队,缺乏士气等;

2.9.4 缺乏组织和沟通

缺乏用户参与,职责不明确、管理失败等;

2.9.5 硬件

硬件配置不对、缺乏等;

2.9.6 软件

软件配置不对、缺乏,或操作系统错误导致无法释放资源,工具软件错误,编译器错误等;

2.9.7 工作环境

组织机构调整,预算改变,工作环境恶劣等。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,117评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,328评论 1 293
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,839评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,007评论 0 206
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,384评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,629评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,880评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,593评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,313评论 1 243
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,575评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,066评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,392评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,052评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,082评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,844评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,662评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,575评论 2 270

推荐阅读更多精彩内容