常见的软件缺陷有以下四种:
第一,栈溢出。就是在栈中申请一段内存,一般是数组或字符串,在对这段内存做操作的时候,错误的写操作可能导致栈中也特殊意义的地址被用户的输入内容所控制。最早发现是一些字符串操作的函数中,比如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上比较难以利用。很多软件采用自己管理内存方法,那么就很可能被利用到。
用户操作不当跟软件自身缺陷,那个是漏洞产生的主要原因
一般都是说软件自身缺陷
因为用户的行为不可控
所以,
漏洞在所难免,只能是不断打补丁!
软件测试 缺陷报告都要包括什么内容
缺陷报告:
项目:
测试策略 方法
用例
时间
测试环境 系统配置
测试人员 提交BUG 数量 ,等级,BUG的走势
每天的BUG数据
BUG 的状态 多少打开,多少关闭各种状态
系统还存在的问题。和以后可能有的问题
软件缺陷的构成
从软件测试观点出发,软件缺陷有以下五大类: (1)规格说明书缺陷:规格说明书可能不完全,有二义性或自身矛盾。另外,在设计过程中可能修改功能,如果不能紧跟这种变化并及时修改规格说明书,则产生规格说明书错误。 功 规格说明书 404 能 功能 147 缺 测试 7 陷 总计 558 27% (2)功能缺陷:程序实现的功能与用户要求的不一致。这常常是由于规格说明书包含错误的功能、多余的功能或遗漏的功能所致。在发现和改正这些缺陷的过程中又可能引入新的缺陷。
(3)测试缺陷:软件测试的设计与实施发生错误。特别是系统级的功能测试,要求复杂的测试环境和数据库支持,还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外,如果测试人员对系统缺乏了解,或对规格说明书做了错误的解释,也会发生许多错误。
(4)测试标准引起的缺陷:对软件测试的标准要选择适当,若测试标准太复杂,则导致测试过程出错的可能就大。 ◆外部接口缺陷:外部接口是指如终端、打印机、通信线路等系统与外部环境通讯的手段。所有外部接口之间、人与机器之间的通讯都使用形式的或非形式的专门协议。如果协议有错,或太复杂,难以理解,致使在使用中出错。此外,还包括对输入/输出格式错误理解,对输入数据不合理的容错等。 内部接口 29 系 硬件 63 统 操作系统 2 缺 软件结构 193 陷 控制与顺序 43 资源 8 总计 338 16% ◆内部接口缺陷:内部接口是指程序内部子系统或模块之间的联系。它所发生的缺陷与外部接口相同,只是与程序内实现的细节有关,如设计协议错、输入/输出格式错、数据保护不可靠、子程序访问错等。
◆硬件结构缺陷:与硬件结构有关的软件缺陷在于不能正确的理解硬件如何工作。如忽视或错误地理解分页机构、地址生成、通道容量、I/O指令、中断处理、设备初始化和启动等而导致的出错。
◆操作系统缺陷:与操作系统有关的软件缺陷在于不了解操作系统的工作机制而导致出错。当然,操作系统本身也有缺陷,但是一般用户很难发现这种缺陷。
◆软件结构缺陷:由于软件结构不合理而产生的缺陷。这种缺陷通常与系统的负载有关,而且往往在系统满载时才出现。如错误地设置局部参数或全局参数;错误地假定寄存器与存储器单元初始化了;错误地假定被调用子程序常驻内存或非常驻内存等,都将导致软件出错。
◆控制与顺序缺陷:如忽视了时间因素而破坏了事件的顺序;等待一个不可能发生的条件;漏掉先决条件;规定错误的优先级或程序状态;漏掉处理步骤;存在不正确的处理步骤或多余的处理步骤等。
◆资源管理缺陷:由于不正确地使用资源而产生的缺陷。如使用未经获准的资源;使用后未释放资源;资源死锁;把资源链接到错误的队列中等。 ◇算法与操作缺陷:是指在算术运算、函数求值和一般操作过程中发生的缺陷。如数据类型转换错;除法溢出;不正确地使用关系运算符;不正确地使用整数与浮点数做比较等。 算术 114 加 初始化 15 工 控制与次序 271 缺 静态逻辑 13 陷 其他 120 总计 533 26% ◇初始化缺陷:如忘记初始化工作区,忘记初始化寄存器和数据区;错误地对循环控制变量赋初值;用不正确的格式、数据或类类型进行初始化等。
◇控制和次序缺陷:与系统级同名缺陷相比,它是局部缺陷。如遗漏路径;不可达到的代码;不符合语法的循环嵌套;循环返回和终止的条件不正确;漏掉处理步骤或处理步骤有错等。
◇静态逻辑缺陷:如不正确地使用switch语句;在表达式中使用不正确的否定(例如用“>”代替“<”的否定);对情况不适当地分解与组合;混淆“或”与“异或”等。 △动态数据缺陷:动态数据是在程序执行过程中暂时存在的数据,它的生存期非常短。各种不同类型的动态数据在执行期间将共享一个共同的存储区域,若程序启动时对这个区域未初始化,救护导致数据出错。 类型 36 数 结构 34 据 初始值 51 错 其他 120 误 总计 241 12% △静态数据缺陷:静态数据在内容和格式上都是固定的。它们直接或间接的出现在程序或数据库中,有编译程序或其他专门对他们做预处理,但预处理也会出错。
△数据内容、结构和属性缺陷:数据内容是指存储于存储单元或数据结构中的位串、字符串或数字。数据内容缺陷就是由于内容被破坏或被错误地解释而造成的缺陷。数据结构是指数据元素的大小和组织形式。在同一存储区域中可以定义不同的数据结构。数据结构缺陷包括结构说明错误及数据结构误用的错误。数据属性是指数据内容的含义或语义。数据属性缺陷包括对数据属性不正确地解释,如错把整数当实数,允许不同类型数据混合运算而导致的错误等。 包括数据说明错、数据使用错、计算错、比较错、控制流错、界面错、输入\输出错,及其他的错误。
规格说明书是软件缺陷出现最多的地方,其原因是: 程序编写错误 78 4% 文档和其他错误 322 16% ◆用户一般是非软件开发专业人员,软件开发人员和用户的沟通存在较大困难,对要开发的产品功能理解不一致。
◆由于在开发初期,软件产品还没有设计和编程,完全靠想象去描述系统的实现结果,所以有些需求特性不够完整、清晰。
◆用户的需求总是不断变化,这些变化如果没有在产品规格说明书中得到正确的描述,容易引起前后文、上下文的矛盾。
◆对规格说明书不够重视,在规格说明书的设计和写作上投入的人力、时间不足。
◆没有在整个开发队伍中进行充分沟通,有时只有设计师或项目经理得到比较多的信息。
排在产品规格说明书之后的是设计,编程排在第三位。许多人印象中,软件测试主要是找程序代码中的错误,这是一个认识的误区。
为什么说单元测试能发现约80%的软件缺陷
这是软件工程长期的历史数据统计和测试经验总结得来的,没听说过有典故或理由。当然要发现这80%的缺陷也是要依靠设计出良好的测试用例,另外顺便提下,软件测试行业有个二八原则,就是软件80%的缺陷存在与20%的代码中,希望能帮到你。
为什么说单元测试能发现约80%的软件缺陷
不好意思,没看过这个笔试问题,不过经验看来,这个80%有点高,因为:
1.单元测试是开发自己测自己,比较倾向于用合法的数据保证功能的完成
2.开发过程中,有的需求都没有确定,开发没法做单元测试
3.因为各个模块的开发在单元测试的时候都是模拟其他模块的数据来交互的,一旦进入集成和系统测试,会带来大量问题,数据格式不对,数据长度不对,等等,我们不能假设在紧张的项目中,各个组能完整的沟通相互间的接口问题。还有很多是在设计中根本想不到的。
等等
一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
1.和BUG对应的软件版本
2.开发的借口人员,测试人员
3.BUG的优先级
4.BUG的严重程度
5.BUG可能属于的模块
6.BUG的标题
7.BUG的描述
8.BUG的截图
9.BUG的状态
10.BUG的错误类型(数据,界面。。。。)
软件测试中什么样的缺陷是好缺陷?
这个问题问的有水平!!
对测试员来说,什么样的缺陷算是好缺陷!!
一般来说。同样的一个系统,分别让2个不同的测试员测试,发现的BUG也不会都相同,因为人和人的看法,立场,观点都有可能不一样,所以看事物的角度也不一样,发现的BUG也不一样。
尽可能多的发现问题,发现BUG,是软件测试的基本。
所以缺陷没有好坏之分,发现是BUG,对测试员来说就是好BUG。。。
转载请注明出处51数据库 » 软件经典缺陷 软件缺陷有哪些表现