资源描述
软件测试基础教程第一章软件测试的基础理论第一章软件测试的基础理论1.1软件测试的含义1.2软件测试的目的与原则1.3软件测试的生命周期1.4软件测试与软件开发的关系习题本章概要第一章软件测试的基础理论软件测试的发展历史及其现状软件测试的定义测试目的测试原则测试的生命周期软件测试与软件开发的关系1.1软件测试的含义第一章软件测试的基础理论1.1.1软件缺陷1.1.2软件测试技术的发展历史及现状1.1软件测试的含义第一章软件测试的基础理论软件的质量就是软件的生命,为了保证软件的质量,人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法。但是借助这些方法,我们只能尽量减少软件中的错误和不足,却不能完全避免所有的错误。如果把所开发出来的软件看作一个企业生产的产品,那么软件测试就相当于该企业的质量检测部分。简单地说,我们在编写完一段代码之后,检查其是否如我们所预期的那样运行,这个活动就可以看作是一种软件测试工作。新的测试理论、测试方法、测试技术手段在不断涌出,软件测试机构和组织也在迅速产生和发展,由此软件测试技术职业也同步完善和健全起来。1.1.1软件缺陷第一章软件测试的基础理论1软件缺陷案例人们常常不把软件当回事,没有真正意识到它已经深入渗透到我们的日常生活中,软件在电子信息领域里无处不在。现在有许多人如果一天不上网查看电子邮件,简直就没法过下去。我们已经离不开24小时包裹投递服务、长途电话服务和最先进的医疗服务了。然而软件是由人编写开发的,是一种逻辑思维的产品,尽管现在软件开发者采取了一系列有效措施,不断地提高软件开发质量,但仍然无法完全避免软件(产品)会存在各种各样的缺陷。1.1.1软件缺陷第一章软件测试的基础理论下面以实例来说明。(1)迪斯尼的狮子王游戏软件缺陷。1994年秋天,迪斯尼公司发布了第一个面向儿童的多媒体光盘游戏狮子王动画故事书(TheLionKingAnimatedStorybook)。尽管已经有许多其他公司在儿童游戏市场上运作多年,但是这次是迪斯尼公司首次进军这个市场,所以进行了大量促销宣传。结果,销售额非常可观,该游戏成为孩子们那年节假日的“必买游戏”。然而后来却飞来横祸。12月26日,圣诞节的后一天,迪斯尼公司的客户支持电话开始响个不停。很快,电话支持技术员们就淹没在来自于愤怒的家长并伴随着玩不成游戏的孩子们哭叫的电话之中。报纸和电视新闻进行了大量的报道。后来证实,迪斯尼公司未能对市面上投入使用的许多不同类型的PC机型进行广泛的测试。软件在极少数系统中工作正常-例如在迪斯尼程序员用来开发游戏的系统中但在大多数公众使用的系统中却不能运行。1.1.1软件缺陷第一章软件测试的基础理论(2)爱国者导弹防御系统缺陷爱国者导弹防御系统是里根总统提出的战略防御计划(即星球大战计划)的缩略版本,它首次应用在海湾战争中对抗伊拉克飞毛腿导弹的防御战中。尽管对系统赞誉的报道不绝于耳,但是它确实在对抗几枚导弹中失利,包括一次在沙特阿拉伯的多哈击毙了28名美国士兵。分析发现症结在于一个软件缺陷,系统时钟的一个很小的计时错误积累起来到14小时后,跟踪系统不再准确。在多哈的这次袭击中,系统已经运行了100多个小时。1.1.1软件缺陷第一章软件测试的基础理论(3)千年虫问题20世纪70年代早期的某个时间,某位程序员正在为本公司设计开发工资系统。他使用的计算机存储空间很小,迫使他尽量节省每一个字节。他将自己的程序压缩得比其他任何人都紧凑。使用的其中一个方法是把4位数年份,例如1973年,缩减为2位数,73。因为工资系统相当信赖于日期的处理,所以需要节省大量的存储空间。他简单的认为只有在到达2000年,那时他的程序开始计算00或01这样的年份时问题才会产生。虽然他知道会出这样的问题,但是他认定在25年之内程序肯定会升级或替换,而且眼前的任务比现在计划遥不可及的未来更加重要。然而这一天毕竟到来了。1995年他的程序仍然在使用,而他退休了,谁也不会想到如何深入到程序中检查2000年兼容问题,更不用说去修改了。估计全球各地更换或升级类似的前者程序以解决潜在的2000问题的费用已经达数千亿美元。1.1.1软件缺陷第一章软件测试的基础理论(4)美国航天局火星登陆探测器缺陷1999年12月3日,美国航天局的火星极地登陆者号探测器试图在火星表面着陆时失踪。一个故障评估委员会调查了故障,认定出现故障的原因极可能是一个数据位被意外置位。最令人警醒的问题是为什么没有在内部测试时发现呢。从理论上看,着陆的计划是这样的:当探测器向火星表面降落时,它将打开降落伞减缓探测器的下降速度。降落伞打开几秒钟后,探测器的三条腿将迅速撑开,并锁定位置,准备着陆。当探测器离地面1800米时,它将丢弃降落伞,点燃着陆推进器,缓缓地降落到地面。美国航天局为了省钱,简化了确定何时关闭着陆推进器的装置。为了替代其他太空船上使用的贵重雷达,他们在探测器的脚部装了一个廉价的触点开关,在计算机中设置一个数据位来控制触点开关关闭燃料。很简单,探测器的发动机需要一直点火工作,直到脚“着地”为止。1.1.1软件缺陷第一章软件测试的基础理论遗憾的是,故障评估委员会在测试中发现,许多情况下,当探测器的脚迅速撑开准备着陆时,机械震动也会触发着陆触点开关,设置致命的错误数据位。设想探测器开始着陆时,计算机极有可能关闭着陆推进器,这样火星极地登陆者号探测器飞船下坠1800米之后冲向地面,撞成碎片。结果是灾难性的,但背后的原因却很简单。登陆探测器经过了多个小组测试。其中一个小组测试飞船的脚折叠过程,另一个小组测试此后的着陆过程。前一个小组不去注意着地数据是否置位这不是他们负责的范围;后一个小组总是在开始复位之前复位计算机,清除数据位。双方独立工作都做得很好,但合在一起就不是这样了1.1.1软件缺陷第一章软件测试的基础理论(5)金山词霸缺陷在国内,“金山词霸”是一个很著名的词典软件,应用范围极大,对使用中文操作的用户帮助很大,但它也存在不少缺陷。例如输入“cube”,词霸会在示例中显示33=9的错误;又如,如果用鼠标取词“dynamically”(力学,动力学),词霸会出现其他不同的单词“dynamiten.炸药”的显示错误。1.1.1软件缺陷第一章软件测试的基础理论(6)英特尔奔腾浮点除法缺陷在计算机的“计算器”程序中输入以下算式:(4195835/3145727)*3145727-4195835如果答案是0,就说明计算机没问题。如果得出别的结果,就表示计算机使用的是带有浮点除法软件缺陷的老式英特尔奔腾处理器这个软件缺陷被烧录在一个计算机芯片中,并在制作过程中反复生产。1994年10月30日,弗吉利亚州Lynchburg学院的ThomasR.Nicely博士在他的一个实验中,用奔腾PC机解决一个除法问题时,记录了一个想不到的结果,得出了错误的结论。他把发现的问题放到因特网上,随后引发了一场风暴,成千上万的人发现了同样的问题,并且发现在另外一些情形下也会得出错误的结果。万幸的是,这种情况很少见,仅仅在进行精度要求很高的数学、科学和工程计算中才会导致错误。大多数用来进行税务处理和商务应用的用户根本不会遇到此类问题。1.1.1软件缺陷第一章软件测试的基础理论这件事情引人关注的并不是这个软件缺陷,而是英特尔公司解决问题的方式:他们的软件测试工程师在芯片发布之前进行内部测试时已经发现了这个问题。英特尔的管理层认为这没有严重到要保证修正,甚至公开的程度。当软件缺陷被发现时,英特尔通过新闻发布和公开声明试图弱化这个问题的已知严重性。受到压力时,英特尔承诺更换有问题的芯片,但要求用户必须证明自己受到缺陷的影响。2软件缺陷的定义从上述的案例中可以看到软件发生错误时将造成灾难性危害或对用户产生各种影响。软件缺陷(bug),即计算机系统或者程序中存在的任何一种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷、瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需要。1.1.1软件缺陷第一章软件测试的基础理论对于软件缺陷的准确定义,通常有以下5条描述:(1)软件未实现产品说明书要求的功能。(2)软件出现了产品说明书指明不会出现的错误。(3)软件超出实现了产品说明书提到的功能。(4)软件实现了产品说明书虽未明确指出但应该实现的目标。(5)软件难以理解,不易使用,运行缓慢或者终端用户认为不好。1.1.1软件缺陷第一章软件测试的基础理论为了更好地理解每一条规则,我们以计算器为例进行说明。计算器的产品说明书声称它能够准确无误地进行加、减、乘、除运算。当你拿到计算器后,按下()键,结果什么反应也没有,根据第条规则,这是一个缺陷。假如得到错误答案,根据第条规则,这同样是一个缺陷。若产品说明书声称计算器永远不会崩溃、锁死或者停止反应。当你任意敲键盘,计算器停止接受输入,根据第条规则,这是一个缺陷。若用计算器进行测试,发现除了加、减、乘、除之外它还可以求平方根,说明书中从没提到这一功能,根据第条规则,这是软件缺陷。软件实现了产品说明书未提到的功能若在测试计算器时,会发现电池没电会导致计算不正确,但产品说明书未指出这个问题。根据第条规则,这是个缺陷。第条规则是全面的。如果软件测试员发现某些地方不对劲,无论什么原因,都要认定为缺陷。如“”键布置的位置使其极其不好按;或在明亮光下显示屏难以看清。根据第条规则,这些都是缺陷。1.1.1软件缺陷第一章软件测试的基础理论3软件缺陷的种类软件缺陷表现的形式有多种,不仅仅体现在功能的失效方面,还体现在其他方面。软件缺陷的主要类型有:功能、特性没有实现或部分实现。设计不合理,存在缺陷。实际结果和预期结果不一致。运行出错,包括运行中断、系统崩溃、界面混乱。数据结果不正确、精度不够。用户不能接受的其他问题,如存取时间过长、界面不美观。1.1.1软件缺陷第一章软件测试的基础理论4软件缺陷的级别及软件缺陷的状态(1)软件缺陷的级别作为软件测试员,可能所发现的大多数问题不是那么明显、严重,而是难以觉察的简单而细微的错误,有些是真正的错误,也有些不是。一般来说,问题越严重的,其优先级越高,越要得到及时的纠正。软件公司对缺陷严重性级别的定义不尽相同,但一般可以概括为4种级别:致命的:致命的错误,造成系统或应用程序崩溃、死机、系统悬挂,或造成数据丢失、主要功能完全丧失等。严重的:严重错误,指功能或特性没有实现,主要功能部分丧失,次要功能完全丧失,或致命的错误声明。一般的:不太严重的错误,这样的软件缺陷虽然不影响系统的基本使用,但没有很好地实现功能,没有达到预期效果。如次要功能丧失,提示信息不太准确,或用户界面差,操作时间长等。微小的:一些小问题,对功能几乎没有影响,产品及属性仍可使用,如有个别错别字、文字排列不整齐等。除了这4种之外,有时需要“建议”级别来处理测试人员所提出的建议或质疑,如建议程序做适当的修改,来改善程序运行状态,或对设计不合理、不明白的地方提出质疑。1.1.1软件缺陷第一章软件测试的基础理论(2)软件缺陷的状态软件缺陷除了严重性之外,还存在反映软件缺陷处于一种什么样的状态,便于跟踪和管理某个产品的缺陷,可以定义不同的bug状态。激活状态:问题还没有解决,测试人员新报的bug,或验证后bug仍然存在。已修正状态:开发人员针对所存在的缺陷,修改程序,认为已解决问题,或通过单元测试。关闭或非激活状态:测试人员验证已经修正的bug后,确认bug不存在以后的状态。1.1.1软件缺陷第一章软件测试的基础理论5软件缺陷的原因软件缺陷的产生,首先是不可避免的。其次我们可以从软件本身,团队工作和技术问题等多个方面分析,比较容易确定造成软件缺陷的原因,归纳如下。技术问题算法错误。语法错误。计算和精度问题。系统结构不合理,造成系统性能问题。接口参数不匹配出现问题。团队工作系统分析时对客户的需求不是十分清楚,或者和用户的沟通存在一些困难。不同阶段的开发人员相互理解不一致,软件设计对需求分析结果的理解偏差,编程人员对系统设计规格说明书中某些内容重视不够,或存在着误解。设计或编程上的一些假定或依赖性,没有得到充分的沟通。软
展开阅读全文
温馨提示:
金锄头文库所有资源均是用户自行上传分享,仅供网友学习交流,未经上传用户书面授权,请勿作他用。
相关搜索