软件测试案例

1、案例释疑案例1-1 :终点线前的遗憾 说明： 课堂上讲述该案例，目的是让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺陷都可能带来严重后果。教师不必全部讲述，需摘略其中重点内容。内容：作为长期火星探测战略的一个步骤， 美国航宇局于1998年12月11日和1999年1月3日先 后将两颗探测器送往火星。其中先行一步的火星气候轨道器（MCO ）经过6.65亿公里的飞咒粧射肯肩誠汗行，终于在9月份飞到了火星，但在准备进入 绕火星运行的轨道时，却不慎失手，让关注它 的人们大失所望。令人吃惊的是，此次事故的 原因竟是一个非常低级的失误。根据对进行入轨机动点火前采集到的跟踪数 据的分析，项目官员认为

2、火星气候轨道器失踪 的原因是导航出了重大错误，致使探测器飞到 了比预定高度低很多的高度。实际上，在因飞 入火星背面而与地面正常”地失去联络之前， 探测器就已经走上了一条将把它带到距火星 表面最近仅 57公里的错误路线。这一高度大大低于技术人员提出的约 85100公里的最小安全距离，与预定的140150公里高度更是相差甚远。高度太低，探测器有可能在火星的大气中因气动热而被火葬”甚至还有可能坠毁在火星表面上。事故发生后，主管该项目的美国航宇局喷气推进实验室等部门迅速开始了调查工作。初步分析时认定，问题可能出在卫星软件上，还可能是地面系统的问题，人员操作失误的可能性也不能排除。但最后查出的结果却让人

3、难以置信：造成飞行高度太低的原因竟然是公制和英制的转换问题。调查人员在 9月30日公布的一份报告中称，探测器制造商洛马公司对探测器 的一项关键性操作提供的是英制单位的数据，而美国航宇局喷推实验室的导航人员想当然地以为是公制，未加换算便直接将英制数据输入了采用公制数据的计算机系统内，从而造成了严重的导航错误。问题出在一个导航软件表上。这个出错的推力器校定表用在确定探测器位置的地面导航软件 中。它的作用是把遥测到的推力器点火工作次数转换成提供给探测器的冲量，以消除因推力器点火工作造成的弹道计算中的剩余误差。喷推实验室在编制表时对推力器每次工作的冲量使用的是牛 秒这一公制单位，但由洛马公司提供的数据

4、使用的却是英制的磅秒，而这样计算出的冲量值只是实际值的22%。三轴稳定的该探测器使用反动轮控制姿态，其推力器每隔大约1315小时点火一次，以降低轮的转速。这些点火工作每次只会引起几毫米/秒的速度变化，但每周要进行 11次以上。起初剩余误差很小时，弹道计算可以很快收敛，但到后 来收敛性就比较差了。出现这种低级错误使有关部门感到很难堪。美国航宇局负责空间科学项目的副局长韦勒称， 这已不能简单地说成是错误，这是美国航宇局系统工程工作的失败。案例1-2：一 一五大瘫痪说明：任何设计上的漏课堂上讲述该案例，用于让学员明白软件缺陷的危害及缺陷是不可避免的, 洞都会被别有用心的人利用。教师不必全部讲述，需摘

5、略其中重点内容。内容：1990年1月15日，美国电话电报公司的长途电话交换系统陷入全面瘫痪。这是一起奇怪的、可怕的、波及面广泛的事故。6万名用户的电话无法使用。对电话业来说，服务中断是一种由来已久、素为人知的风险。飓风的侵袭可能会折断上千条电缆，地震会破坏埋在地下的光缆干线，交换站也有可能被大火烧得精光。电话公司为诸如此类的事情制订了紧急应变计划， 多年来也在这方面积累了深厚的经验。然而，一 一五”大瘫痪却令其措手不及。它的影响范围之大令人难以置信，而且，找不出什么明显的物理原因。事故发生在一个星期一的下午，最早是曼哈顿的一家交换站开始出现故障。但是，与一般的物理故障不同，这次故障似乎具有传染

6、性，美国境内一家又一家交换站陆续感染上此类症状。一连串的反应最终摧毁了 AT&T电话网的一半，另一半则由于通话量的急剧增加而手忙脚 乱。在9个小时之内，AT & T的软件工程师们设法弄清了瘫痪的原因。罪犯”是AT & T自己开发的软件中的一个 臭虫”（bug）即程序中的一个错误。这起事故使 AT&T忍垢蒙羞。它对公司长久以来引以为自豪的服务可靠的名声是一个巨大打击。几天后，AT & t的最高首脑鲍勃 艾伦在美国各大报纸上发表了致用户的公开信”，其中说：我们没有达到自己的质量标准。事情就是如此简单。 这对我们来说是不可接受的，对你们来说也是如此 我们十分清楚，人们对 AT &T服务的依赖性有多强

