软件测试失效案例简介

https://www.360docs.net/doc/af19200943.html,/art/200909/151890.htm

失效案例简介

软件出现的问题有多种形式，会产生各种各样的后果。下面是一些例子。

受医用线性加速器的过度辐射，造成6人严重烧伤或死亡。经查，管理加速器的软件包含了一系列程序错误，由于软件结构极差，错误再现困难，也使得机器生产者不愿意收回机器。

火星气候轨道航天器撞到了火星的表面。调查表明，由于测试不充分，没有发现程序中的一个简单的量纲转换错误。

几架"黑鹰"直升机撞毁，多人罹难。调查表明，灾难原因是无线电信号与机载计算机系统相互干扰。

称做CONFIRM的旅游预订系统在经过1.25亿美元的投资后流产。

F22战机的一个软件故障（边界值测试的漏洞）。2007年2月，美军F22战斗机从夏威夷飞往日本，途径日期变更线（东经180度，西经0度）时，软件缺陷爆发，飞机上的全球定位系统失灵，电脑系统崩溃。飞行员无法确定战机的位置，返回夏威夷的希卡姆空军基地。洛·马丁公司对软件进行了维护，48小时后提供了新的软件版本。

2007年北京机场信息系统瘫痪。2007年10月10日13时28分，设在北京首都国际机场的中国民航信息网络股份公司离港系统突然发生故障，短短50分钟内，北京、广州、深圳、长沙机场至少84个离港航班发生延误，受其影响的城市包括上海、长春、南京、南宁、温州、成都、郑州、太原、呼和浩特、重庆、兰州、香港、东京等。该系统是由美国某家公司研发，此事件引发信息系统安全的担忧。

2008北京奥运会售票系统于2007年10月30日上午11时瘫痪：北京奥运会的指定独家票务供应商-北京歌华特玛捷票务有限公司成立于2006年9月，由美国特玛捷公司、中体产业股份有限公司及北京歌华文化发展集团三家出资构建而成。售票系统瘫痪事件发生后，公众普遍质疑歌华特玛捷公司是否具备承担2008北京奥运会的票务销售能力。

用户常常在软件开发初期就发现软件不是他们所期待的。在开发软件之前，需要进行必要的需求分析。充分的需求分析要求软件开发人员与用户进行良好的沟通，充分理解用户需求才能开发出更有用的产品。虽然这些软件故障的后果程度不一，但可以肯定的是，通过严格的软件工程可以极大地降低故障及因此而引发的种种恶果。

1.6.2 失效原因

软件失效主要是由于开发组织没有采用好的软件工程方法。尽管软件开发人员知道不好的软件开发可能造成可怕的后果，但为什么大家还不能广泛采用软件工程的方法呢？原因是管理和开发队伍对软件工程早期的重要性的认识严重不足，认为代码的行数是项目进展的唯一尺度，任何与生成代码无关的事情都不是进展，因而也不值得花费时间和资源。

引起软件失效的原因包括：

1)软件复杂度；

2)非线性（多线程）软件；

3)对意外的输入或条件估计不足；

4)与外设接口动作异常；

5)硬件或操作系统与软件不兼容；

6)管理不善；

7)测试不充分；

8)粗心大意；

9)想走捷径；

10)不向管理部门通报问题；

11)风险分析不充分；

12)数据输入错误；

13)错误的输出解释；

14)对软件过于自信；

15)缺乏生产高质量软件的市场或法律压力。

以上是引起软件失效的原因列表，对我们很有帮助，我们应该谨记。考虑的潜在软件失效原因越多，系统就越不易出现失效。例如，如果完全按照一种软件工程方法学来开发软件，假设用户是未经过充分训练的，那么就应考虑可能会出现数据完整性错误，否则，系统可能是没什么用的。

下面来看几个实际的软件开发中的灾难故事，目的是让你充分理解软件开发中和谐工作方式的重要性，不论你是初学者还是计算机专家，均能获益。这些故事也可以让你为争取在你的工作环境下采用好的软件工程方法提供有力证据。

