软件缺陷状态,软件缺陷状态有几种

软件缺陷的生命周期中有哪些基本状态

发现缺陷,新建缺陷,打开修复,关闭,解决问题

软件缺陷有哪些表现

常见的软件缺陷有以下四种：

第一，栈溢出。就是在栈中申请一段内存，一般是数组或字符串，在对这段内存做操作的时候，错误的写操作可能导致栈中也特殊意义的地址被用户的输入内容所控制。最早发现是一些字符串操作的函数中，比如strcat，后来又发现在Strncpy如果不正常操作的话也会出现这个问题。最后有一个Windows UNicode处理的函数如果不正常使用也会出现这样的问题。下面介绍的是整数溢出的问题。

整数溢出是多发于的情况，特别是一些加、乘的操作出现在内存前面就要特别注意了。加或者乘出来的数不一定比原先两个数大。还有一个正负数比较的问题，或者是符号扩展的问题。即使现在这个问题仍存在于很多软件中。但是在很多流行软件中已经很少出现了，比如微软的软件、国外大公司的软件。但是在国内软件这个问题依然是很多的。这个问题在JAVA软件中也经常存在。例如银行系统，系统错误处理，把别人帐号上扣掉的金额，一个正的金额加到你的帐号上。

第二， heap overflow。这是现代程序C语言主要申请分配方法，所以他比栈溢出比例大的多。微软做了很多防护措施，所以它利用起来是非常复杂的。尤其是 WindowsXP2之后的版本，比如vista。堆管理主要利用两张表，freelist、lookaside，freelist[0]代表着一些不规则的可以利用的chunk，尤其是比较大的chunk。freelist[1] – freelist[n]代表2的整数次方可以利用的堆中的chunk。利用这样堆溢出的问题，你需要对Windows堆管理非常熟悉。比如有人通过 freelist[0]这个链表成功利用。目前有一个immdbg的程序对这种研究利用是很有帮助的。因为他把堆分配的内容都可以显示出来。对vista 软件的攻击，理论上应该是不存在的。因为vista对堆管理有严格控制，但是有很多软件使用自己的内存管理方法，比如OFFICE，他们自己堆管理方法和内存方法是和vista不一样的，这些方法往往采用教科书的方法或者以前系统的方法，所以他们这些方法是有可能被利用起来。

第三，未初始化的问题。栈上的问题由德国人在06年详细讨论过。头一次压栈的时候，在栈上写需要内容，然后函数退出，导致栈顶上移，有问题的函数压栈时正好利用这段栈空间，如果函数中发现了未初始化问题，比如数组，那么其内容刚好是我们刚写入的内容的栈空间，就可能被利用。先把堆里的大部分内容写成自己需要的内容，未初始问题发生时，比如堆里指针的内容就可能指向我们需要的内容。目前这个问题是大量存在的，OFFICE存在了很多。比如这个月微软补丁，excel那一个补丁里就包括很多这样的问题。你可以对比新旧的OFFICE软件，你发现 OFFICE2007有一些新加的代码就是做初始化工作的。

第四，二次释放或者叫double free问题。内存泄露是现代软件大敌，特别是服务器软件。有很多程序员害怕发生这样的问题，申请内存时总是想释放它，结果释放多了几次，这样也会有安全问题。曾经在linux上的方法很巧妙、经典，但是在目前Windows上比较难以利用。很多软件采用自己管理内存方法，那么就很可能被利用到。

软件缺陷分类的标准

