资源预览内容
第1页 / 共51页
第2页 / 共51页
第3页 / 共51页
第4页 / 共51页
第5页 / 共51页
第6页 / 共51页
第7页 / 共51页
第8页 / 共51页
第9页 / 共51页
第10页 / 共51页
亲,该文档总共51页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
第八章 软件BUG和管理,本章要点 .软件Bug对软件质量的影响; .常见的软件Bug类型,重现软件Bug的分析技术; .软件Bug的描述和管理。, 本章目标 了解软件BUG的影响和产生; 掌握软件开发过程中产生的BUG种类; 掌握使BUG重现的技术; 了解软件BUG报告单应该包括的主要内容以及软件BUG的管理流程。,8.1软件BUG概述 在IEEE 1983 of IEEE Standard 729中对软件缺陷下了一个标准的定义: (1)从产品内部看,软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题; (2)从外部看,软件缺陷是系统所需要实现的某种功能的失效或违背。 软件缺陷有很多种,其中主要软件缺陷类型有:,1.一些功能、特性没有实现或只实现了一部分; 2.软件设计不合理,存在缺陷。实际运行结果和预期结果不一致; 3.运行出错,包括运行中断、系统崩溃、界面混乱 4.数据结果不正确、精度不够; 5.用户不能接受的其他问题,如存取时间过长、界面不美观。 8.1.1 BUG的影响 Bug会给用户或使用者带来相当大的麻烦,会给集体或者国家带来很大的经济损失。如:千年虫问题。,8.1.2 BUG的产生 BUG的由来。 对于软件而言,BUG是程序编写错误而导致软件产生问题的缺陷。 软件测试的目的就是找到软件程序代码内的BUG,纠正它,叫做DEBUG。 BUG产生的原因很多,具体有以下几点。 1程序编写错误 Bug的难以避免性。 2需求变更过于频繁,需求变更所造成的结果就是变更程序代码,程序 代码只要稍做变更就必须经过测试来确保运行正常, 所以这个影响是一个连锁反应或称为依存问题。 3软件的复杂度 图形用户界面(GUI)、BS 结构、面向对象设计、分布式运算、底层通信协议、超大型关系型数据库以及庞大的系统规模,都体现了软件复杂度大大高于以前,Bug出现可能性就更高。 4交流不充分或者沟通出问题 大部分项目人员在同客户进行交流时常常存在着各种各样的问题,究其原因,还是因为项目人员、参与人员和客户之间没有详细、充分、谨慎地进行交流。,5测试人员的经验与技巧不足 6时间过于紧迫 7缺乏文档:贫乏或者差劲的文档使得代码维护和修改变得非常困难,结果会导致其他开发人员或客户有许多错误的理解。 8管理上的缺陷 8.2 BUG的种类 BUG是软件“与生俱来”的特征,不同的软件开发阶段会产生不同的BUG,而不同的BUG又会产生不同的后果,因此BUG的属性也并非相同。,8.2.1需求阶段的BUG 这个阶段的BUG是最难发现、最难修复的,而且值得注意的是需求阶段的BUG如果没有及时发现等到实现阶段发现时,那么修复它的费用要比当初修复它要高1575倍。 主要的原因如下: 1、模糊、不清晰的需求; 2、被忽略的需求; 3、相互冲突的需求;,8.2.2分析设计阶段的BUG 设计中的BUG比需求阶段产生的BUG特征明显 易于捕获,但是其维修代价很高,原因是设计BUG 已经作为一个整体影响着整个系统的实现。 原因主要有3种途径。 1 、忽略设计; 2、混乱的设计; 3、模糊的设计;,8.2.3实现阶段的BUG 就是软件系统中最普通、最一般的“常规BUG”。 可以将实现阶段出现的BUG分为下面几类: 1、消息错误 2、用户界面错误 3、遗漏的功能 4、内存溢出或者程序崩溃 5、其他实现错误 第一类型说明了软件系统向用户发送了出错的,消息,可能消息是合理的或者表现为某种中断机制,但是用户认为这是一个BUG。 如下图:,第二类型就是用户界面错误,可归纳为GUI错误。 可能是由于GUI制作不标准而导致用户不能正确地工作。,第三种类型为遗漏的功能BUG (以输入框输入信 息错误,程序抛出未异常为典型) 第四种类型为内存溢出或者程序崩溃BUG,表现 为程序挂起、系统崩溃,属于一种比较严重的软件 BUG类型。(详见教材的药房药品进存销的软件测 试BUG) 8.2.4配置阶段的BUG 配置阶段的BUG出现的原因是复杂的,比较典型 的是旧的代码覆盖了新的代码,或者测试服务器上 的代码和实现人员本机最新代码版本不一致。,可能是实现人员操作配置管理工具不正确引起的;还可能体现了测试人员或者最终用户操作不正确。 8.2.5短视将来的BUG “千年虫”问题就是当初的设计人员为了节省一点硬件成本给全球造成了难以估量的损失。 作者曾经为一家大药房开发了一套药品管理的进销存软件,由于最初的时候对业务流程并不是很熟悉,所以在定义药品编码的时候把许多药品的ID号定义为了整型变量(INT),开始作者认为这些足以定义所有的药品名称了,没想到,一年以后,由于药房的业务量急增,药品的ID也就不够了,由于整套系统是由Power Builder编写,整型变量的最大值只有32767,因此程序经常由于数据溢出而出现问题,所以作者被迫用了近一个星期的时间来修改原来的程序。 8.2.6静态文档的BUG 文档BUG的定义很简单,即说明模糊、描述不完整和过期的都属于文档BUG。说明模糊特指无充分的信息判断如何正确地处理事情;描述不完整特指文档信息不足以支持用户完成某项工作;过期的文档是没有及时更新过的、错误的文档。,8.3.1 BUG报告单的内容 BUG报告单也叫缺陷报告单或者问题报告单。 问题报告单所需的基本信息类型是大同小异的,不同的只是组织和标志。 介绍一下字段: (1)问题报告编号 (2)程序名 (3)版本标识:发布号和版本号。是用来识别被测的代码。 例如:某个版本号可能是1.01m,发布号是1.01,“m”指1.01版本的第13稿。,(4)报告类型:描述了发现的问题类型。包括:编码错误 、设计问题 、建议 、文档 、硬件、质疑。 (5)严重性:为问题严重程度评分。 包含三个等级:三个等级:轻微的、严重的和致命的。 (6)附件 存有测试数据的软盘、键盘捕获记录或一组可产生测试用例的宏、程序的打印输出、内存dump或一份注释,里面详细描述了你所做的操作,以及你认为该问题很重要的原因。 (7)问题概要:对问题进行描述,有助于评审突出的问题,并找到相应的问题报告。,(8)问题能否重现。要多次测试看能否再次出现。 (9)问题描述及如何重现。描述所有的步骤和现象,包括错误信息。一定要提交报告。 (10)建议的改正措施 (11)报告人 (12)日期:指的是报告人员发现问题的日期。 (13)功能域:对问题进行大体分类。 (14)承办人 (15)注释:程序员在这里简短地说明为什么要推迟处理,或说明是如何改正问题的。,(16)状态。三个状态码:开放、关闭和已解决。 (17)优先级。只由项目经理设置。 (18)处理状态与处理版本 处理状态定义了问题的当前状态: 未解决:初始化状态或仍有冲突状态。 已改正 不能重现 暂缓:对存在的问题在下个版本改正。 符合设计 由报告人撤回,需要进一步信息 不同意建议 重复:关闭重复上报的缺陷。 (19)签名:签署以表明已经对改动进行了测试,对结果表示满意。 (20)暂缓处理:对缺陷的推迟处理。 图8-3 、8-4整合起来即为一张完整的报告单。,图8-3 报告单(part 1),图8-4 报告单(part 2),8.3.2 BUG报告的特点 一份好的问题报告应是书面的、已编号的、简单的、易于理解的、可重现的、易读的和不做判断的。 1) 书面的 一份书面的报告是必要的,供日后对修改后的程序进行测试时使用;让管理层、销售人员和产品支持人员检查。 2) 已编号的 依据惟一的编号跟踪问题报告。,3) 简单的 一份报告应只描述一个问题,不要在一份报告中记录多个缺陷。 4) 可重现的 一定要强调BUG的可重现性。 5) 不做判断的 对程序员的评价要三思而后行,本着合作的精神,作出合理的判断。,8.3.3重现BUG的分析和方法 本节重点是报告编码错误,而非报告设计问题。 一、重现BUG的分析 “可重现”隐含了下列定义: 我们能够描述如何让程序进入某个已知的状态。任何熟悉程序的人都能够依照我们的描述使程序进入该状态。 从那个状态出发,我们确定出精确的一组步骤来暴露出问题。 为使报告更有效,我们应该对问题进一步分析,,目的在于: 1)找出问题最严重的后果。 找出某个BUG导致的最严重的后果,这样可以激发人们改正它的兴趣。一个看来很轻微的问题往往更有可能被暂缓处理。 例如:假设有个BUG在屏幕角落显示了一个无用的字符,这个问题很轻微,但是是可以报告的。有些时候,屏幕上显示出无用信息只是一个孤立的问题(因此对它置之不理的决定可能是明智的,尤其是程序快要交付的时候)。但是如果继续运行这个程序,可能会出现一旦显示无用,信息之后,程序几乎会马上崩溃-最严重的后果。 2)找出最简单、最直接和最常见的BUG触发条件。 如果理解和改正问题仅需要很小的工作量,那么就会修复它。 如果问题的解决需要(或看起来需要)很长的时间和精力,程序员会不太情愿改正它。 如果问题会在程序日常使用的过程中发生,管理层对问题的关注会增加。 如果问题的出现几乎无人知晓,关注程度会很低。 3)找出产生相同问题的其他路径。,有时不止一种方法可以触发一个错误,若有两条不同的路径通往同一个BUG,比起仅有一条路径来势更有力的危险信号。即使每条路径都包含着很复杂的步骤序列,存在两条路径也意味着代码中含有严重的错误。 要充分展示各条路径的差异,不能让程序员把多条路径视为对同一个BUG的相似描述。 4)找出相关的问题。 根据积累的经验,仿照以前发现BUG的方法,查找程序中其他可能的位置,能有相当的机会在新的代码中找出类似的问题。,二、可重现BUG的分析技术 1)寻找最关键的步骤 根据BUG查找代码中的错误,不要忽略任何细微的有关错误的线索。 应该查找下列的问题: 1. 错误信息; 2.处理延时; 3.屏幕闪烁; 4. 光标跳跃; 5.文本错误;,6. 工作指示灯在设备未使用时亮起。 2)最大程度地提高程序运行的可见性 将程序运行的越多方面变的可见,就越能看到更多的出错情况,也就越有可能明确关键的步骤。 用调试工具可以报告出当前活动的进程、程序占用的内存或其他资源的数量、正在使用的堆栈的数量以及其他的内部信息。 1.监测堆栈中的遗留数据的多少 2.监侧进程的收发消息,内存的占用情况。 另一条途径是将屏幕显示的所有内容和磁盘文件,的所有变更统统都打印出来,然后进行分析。 3)多尝试一些结果 将程序的事件进行组合的执行。 4)查找后续错误 一旦发现了某个错误,也应该再坚持运行程序一段时间,看看是否会有其他的错误出现。我们要认真细致地做这件事,最初出现的问题可能会诱发一系列后续问题。 5)渐进地省略或改变步骤 问题复杂的时候可以跳过一些步骤,但对每个要省略的步骤进行测试,看看它是否是重现BUG的必要环节。,至于改变步骤,可以在每个步骤中查找是否存在边界条件,对边界条件的敏感程度,是一个测试人员技术成熟与否的标志之一。 6)在程序以前的版本中查找错误 7)查找配置依赖 三、让BUG可重现 如何触发BUG? 将我们记得的有关第一次操作的所有事情都记 下来,进行一步一步的问题回溯。 倘若没有效果,可能是没有满足确切的条件, BUG没有显现出来。,下面列举了几种应该考虑到的情况: 1)竞争条件 2)被遗忘的细节 3)BUG造成的影响会导致其无法重现 4)BUG是依赖于内存的 5)仅会在初次运行时出现的BUG 6)因数据错误导致的BUG 7)由于一些其他问题附带引起的BUG 8)间断性硬件故障 9)BUG依赖于时间 10)BUG依赖与资源,11)BUG由长期积累形成 8.3.4 BUG管理流程 对BUG的跟踪管理是测试工作的一个重要部分,测试的目的是为了尽早发现软件系统中的缺陷,因此,对BUG进行跟踪管理,确保每个被发现的缺陷都能及时得到处理。 BUG管理流程是一套复杂的处理过程,涉及到测试员(复审员)、项目数据库管理员、实施员(设计员)三方的交互,图8-4所示的BUG管理流转图详细描述了三方关联关系(同样适合
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号