1.6.3 CONFIRM

CONFIRM是一个雄心勃勃的软件开发计划，它的目标是集成飞机订票、汽车出租和旅馆预订以及相关的决策支持机制为一体。它是由美国航空公司的子公司AMRIS提出的，项目开发了3年半，耗资1.25亿美元，结果生产了一个无用的系统。

CONFIRM的惨败虽然没有危及任何人的生命，但是如此巨大的经济损失最后都转嫁到了消费者身上。通过这种高的消费代价，大众觉察到如此灾难性软件开发的后果。为了更好地评估避免如此巨大经济损失而应采取的各种策略，将有关的大事列表如下：

1)1987年10月，Marriott,Hilton,Budget Rent-a-Car和AMRIS成立联盟，决定开发和运营CONFIRM，并让AMRIS管理开发。项目计划分两个阶段，计划于1992年6月完工。

2)1988年5月24日，AMRIS发布新闻，宣布CONFIRM设计阶段开始。

3)1988年12月30日，AMRIS向联盟呈报了系统基础设计，Marriott认为系统的功能规约还不够充分，用户需求还不够细，开发人员还不能据此进行开发。

4)1989年3月，AMRIS呈报一份开发计划，结果也未被联盟成员们接受。

5)1989年8月，AMRIS向联盟成员提交了项目经费预算。基于这一预算，其他成员决定继续维持该项目。后来的事实表明，这一预算对人员和操作成本的估计存在严重不足。

6)1989年9月，AMRIS终于完成了一个令联盟满意的设计，同时预算也增长至7260万美元。

7)1990年1月，AMRIS未能按第一合同期限完成终端屏幕的设计。

8)1990年2月，第二个项目里程碑即系统商务领域分析也未能如期完成。AMRIS承认有13周的滞后，但仍声明系统可以在原定的期限完成。

9)1991年2月，AMRIS向联盟成员提交了一份修改过的开发计划，要到1993年3月为Marriott提供完整功能的系统。后来Marriott声称其实AMRIS知道它不可能在新的期限内完成系统，但还是强迫雇员人为地延长工作时间表，否则会遭到解雇或重新调遣。AMRIS 也在修改的开发计划中提高了开发的价钱，升至9200万美元。

10)1991年10月，AMRIS总裁以及20余名雇员辞职。

11)1992年5月1日，AMRIS的新总裁认可"系统接口和数据库不足以提供必要的性能和可靠性"，他还将这种状况归究于AMRIS对项目状态的错误认识。

12)最后，于1992年7月，联盟在花费了1.25亿美元后，不堪重负，终于解散。

大量的报刊对CONFIRM项目的无能的管理和技术上的幼稚等进行了无情的嘲讽。不过我们关心的是，如何利用适当的软件工程方法来避免这种灾难。虽然这个例子涉及一个重要的职业道德问题，但首先还是让我们来分析软件失效的根源。

很明显，AMRIS关于项目状态的管理是有问题的。项目是如何发展到管理部门被迫掩盖真相的呢其实在项目的早期就有一些不好的征兆，AMRIS是不能开发一个可行的产品的；第二个征兆是，经过7个月的努力后，AMRIS提交的设计文档技术上是不能令人满意的。这样的一个设计意味着AMRIS没有能力正确估计自己设计的质量。另外，AMRIS的行动表明它并不重视交付设计的质量，只重视初始设计的按期完成。第二次提交的设计再次遭到拒绝，这也再一次表明AMRIS确实太无能，不可能提出一个充分的开发计划。

以上大事记似乎反复强调了AMRIS不能提供高质量的软件工程报告，这意味着基础的软件开发阶段的有效性值得质疑。另外，某种基础的风险分析应能帮助联盟成员识别至少两种高风险目标。这些风险目标应能提醒联盟成员进行某些测验项目，以确定这些目标的可行性。CONFIRM系统的一个高风险目标是需要与联盟伙伴的现有系统连接，这样的连接要求CONFIRM同异构的软硬件能互操作；第二个高风险目标是需要将预订系统同每种商务领域的决策支持系统集成。初始时对这些目标的复杂性作一下分析，就会得到一个更合理的开发进度计划。

