案例释疑案例1-1：终点线前的遗憾说明：课堂上讲述该案例，目的是让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺陷都可能带来严重后果。

教师不必全部讲述，需摘略其中重点内容。

内容：作为长期火星探测战略的一个步骤，美国航宇局于1998年12月11日和1999年1月3日先后将两颗探测器送往火星。

其中先行一步的火星气候轨道器（MCO）经过6.65亿公里的飞行，终于在9月份飞到了火星，但在准备进入绕火星运行的轨道时，却不慎失手，让关注它的人们大失所望。

令人吃惊的是，此次事故的原因竟是一个非常低级的失误。

根据对进行入轨机动点火前采集到的跟踪数据的分析，项目官员认为火星气候轨道器失踪的原因是导航出了重大错误，致使探测器飞到了比预定高度低很多的高度。

实际上，在因飞入火星背面而与地面“正常”地失去联络之前，探测器就已经走上了一条将把它带到距火星表面最近仅57公里的错误路线。

这一高度大大低于技术人员提出的约85～100公里的最小安全距离，与预定的140～150公里高度更是相差甚远。

高度太低，探测器有可能在火星的大气中因气动热而被“火葬”，甚至还有可能坠毁在火星表面上。

事故发生后，主管该项目的美国航宇局喷气推进实验室等部门迅速开始了调查工作。

初步分析时认定，问题可能出在卫星软件上，还可能是地面系统的问题，人员操作失误的可能性也不能排除。

但最后查出的结果却让人难以置信：造成飞行高度太低的原因竟然是公制和英制的转换问题。

调查人员在9月30日公布的一份报告中称，探测器制造商洛马公司对探测器的一项关键性操作提供的是英制单位的数据，而美国航宇局喷推实验室的导航人员想当然地以为是公制，未加换算便直接将英制数据输入了采用公制数据的计算机系统内，从而造成了严重的导航错误。

问题出在一个导航软件表上。

这个出错的推力器校定表用在确定探测器位置的地面导航软件中。

它的作用是把遥测到的推力器点火工作次数转换成提供给探测器的冲量，以消除因推力器点火工作造成的弹道计算中的剩余误差。

喷推实验室在编制表时对推力器每次工作的冲量使用的是牛·秒这一公制单位，但由洛马公司提供的数据使用的却是英制的磅·秒，而这样计算出的冲量值只是实际值的22%。

三轴稳定的该探测器使用反动轮控制姿态，其推力器每隔大约13～15小时点火一次，以降低轮的转速。

这些点火工作每次只会引起几毫米/秒的速度变化，但每周要进行11次以上。

起初剩余误差很小时，弹道计算可以很快收敛，但到后来收敛性就比较差了。

出现这种低级错误使有关部门感到很难堪。

美国航宇局负责空间科学项目的副局长韦勒称，这已不能简单地说成是错误，这是美国航宇局系统工程工作的失败。

案例1-2：“一·一五”大瘫痪说明：课堂上讲述该案例，用于让学员明白软件缺陷的危害及缺陷是不可避免的，任何设计上的漏洞都会被别有用心的人利用。

教师不必全部讲述，需摘略其中重点内容。

内容：1990年1月15日，美国电话电报公司的长途电话交换系统陷入全面瘫痪。

这是一起奇怪的、可怕的、波及面广泛的事故。

6万名用户的电话无法使用。

对电话业来说，服务中断是一种由来已久、素为人知的风险。

飓风的侵袭可能会折断上千条电缆，地震会破坏埋在地下的光缆干线，交换站也有可能被大火烧得精光。

电话公司为诸如此类的事情制订了紧急应变计划，多年来也在这方面积累了深厚的经验。

然而，“一·一五”大瘫痪却令其措手不及。

它的影响范围之大令人难以置信，而且，找不出什么明显的物理原因。

事故发生在一个星期一的下午，最早是曼哈顿的一家交换站开始出现故障。

但是，与一般的物理故障不同，这次故障似乎具有传染性，美国境内一家又一家交换站陆续感染上此类症状。

一连串的反应最终摧毁了AT&T电话网的一半，另一半则由于通话量的急剧增加而手忙脚乱。

在9个小时之内，AT＆T的软件工程师们设法弄清了瘫痪的原因。

“罪犯”是AT＆T自己开发的软件中的一个“臭虫”（bug）——即程序中的一个错误。

这起事故使AT＆T忍垢蒙羞。

它对公司长久以来引以为自豪的服务可靠的名声是一个巨大打击。

几天后，AT＆t 的最高首脑鲍勃·艾伦在美国各大报纸上发表了“致用户的公开信”，其中说：“我们没有达到自己的质量标准。

事情就是如此简单。

这对我们来说是不可接受的，对你们来说也是如此……我们十分清楚，人们对AT＆T服务的依赖性有多强，所以贝尔实验室的科学家和公司的网络工程师正在尽其所能，以确保类似事件下再发生……”，在电话业竞争日趋激烈的形势下，这样的声明当然不是这个电信巨头愿意作出的。

虽然AT＆T就“一·一五”大瘫痪向用户进行了公开道歉，但由于技术的复杂性，事故的全部真相及其含义从未被彻底披露和解释过。

引发事故的根本原因鲜有人知，这使它从一开始就被笼罩在一种扑朔迷离的气氛当中。

事情已变得很明白，没有人能够“保护”系统不受破坏。

而系统到目前为止所遭受的最严重的破坏，都是系统自身造成的。

这次，没有人再出来说什么这只是意外事故，永远不会再发生了等等。

到1991年，用报道过“一·一五”大瘫痪的斯特林的话说，系统的保卫者们已经遇到了他们最难以捉摸的对手，这个对手就是——系统本身。