7、，所以贝尔实 验室的科学家和公司的网络工程师正在尽其所能，以确保类似事件下再发生”，在电话业竞争日趋激烈的形势下，这样的声明当然不是这个电信巨头愿意作出的。虽然AT&T就一 一五”大瘫痪向用户进行了公开道歉，但由于技术的复杂性，事故的全部真相及其含义从未被彻底披露和解释过。 引发事故的根本原因鲜有人知，这使它从一开始就 被笼罩在一种扑朔迷离的气氛当中。事情已变得很明白，没有人能够保护”系统不受破坏。而系统到目前为止所遭受的最严重的破坏， 都是系统自身造成的。 这次，没有人再出来说什 么这只是意外事故，永远不会再发生了等等。到1991年，用报道过 一 一五”大瘫痪的斯特林的话说，系统的保卫者们已

8、经遇到了他们最难以捉摸的对手，这个对手就是一一系统本身。案例1-3 :鲜为人知的核危机揭秘说明：课堂上讲述该案例，用于让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺陷都可能带来严重后果。教师不必全部讲述，需摘略其中重点内容。内容：1983年9月26日，苏联刚刚启用的早期预警卫星系统也造成了一次假的核攻击警报。苏联 为了监视洲际弹道导弹实际发射情况，为其预警卫星精心选定了一种特殊的轨道，这种名为“闪电”的卫星，在飞过南半球时，与地球距离极近；但在卫星经过北半球时，与地球的距离越来越远，相当于距离月球的近十分之一。苏联的“眼睛”早期预警卫星高悬于欧洲北部上空，可长时间以准确的观察角度监测

9、美国本土的导弹发射基地。然而，在莫斯科时间1983年9月26日午夜过后不久，太阳、苏联预警卫星与美国导弹基地连成了一条直线，使阳光 在高空云层中的反射强度达到了极点。这种现象是不可预见的，自从该预警卫星系统在前一年投入运行以来，这种罕见的排列奇观恐怕还是首次出现。在接受记者采访时，苏联早期预警卫星系统地下秘密监控中心一一“谢尔普霍夫-15”的负责人斯坦尼斯拉夫彼得罗夫中校指出，新卫星系统监测到美国从其本 土导弹基地发射了数枚导弹。彼得罗夫曾多次收到报告说，美国将发动大规模核打击，企图 凭一次打击就摧毁苏联的武装力量。这次的假警报为什么未能引发核战争呢？也许苏联指挥机关不想仅凭一种全新而独特的系

10、 统所提供的数据就发动一场毁灭人类的核战争。但从另一个角度考虑， 假设阳光反射造成系统报告说美国发射了数百枚导弹的话，那么苏联就很有可能错误地发射导弹进行“还击” 彼得罗夫还说，他拒绝将这一警报向他的上级汇报，是因为“要发动一场战争也绝不会仅发射五枚导弹，区区五枚导弹不会造成多大的破坏。”案例1-4 :两位数加法计算器软件的功能说明说明：该案例介绍了两位数加法计算器软件的功能和操作步骤。需要学员描述如何对该软件进行测 内容：软件功能说明：完成-99到99的两个数的加法计算，每个数据以回车结束输入。 操作步骤举例说明：假设程序启动命令为ADDER 。所进行的操作操作结果键入ADDER后回车屏幕被

11、刷新，在屏幕的左上角看见一个“？”提 示符键入被加数2在“？”后出现数字“ 2”回车第二行出现“？”提示符键入加数3在第二个“？”后出现数字“3”回车在第三行显示“5”，同时下一行出现另一个“？”屏幕显示情况是:？ 2？ 35？案例1-5:案例 1-4测试总结说明： 该案例是案例1-4的加法计算器软件的测试总结。内容：程序的错误有如下几点：1. 设计错误：没有任何提示信息告诉用户程序的功能，用户怎样才能知道自己处在本程序的运行环境中？2. 设计错误：没有在线帮助，用户怎么知道自己要干什么？如果录入了一个错误的数据会 怎么样？这种帮助应该以简洁的语句一直显示在屏幕上。3. 设计错误：用户如何去终

12、止程序的运行？这条帮助信息也应显示在屏幕上。4. 代码错误：计算结果“ 5”的显示没有与其他输入的数据显示对齐。软件测试人员要做的事情：A. 以一个最简单的用例开始，如上所述，以2+3开始。B. 设计程序可以进行处理的一组测试用例，这组测试用例的设计并非是很简单的，我们可以算一算，两位数的范围是从-99到99,实现两个两位数的累加意味着有199*199=39601种可能性，当然没有必要把这39601种可能逐个去试，但究竟应该选择哪些数据测试呢？这里选择了八组数据：测试用例期望结果值说明（备注）99+99198程序所能累加的最大一对数据-99+-99-198程序中并未说明不能对负数进行处理99+

