软件 缺陷类型 有哪些
冗余代码多 兼容性差 可操作性差 界面不友好 与需求不一致 可扩展性差
软件缺陷包括哪些内容?
软件危机是计算机软件在它的开发和维护中所遇到的一系列严重问题 软件缺陷是不是软件开发存在的问题 是客户使用过程中出现的问题 主要有:软件成本和进度的估计常常很不准确 用户对“已经完成的”软件系统不满意 软件产品的质量靠不住 软件是不可维护的 软件没有适当的文档资料 软件成本在计算机系统总成本中所占的比例逐年上升
软件的缺陷等级应如何划分?
补充相关方面：A类—严重错误，包括以下各种错误： 1． 由于程序所引起的死机,非法退出 2． 死循环 3． 数据库发生死锁 4． 因错误操作导致的程序中断 5． 功能错误 6． 与数据库连接错误 7． 数据通讯错误 B类—较严重错误，包括以下各种错误： 1． 程序错误 2． 程序接口错误 3． 数据库的表、业务规则、缺省值未加完整性等约束条件C类—一般性错误，包括以下各种错误： 1． 操作界面错误（包括数据窗口内列名定义、含义是否一致） 2． 打印内容、格式错误 3． 简单的输入限制未放在前台进行控制 4． 删除操作未给出提示 5． 数据库表中有过多的空字段D类—较小错误，包括以下各种错误： 1． 界面不规范 2． 辅助说明描述不清楚 3． 输入输出不规范 4． 长操作未给用户提示 5． 提示窗口文字未采用行业术语 6． 可输入区域和只读区域没有明显的区分标志
软件缺陷分类的标准
软件缺陷(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： 由于集成的问题引起的缺陷
软件缺陷有哪些表现
常见的软件缺陷有以下四种：
第一，栈溢出。就是在栈中申请一段内存，一般是数组或字符串，在对这段内存做操作的时候，错误的写操作可能导致栈中也特殊意义的地址被用户的输入内容所控制。最早发现是一些字符串操作的函数中，比如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上比较难以利用。很多软件采用自己管理内存方法，那么就很可能被利用到。
列举你使用的软件的缺陷有哪些
优点是针对性强,方便快捷.缺点是使用的人少没有破解版,价格昂贵
软件缺陷的简介
软件缺陷(Defect),常常又被叫做Bug.所谓软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷.缺陷的存在会导致软件产品在某种程度上不能满足用户的需要.IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背.在软件开发生命周期的后期,修复检测到的软件错误的成本较高.
软件缺陷（ Software Bug ）的具体含义包括几个因素
软件缺陷：
软件未达到产品设计规范表明的功能；
软件出现了产品设计规范指明不会出现的错误；
软件功能超出产品设计规范指明的范围；
软件未达到产品设计规范虽未指出但应达到的目标；
软件测试人员认为软件难以理解、不易使用、运行速度慢，或者最终用户认为不好。
你应该也想知道软件错误吧
计算、观察、测量的值或条件与实际的、规定的或理论上的值或条件不符合；
导致产生含有缺陷的软件的人为行动。
例如，遗漏或误解软件说明书中的用户需求，不正确的翻译或遗漏设计规格说明书中的需求。
上面的统称软件故障
提交高质量的软件缺陷记录，你们使用CQ吗，还是buglist，觉得故障定级要准确，对于随机性出现的错误一定要做好记录，这个最好截图，有些错误真的就出现一次，如果条件允许，你出故障的时候，比如一级故障，截个图，就可以叫研发人员过来看，然后注意老员工的提交记录，学习他们的规范和思考方式，特别要和研发人员保持好关系，否则别人直接无视你的报告，如果你是女的还好，别人不好意思说你，你是男的，直接藐视了，特别注意不要提太多的bug，写bug记录的时候也要站在研发的角度，提出解决方法，建议他们作修改，我的一些个人意见，希望对你有帮助。
举例说下软件缺陷等级
缺陷严重级别定义:
o 最高级–导致运行中断(应用程序崩溃),预期的功能没有得到实现,测试工作无法继续进行等.
o 紧急—事件非常重要,并且需要马上给予关注.
o 高级—事件是重要的,并且应该在紧急的事件处理之后尽快得到解决.
o 中级—事件是重要的,但是由于解决问题需要花费一定的时间,所以可以用较长的时间解决.
o 低级—事件不重要,可以在时间和资源允许的情况下再解决.
o 建议性缺陷.
更为详细的划分如下:
A类——严重错误，包括：
o 由于程序所引起的死机,非法退出
o 死循环
o 导致数据库发生死锁
o 数据通讯错误
o 严重的数值计算错误
B类——较严重错误，包括：
o 功能不符
o 数据流错误
o 程序接口错误
o 轻微的数值计算错误
C类——一般性错误，包括：
o 界面错误(详细文档)
o 打印内容、格式错误
o 简单的输入限制未放在前台进行控制
o 删除操作未给出提示
D类——较小错误，包括：
o 辅助说明描述不清楚
o 显示格式不规范
o 长时间操作未给用户进度提示
o 提示窗口文字未采用行业术语
o 可输入区域和只读区域没有明显的区分标志
o 系统处理未优化
E类——测试建议（非缺陷）
什么叫做软件缺陷啊？
软件漏洞 被安装了后门 也就是木马程序可以利用的漏洞`
一般我们都认为测出一个问题就是一个bug，其实这是不对的，假设测试10个问题就10个bug，而修改一出就全解决了，程序员肯定认为冤枉自己。
所有软件是文档，代码等组成的，最初的错误是来自于这些软件错误(software error)，如代码中加法写成减法。软件错误导致软件缺陷(software defect)，如设计缺陷，代码缺陷等，可用静态测试，如走查，静态检查，测试床（军事软件用的技术）等，软件的缺陷导致一个或多个软件故障 (software fault)，故障有内部故障，外部故障，也就是我们所说的bug，软件故障导致了软件在功能操作等方面的失效(software failure)。
我们平时测的bug实际上是软件故障于失效的体现。一旦软件错误得到修改，相应的故障与失效也就解除了。这样分有助于我们定位问题，找到问题。
详见《软件可靠性工程》
