软件缺陷管理基本概念

mowuhen

软件缺陷管理基本概念


认识软件缺陷，首先要了解软件缺陷的概念，其次是了解软件缺陷的详细特征，最后就是它的属性了，再高一个层次就是学习利用管理软件缺陷的工具了。
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等

yslin1128

楼主关于软件缺陷的定义不是很准确哦
软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
对于界面之类的一般缺陷，并不影响实现其功能啊，但是能不叫它“缺陷”
不过还是很感谢楼主共享啊

jiuquanzi

Thanks for the sharing.

scarlett

我觉得缺陷的生命周期和软件的生命周期一样。它随软件的产生而产生。所以从软件一开始，调研，需求分析，概要设计，详细设计，编码，测试，运行。。。就要进行相应的缺陷管理。

只有当我们知道bug的形成才知道该如何去预防。

我刚接触bug的时候。最先看的是《产品质量的基石——微软Bug管理》【http://bugfree.newsky.cn/zhenfei/Document/BugFree.htm】这篇文章。觉得写的很不错。
看过几遍以后。就对bug的一些基本概念都很清楚了。