本文共 2117 字,大约阅读时间需要 7 分钟。
没有测试就没有软件质量,测试没做好,软件问题可能引起灾难或给企业带来巨大损失,因此,开展测试活动是为了保证软件质量。
在计算机的“计算器”程序中输人以下算式:
(4195835/3145727)×3145727— 4195835
这个故事不仅说明软件缺陷所带来的问题,更重要的是说明对待软件缺陷的态度。
英特尔的软件测试工程师在芯片发布之前进行内部测试时已经发现了这个问题,但管理层认为这没有严重到一定要修正,也没有公布这个问题。
当软件缺陷被发现时,英特尔通过新闻发布和公开声明试图掩饰此问题的严重性。
受到压力时,英特尔承诺更换有问题的芯片,但要求用户必须证明自己受到软件缺陷的影响。
结果舆论大哗。因特网新闻组充斥着愤怒的客户要求英特尔解决问题的呼声。得到这个教训之后,英特尔在网站上报告已发现的问题,并认真对待客户在因特网新闻组上的反馈意见。
比英特尔公司损失更大的是美国丹佛市的国际机场。丹佛新国际机场希望被建成现代的 (state-of-the-art)机场,它将拥有复杂的,计算机控制的,自动化的包裹处理系统,而且还有 8530km 长的光纤网络。不幸的是,在这个包裹处理系统中存在一个严重的程序缺陷,导致行李箱被绞碎,居然自动包裹车会一直开着往墙里面钻。结果,机场启用推迟 16 个月,使得预算超过 32 亿美元,并且废弃这个自动化的包裹处理系统,使用手工处理包裹系统。火星探测飞船坠毁是 20世纪末发生的悲剧,而这主要就是由于软件测试没做好。仅仅由于两个测试小组单独进行测试,没有进行很好沟通,缺少一个集成测试的阶段,结果导致1999年美国宇航局的火星探测飞船在试图登陆火星地面时突然坠毁失踪。质量管理小组观测到故障,并认定出现误动作的原因极可能是某一个数据位被意外更改。什么情况下这个数据位被修改了?又为什么没有在内部测试时发现呢?
从理论上看,登陆计划被设计成这样——在飞船降落到火星的过程中,降落伞将被打开,减缓飞船的下落速度。降落伞打开后的几秒钟内,飞船的三条腿将迅速撑开,并在预定地点着陆。当飞船离地面800m 时,它将丢弃降落伞,点燃登陆反推进器,借助反推力来不断降低速度,从而可以使飞船能缓缓降落地面。
美国宇航局为了省钱,简化了确定何时关闭推进器的装置。为了替代其他太空船上使用的贵重雷达,在飞船的脚上装了一个廉价的触点开关,在计算机中设置一个数据位来关掉燃料。很简单,飞船的脚不“着地”,引擎就会点火。不幸的是,质量管理小组在事后的测试中发现,当飞船的脚迅速摆开准备着陆时,机械震动在大多数情况下也会触发着地开关,设置错误的数据位。设想飞船开始着陆时,计算机极有可能关闭推进器,而火星登陆飞船下坠
1800m之后没有反推进器的帮助,冲向地面,必然会撞成碎片。为什么会出现这样的结果?原因很简单。登陆飞船经过了多个小组测试。其中一个小组测试飞船的脚落地过程,但从没有检查那个关键的数据位,因为那不是这个小组负责的范围;另一个小组测试着陆过程的其他部分,但这个小组总是在开始测试之前重置计算机、清除数据位。双方本身的工作都没什么问题,就是没有合在一起测试,其接口没有被测,而问题就在这里,后一个小组没有注意到数据位已经被错误设定。
转载地址:http://cwiwi.baihongyu.com/