1.6.4 电话和通信

今天，人们很难找到比远程电话网应用技术更好的例子。它通过光纤将遍及世界各地的人们可靠地、即时地连在一起，这不能不说是技术上的奇迹。AT&T拥有多达115个交换站，将遍及世界的当地电话公司连接起来，每天可处理1.15亿次美国境内的呼叫和150万次的海外呼叫，每个交换站每小时能处理将近75万次呼叫。

一个交换站，又名4ESS，其实是一个庞大的专用计算机，它运行一个包含4百万行代码的软件。该软件需要仔细处理电话两端的连接、通话费以及其他许多与电话相关的服务，为维护该软件需要雇佣150人以上。有几次事故曾中断了电话服务，原因就是该软件过于复杂。

1990年1月15日的下午，AT&T的全球电话网络的管理人员发现显示网络状态的视频监视器上不断出现红色报警信号。报警信号说明网络不能完成呼叫，接下来的9个小时内，有近6500万个电话没有接通，造成大约6000万美元的损失。尽管系统的管理人员设法在9小时内解决了问题，但是要查明原因恐怕需要好几天。

大约在系统瘫痪前一个月，软件进行了升级，以允许某种类型的消息更快地通过系统。在升级软件的一小段代码中发现了一个错误，该错误在严格的测试和一个月的试用中没有被发现，因为那几行代码只在网络特别忙而发生了特定的事件序列时才会调用。各单个交换站工作都正常，但交换站之间的消息传递的快速步调引起系统反复重启动。当运行升级软件的

交换站数减少到80台左右时，网络似乎又恢复正常。这时，其余的交换站仍然运行旧版软件，可以处理尽可能多的呼叫。

这种类型的"网络隐错"确实很难发现和想到，要在一个测试用的系统上精确模拟和预料真实世界中的网络通信是十分困难的。事实上，AT&T确实也在它的测试网络上测试了该软件，但没能发现该问题。

与首次瘫痪相隔6个月，又遇到了另一个控制交换站的软件失效。在1991年6月到7月间的三个星期内，8次电话不通事故影响了大约2000万电话客户。不通的原因难以捉摸，而且，本地电话公司之间似乎也不愿意彼此透露如何修复问题的有关信息。最终，由BellCore 贝尔通信研究公司经过6个月的调查，认定引起这一问题的原因仍然是这个交换机软件。

这些事故的原因是制造交换机的软硬件公司DSC通信公司对软件的一次修改不当造成的。1991年4月，DSC通信公司发布了交换机的新版本。很快，华盛顿、宾夕法尼亚和北卡罗来纳州的用户碰到了这一问题。每次瘫痪首先由一个交换机的一个小问题引起，该问题与信号传输点（Signal Transfer Point，STP）有关。然后这一问题会触发大量的错误消息，结果导致STP被关闭，进而导致邻近系统的瘫痪。

最后，BellCore发现问题出在新版软件中的一个三位错：一个应是二进制数D（1101）的数误为二进制数60110）。在交换算法中，这三位错导致交换机允许错误消息饱和。通过网络，一个系统出错导致其他系统崩溃。正常情况下，饱和的交换机只简单地通告其他系统出现了拥塞情况。DSC通信公司很快发布了该软件的补丁，专门处理这一问题。对源程序作了广泛的测试之后发现，一个程序员对源程序中的三行代码作了修改，其中一行包含低级的打字错误，软件发布前，该段代码没有经过测试。

