欢迎来到天天文库
浏览记录
ID:8179929
大小:44.50 KB
页数:6页
时间:2018-03-09
《软件测试失效案例简介》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、http://book.51cto.com/art/200909/151890.htm失效案例简介软件出现的问题有多种形式,会产生各种各样的后果。下面是一些例子。受医用线性加速器的过度辐射,造成6人严重烧伤或死亡。经查,管理加速器的软件包含了一系列程序错误,由于软件结构极差,错误再现困难,也使得机器生产者不愿意收回机器。火星气候轨道航天器撞到了火星的表面。调查表明,由于测试不充分,没有发现程序中的一个简单的量纲转换错误。几架"黑鹰"直升机撞毁,多人罹难。调查表明,灾难原因是无线电信号与机载计算机系统相互干扰。称做CONFIRM的旅游预订系统在经过1.25亿美元的投资后流产。
2、F22战机的一个软件故障(边界值测试的漏洞)。2007年2月,美军F22战斗机从夏威夷飞往日本,途径日期变更线(东经180度,西经0度)时,软件缺陷爆发,飞机上的全球定位系统失灵,电脑系统崩溃。飞行员无法确定战机的位置,返回夏威夷的希卡姆空军基地。洛·马丁公司对软件进行了维护,48小时后提供了新的软件版本。2007年北京机场信息系统瘫痪。2007年10月10日13时28分,设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障,短短50分钟内,北京、广州、深圳、长沙机场至少84个离港航班发生延误,受其影响的城市包括上海、长春、南京、南宁、温州、成都、郑州、太原、
3、呼和浩特、重庆、兰州、香港、东京等。该系统是由美国某家公司研发,此事件引发信息系统安全的担忧。2008北京奥运会售票系统于2007年10月30日上午11时瘫痪:北京奥运会的指定独家票务供应商-北京歌华特玛捷票务有限公司成立于2006年9月,由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后,公众普遍质疑歌华特玛捷公司是否具备承担2008北京奥运会的票务销售能力。用户常常在软件开发初期就发现软件不是他们所期待的。在开发软件之前,需要进行必要的需求分析。充分的需求分析要求软件开发人员与用户进行良好的沟通,充分理解用户需求才能开发
4、出更有用的产品。虽然这些软件故障的后果程度不一,但可以肯定的是,通过严格的软件工程可以极大地降低故障及因此而引发的种种恶果。1.6.2 失效原因软件失效主要是由于开发组织没有采用好的软件工程方法。尽管软件开发人员知道不好的软件开发可能造成可怕的后果,但为什么大家还不能广泛采用软件工程的方法呢?原因是管理和开发队伍对软件工程早期的重要性的认识严重不足,认为代码的行数是项目进展的唯一尺度,任何与生成代码无关的事情都不是进展,因而也不值得花费时间和资源。引起软件失效的原因包括:1)软件复杂度;2)非线性(多线程)软件;3)对意外的输入或条件估计不足;4)与外设接口动作异常;5)硬
5、件或操作系统与软件不兼容;6)管理不善;7)测试不充分;8)粗心大意;9)想走捷径;10)不向管理部门通报问题;11)风险分析不充分;12)数据输入错误;13)错误的输出解释;14)对软件过于自信;15)缺乏生产高质量软件的市场或法律压力。以上是引起软件失效的原因列表,对我们很有帮助,我们应该谨记。考虑的潜在软件失效原因越多,系统就越不易出现失效。例如,如果完全按照一种软件工程方法学来开发软件,假设用户是未经过充分训练的,那么就应考虑可能会出现数据完整性错误,否则,系统可能是没什么用的。下面来看几个实际的软件开发中的灾难故事,目的是让你充分理解软件开发中和谐工作方式的重要性
6、,不论你是初学者还是计算机专家,均能获益。这些故事也可以让你为争取在你的工作环境下采用好的软件工程方法提供有力证据。1.6.3CONFIRMCONFIRM是一个雄心勃勃的软件开发计划,它的目标是集成飞机订票、汽车出租和旅馆预订以及相关的决策支持机制为一体。它是由美国航空公司的子公司AMRIS提出的,项目开发了3年半,耗资1.25亿美元,结果生产了一个无用的系统。CONFIRM的惨败虽然没有危及任何人的生命,但是如此巨大的经济损失最后都转嫁到了消费者身上。通过这种高的消费代价,大众觉察到如此灾难性软件开发的后果。为了更好地评估避免如此巨大经济损失而应采取的各种策略,将有关的大
7、事列表如下:1)1987年10月,Marriott,Hilton,BudgetRent-a-Car和AMRIS成立联盟,决定开发和运营CONFIRM,并让AMRIS管理开发。项目计划分两个阶段,计划于1992年6月完工。2)1988年5月24日,AMRIS发布新闻,宣布CONFIRM设计阶段开始。3)1988年12月30日,AMRIS向联盟呈报了系统基础设计,Marriott认为系统的功能规约还不够充分,用户需求还不够细,开发人员还不能据此进行开发。4)1989年3月,AMRIS呈报一份开发计划,结果也未被联盟成员
此文档下载收益归作者所有