软件缺陷(software defect)分类标准缺陷属性属性名称描述缺陷标识(Identifier) 缺陷标识是标记某个缺陷的一组符号。每个缺陷必须有一个唯一的标识缺陷类型 (Type) 缺陷类型是根据缺陷的自然属性划分的缺陷种类。缺陷严重程度 (Severity) 缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度。缺陷优先级(Priority) 缺陷的优先级指缺陷必须被修复的紧急程度。缺陷状态(Status) 缺陷状态指缺陷通过一个跟踪修复过程的进展情况。缺陷起源(Origin) 缺陷来源指缺陷引起的故障或事件第一次被检测到的阶段。缺陷来源(Source) 缺陷来源指引起缺陷的起因。缺陷根源(Root Cause) 缺陷根源指发生错误的根本因素。缺陷类型（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 不符合各种标准的要求，如编码标准、设计符号等。缺陷严重程度（Severity）1.3.1 软件测试错误严重程度 # 缺陷严重等级描述 1 Critical 不能执行正常工作功能或重要功能。或者危及人身安全。 2 Major 严重地影响系统要求或基本功能的实现，且没有办法更正。（重新安装或重新启动该软件不属于更正办法） 3 Minor 严重地影响系统要求或基本功能的实现，但存在合理的更正办法。（重新安装或重新启动该软件不属于更正办法） 4 Cosmetic 使操作者不方便或遇到麻烦，但它不影响执行工作功能或重要功能。 5 Other 其它错误。1.3.2 同行评审错误严重程度 # 缺陷严重等级描述 Major 主要的，较大的缺陷 Minor 次要的，小的缺陷缺陷优先级（Priority）# 缺陷优先级描述 1 Resolve Immediately 缺陷必须被立即解决。 2 Normal Queue 缺陷需要正常排队等待修复或列入软件发布清单。 3 Not Urgent 缺陷可以在方便时被纠正。缺陷状态（Status）缺陷状态描述 Submitted 已提交的缺陷 Open 确认“提交的缺陷”，等待处理 Rejected 拒绝“提交的缺陷”，不需要修复或不是缺陷 Resolved 缺陷被修复 Closed 确认被修复的缺陷，将其关闭缺陷起源（Origin）缺陷起源描述 Requirement 在需求阶段发现的缺陷 Architecture 在构架阶段发现的缺陷 Design 在设计阶段发现的缺陷 Code 在编码阶段发现的缺陷 Test 在测试阶段发现的缺陷缺陷来源（Source）缺陷来源描述Requirement：由于需求的问题引起的缺陷 Architecture：由于构架的问题引起的缺陷Design：由于设计的问题引起的缺陷 Code：由于编码的问题引起的缺陷Test：由于测试的问题引起的缺陷 Integration：由于集成的问题引起的缺陷

复杂的软件缺陷包括哪六个生命状态?

缺陷报告需要包含的内容包括:标题、前提、测试环境、操作步骤、期望结果、实际结果和出现的频率这些基本内容,另外还应该包含缺陷的严重级和优先级等其他的内容.

什么是Bug等级及严重程序

缺陷状态：

致命的软件缺陷(Blocker):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等

严重错误的软件缺陷（Major）：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件

一般错误的软件缺陷（normal）：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等

较小错误的软件缺陷（Minor）：使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范（字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志），辅助说明描述不清楚

建议问题的软件缺陷（Enhancemental）：由问题提出人对测试对象的改进意见或测试人员提出的建议、质疑。

在td中修改缺陷状态字段转换规则,缺陷状态字段有几种状态

在实际的软件缺陷管理中,需要实现以下要求: 1、测试人员只能修改缺陷状态为:new–>open,fixed–>closed,fiexed–>reopen 2、开发人员只能修改缺陷状态为:open–>fiexd,open–>rejected 以上状态转换,可以根据实际需要进行定制!

在软件测试中,哪些软件问题被称为软件缺陷

一.软件缺陷的正式定义: 符合下边5个规则的才能叫做软件缺陷. 1.软件未达到产品说明书标明的功能. 2.软件出现了产品说明书指明不会出现的错误. 3.软件功能超出产品说明书指明范围. 4.软件未达到产品说明书虽未指出但应达到的目标. 5.软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好. 参考 http://www.spasvo.com/baike/504.html

软件缺陷分析方法有哪些

已经修改的错误重复出现; 无法清晰的描述当前版本的缺陷状态; 对测试中发现的问题,主要依靠记忆得方式来记录;能记录的数量有限,并且经常遗忘; 采用了记录单或问题表单的方式来记录缺陷,但只是简单的记录了错误内容,没有分析和流程跟踪能力; 研发经验教训得不到继承,重复同样的错误; 缺陷跟踪管理系统可以规范项目中开发、测试、缺陷处理的流程.