案例1-3：鲜为人知的核危机揭秘说明：课堂上讲述该案例，用于让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺陷都可能带来严重后果。

教师不必全部讲述，需摘略其中重点内容。

内容：1983年9月26日，苏联刚刚启用的早期预警卫星系统也造成了一次假的核攻击警报。

苏联为了监视洲际弹道导弹实际发射情况，为其预警卫星精心选定了一种特殊的轨道，这种名为“闪电”的卫星，在飞过南半球时，与地球距离极近；但在卫星经过北半球时，与地球的距离越来越远，相当于距离月球的近十分之一。

苏联的“眼睛”早期预警卫星高悬于欧洲北部上空，可长时间以准确的观察角度监测美国本土的导弹发射基地。

然而，在莫斯科时间1983年9月26日午夜过后不久，太阳、苏联预警卫星与美国导弹基地连成了一条直线，使阳光在高空云层中的反射强度达到了极点。

这种现象是不可预见的，自从该预警卫星系统在前一年投入运行以来，这种罕见的排列奇观恐怕还是首次出现。

在接受记者采访时，苏联早期预警卫星系统地下秘密监控中心——“谢尔普霍夫-15”的负责人斯坦尼斯拉夫·彼得罗夫中校指出，新卫星系统监测到美国从其本土导弹基地发射了数枚导弹。

彼得罗夫曾多次收到报告说，美国将发动大规模核打击，企图凭一次打击就摧毁苏联的武装力量。

这次的假警报为什么未能引发核战争呢？也许苏联指挥机关不想仅凭一种全新而独特的系统所提供的数据就发动一场毁灭人类的核战争。

但从另一个角度考虑，假设阳光反射造成系统报告说美国发射了数百枚导弹的话，那么苏联就很有可能错误地发射导弹进行“还击”。

彼得罗夫还说，他拒绝将这一警报向他的上级汇报，是因为“要发动一场战争也绝不会仅发射五枚导弹，区区五枚导弹不会造成多大的破坏。

”案例1-4：两位数加法计算器软件的功能说明说明：该案例介绍了两位数加法计算器软件的功能和操作步骤。

需要学员描述如何对该软件进行测试。

内容：软件功能说明：完成-99到99的两个数的加法计算，每个数据以回车结束输入。

屏幕显示情况是：？2？35？案例1-5：案例1-4测试总结说明：该案例是案例1-4的加法计算器软件的测试总结。

内容：程序的错误有如下几点：1.设计错误：没有任何提示信息告诉用户程序的功能，用户怎样才能知道自己处在本程序的运行环境中？2.设计错误：没有在线帮助，用户怎么知道自己要干什么？如果录入了一个错误的数据会怎么样？这种帮助应该以简洁的语句一直显示在屏幕上。

3.设计错误：用户如何去终止程序的运行？这条帮助信息也应显示在屏幕上。

4.代码错误：计算结果“5”的显示没有与其他输入的数据显示对齐。

软件测试人员要做的事情：A.以一个最简单的用例开始，如上所述，以2+3开始。

B.设计程序可以进行处理的一组测试用例，这组测试用例的设计并非是很简单的，我们可以算一算，两位数的范围是从-99到99，实现两个两位数的累加意味着有199*199=39601种可能性，当然没有必要把这39601种可能逐个去试，但究竟应该选择哪些数据测试呢？这里选择了八组数据：C. 对这八组用例进行测试，记录下测试结果。

假设测试结果如下：程序对所有的非负数的处理都是正确的；程序不允许用户输入两个字符以上的数据，即：当用户输入了两个字符后，再输入任何字符均作为回车符处理，造成了负数的输入只能从-1到-9；输入了负数后，程序陷入死锁状态，即程序并不具备对负数处理的功能。

教师总结：事实上，作为一个好的测试人员，还需要仔细分析程序，例如：计算结果的存储设计、数据输入的存储设计。

在这个程序中，计算结果的范围是从-198到198，但程序只能对非负数进行处理，因此实际计算结果的范围是从0到198。

如果程序员以一个字节来存储计算结果，则要想能够存储负数，一个字节所能表示的数据的范围只能从-127到127，这时程序在处理大于127的计算结果时就会出错。

如果程序对用户输入的字符是根据字符的ASCII 码来进行处理的，程序代码表述如下：IF ASCII_CODE_OF_ENTERED_CHAR is less than 48THEN reject it as a bad characterELSE IF ASCII_CODE_IF_ENTERED_CHAR is greater than 57THEN reject it as a bad characterELSE it is a digit , so accept it .此时，测试人员就需要对这些判断条件的临界值（47、48、57、58）进行测试，以确定程序员没有写错判断条件。

案例1-6：Win2000成功内幕说明：课堂上讲述该案例，用于让学员明白Windows 2000操作系统在开发过程中，测试所起到的作用。

教师不必全部讲述，需摘略其中重点内容。

内容：2000年2月17日，在旧金山的BILL GRAHAM市政演讲大厅，比尔·盖茨的主题演讲中，除了向到场的商家和记者介绍和展示视窗2000的强大功能外，还道出了它的研制内幕。

可以说，微软视窗2000的开发过程堪称迄今为止世界上最庞大的软件设计工程之一。

其间巨大的投资，没完没了的分析测试，数千万行程序代码的编辑，所有这一切最终凝结为微软有史以来最完美的操作系统版本——视窗2000。

毋庸置疑，产品的成功首先还要归功于杰出的开发研制队伍。

部分开发人员来到了发布会现场，当盖茨向开发人员致谢时，他们博得了全场最热烈的掌声。

据介绍，整个视窗2000项目组有近5000人，其中除微软的开发人员之外，还包括合作伙伴，以及美国当地和全球的合作开发人员。