你也许会庆幸通信问题似乎已成历史，因为以上两个例子均发生在20世纪90代初。然而，事实上近年来也发生了大量的这类失效。例如，一位美国西部技师为科罗拉多州安装一个新的区域码软件时，不经意地关闭了该区域的911系统，结果一位在Longmont的名叫Thomas Carlock的男士死于心脏病，发病时他的妻子不能拨通911急救服务。当时，她至少试过3次，结果每次都没有回答，没有振铃，也没有线路忙信号。最后，她查了号码本，直接呼叫了一个急救室的电话，然后救护车才发往她的住地。在事故追查的过程中，技师一直不清楚911会有问题，Longmont急救人员也是直到事故发生后一个小时才知道911有问题的。按照美国西部的一份报告的说法，公司"已承诺采取措施确保软件安装不会影响到911服务"。

1.6.5 阿丽亚娜5型火箭

1996年6月4日，阿丽亚娜（Ariane）5型火箭在法属圭亚那库鲁航天中心首次发射。当火箭离开发射台升空30秒时，距地面约4000米，天空中传来两声巨大的爆炸声并出现一

团桔黄色的巨大火球，火箭碎块带着火星撒落在直径约两公里的地面上。与阿丽亚娜5型火箭一同化为灰烬的还有4颗太阳风观察卫星。这是世界航天史上又一大悲剧。

阿丽亚娜5型火箭由欧洲航天局研制，火箭高52.7米，重740吨，研制费用为70亿美元，研制时间1985－1996年，参研人员约万人。事故原因报道：阿丽亚娜5型火箭采用阿丽亚娜4型火箭初始定位软件。软件不适应物理环境的变化。阿丽亚娜5型火箭起飞推力15900KN，重量740吨，阿丽亚娜4型火箭起飞推力5400KN，重量474吨。阿5型火箭加速度=21.5g，阿4型火箭加速度=11.4g。阿丽亚娜5型火箭加速度值输入到计算机系统的整型加速度值产生上溢出，以加速度为参数的速度、位置计算错误，导致惯性导航系统对火箭控制失效，程序只得进入异常处理模块，引爆自毁。箭载两套计算机系统由于硬件、软件完全相同，没有达到软件容错的目的。

导航系统负责参照基于惯性参考系统输入的特定轨道来计算航线矫正。一个惯性参考系统让一个移动体（例如火箭）仅根据来自加速仪和回转仪的传感器数据来计算其位置，也就是说，其计算不参考外部世界的数据。该惯性系统首先必须初始化起始坐标，用火箭的初始瞄准来校准其轴。导航系统在发射前，进行校对计算。为了把地球自转产生的影响计算在内，校对计算的结果需要不断更新。校准计算很复杂，大约需要45分钟才能完成。一旦火箭发射后，校准数据将传给飞行导航系统。根据设计，校准计算在数据传给导航系统后，还将继续50秒。这一决定使导弹发射前的倒计数得以在对准数据传出后、在发动机被点火之前终止，而不必重新启动校准计算（即，不必重新启动45分钟的计算周期）。当发射成功时，校准轮在起飞后为下一个40秒产生待处理的数据。

Ariane5的计算机系统与Ariane4不同，电子仪器多了一倍。有两个惯性参考系统来计算火箭的位置，两台计算机将计划中的轨道和实际轨道进行比较，并用两套控制仪器来控制火箭。如果某个构件出了问题，后备系统将随时接替现行系统。

专为地面设计的校准系统，使用16位字来存储水平速度(对由于风和地球运行产生的位移计算而言，16位是绰绰有余的)。飞行30秒后，Ariane5的水平速度计算产生了溢出，由此引出了一种意外，通过关掉机载计算机来处理这一问题，并把控制权交给后备系统。

讨论：由于校准系统没有得到充分测试，尽管它经过成千上万次测试，但没有一次测试包括了实际轨道上的测试。导航系统被单独地进行了测试。系统项目组制定测试计划，导航系统的构造者执行测试。系统项目组没有意识到在飞行中的校准会引起主处理机的关闭。这一实例充分说明了构件组与系统组缺乏沟通。

教训：军用软件的运行依赖于支撑环境，武器平台的变化可能影响军用软件采集数据的精度、范围和对系统的控制。军用软件重用必须重新进行系统论证和系统测试／试验，决不能想当然。