13、-1485第一个大数可能会使程序对第二个数据的处理产生影响-38+9961检查负数与正数的累加56+99155第二个大数对第一个数据的影响9+9189是一位数中的最大值0+00通常程序对“ 0”处理时容易出错0+2323程序可能对“ 0”作了特殊处理，所以需要对“ 0”处在第-78+0-78一位和第二位时的情况均作测试C. 对这八组用例进行测试，记录下测试结果。假设测试结果如下：? 程序对所有的非负数的处理都是正确的；? 程序不允许用户输入两个字符以上的数据，即:当用户输入了两个字符后，再输入任何字符均作为回车符处理，造成了负数的输入只能从-1到-9 ；? 输入了负数后，程序陷入死锁状态，即程

14、序并不具备对负数处理的功能。? 再做一些数据的测试，并做好测试结果记录。例如输入如下数据：测试用例测试目的记录100+100边缘数据，只比99大1程序只接收数据10,把第二个0作 为回车处理回车+回车没有输入数据会怎么 样输出结果为上次的累加结果123456+0输入一个很大的数试 试与100的处理相同1.2+5试试小数输入小数点时程序作为回车处理A+b非法字符的处理敲入A再敲回车时，程序陷入死锁+控制符与功能键的处 理中止了程序的运行，而其他 功能键在屏幕上显示为一些图形，并在回车后陷入死锁状态递交测试总结报告。教师总结：事实上，作为一个好的测试人员，还需要仔细分析程序，例如：计算结果的存储设

15、计、数据输入的存储设计。在这个程序中，计算结果的范围是从-198到198，但程序只能对非负数进行处理，因此实际计算结果的范围是从0到198。如果程序员以一个字节来存储计算结果，则要想能够存储负数，一个字节所能表示的数据的范围只能从-127到127,这时程序在处理大于127的计算结果时就会出错。如果程序对用户输入的字符是根据字符的ASCII码来进行处理的，程序代码表述如下：IF ASCII_CODE_OF_ENTERED_CHAR is less tha n 48THEN reject it as a bad characterELSE IF ASCII CODE IF ENTERED CHAR

16、 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 市政演讲大厅，比尔 盖茨的主题演讲中， 除了向到场的商家和记者介绍和展示视窗20

17、00的强大功能外，还道出了它的研制内幕。可以说，微软视窗 2000的开发过程堪称迄今为止世界上最庞大的软件设计工程之一。其间 巨大的投资，没完没了的分析测试，数千万行程序代码的编辑，所有这一切最终凝结为微软 有史以来最完美的操作系统版本一一视窗2000。毋庸置疑，产品的成功首先还要归功于杰出的开发研制队伍。部分开发人员来到了发布会现场，当盖茨向开发人员致谢时，他们博得了全场最热烈的掌声。据介绍，整个视窗2000项目组有近5000人，其中除微软的开发人员之外，还包括合作伙伴，以及美国当地和全球的 合作开发人员。总的说来，这个庞大的项目组包括四大部分：程序管理员、程序开发员、测 试者和外部的合作伙

18、伴及客户。在视窗2000开发过程中的4年时间里，整个项目组的人员将视窗 2000纳入为他们生活的主 题，下面的日程表描述了他们的典型的一天。每天的工作周期是从下午 3 : 00开始，因为项目组的开发人员在这一时间开始构建产品。开发人员要对有关管理和组织代码的所有方面负责。他们要设计出基于最初方案的原始代码框架，评测其他开发人员的代码以确保质量，并寻求最好的产品可靠性和安全性。这个构建过程包括连接和编译数十亿的视窗2000代码行。晚8 : 00 ,构建过程结束。开发人员完成的产品将移交给校验小组”，也就是测试人员。测试人员负责检验产品的各个性能特征，以保证产品的质量和运行可靠性。这还意味着他们要

19、基于预计的产品性能要求建立许多测试模块和应用，并开发一些工具以识别BUG （程序缺陷）。他们将开发人员做好的模块安装在自己的台式机上以及实验室环境进行全面的测试。据统计，这部分人员超过了1500人。除此之外，还有数以百计的微软beta级合作伙伴。小范围的测试之外，更大范围的测试将彻夜不停地运行，包括产品在网络上的使用情况、最新的补丁程序的性能改进等等。据介绍，视窗2000的测试代码程序的长度同样是数千万行。而在头一天的构建和整夜的测试之后，第二天早9 : 30程序管理员们将准时聚在一起。所谓程序管理员就是客户代言人，他们要做的事情是写下客户需求的每一个细节，并把测试版的有关客户反馈信息传达给开发人员。程序管理员每天一早，根据前一天的进展以及客户的需求将提出新的意见和思路，供开发人员参考。这就是项目组的典型而又完整的一天。日复一日，就是这样经过将近 4年的时间，我们见到了视窗2000。案例1-7:浮点运算不精确产生的灾难说明：课堂上讲述该案例，让学员明白软件缺陷的可能会发生在任何地方，甚至是一些简单的运算中。教师不必全部讲述，需摘略其中重点内容。内容：1991年2月25日，在海