软件测试案例

《软件测试案例》由会员分享，可在线阅读，更多相关《软件测试案例（6页珍藏版）》请在金锄头文库上搜索。

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 个小时之内，ATT 的软件工程师们设法弄清了瘫痪的原因。 “罪犯”是 ATT 自己开 发的软件中的一个“臭虫”（bug）即程序中的一个错误。 这起事故使 ATT 忍垢蒙羞。它对公司长久以来引以为自豪的服务可靠的名声是一个巨大 打击。几天后，ATt 的最高首脑鲍勃艾伦

7、在美国各大报纸上发表了“致用户的公开信”， 其中说：“我们没有达到自己的质量标准。事情就是如此简单。这对我们来说是不可接受的， 对你们来说也是如此我们十分清楚，人们对 ATT 服务的依赖性有多强，所以贝尔实 验室的科学家和公司的网络工程师正在尽其所能，以确保类似事件下再发生”，在电话 业竞争日趋激烈的形势下，这样的声明当然不是这个电信巨头愿意作出的。 虽然 ATT 就“一一五”大瘫痪向用户进行了公开道歉，但由于技术的复杂性，事故的全 部真相及其含义从未被彻底披露和解释过。引发事故的根本原因鲜有人知，这使它从一开 始就被笼罩在一种扑朔迷离的气氛当中。事情已变得很明白，没有人能够“保护”系统不受

8、破坏。而系统到目前为止所遭受的最严重的破坏，都是系统自身造成的。这次，没有人再 出来说什么这只是意外事故，永远不会再发生了等等。到 1991 年，用报道过“一一五”大 瘫痪的斯特林的话说，系统的保卫者们已经遇到了他们最难以捉摸的对手，这个对手就是 系统本身。案例案例 1-3：鲜为人知的核危机揭秘：鲜为人知的核危机揭秘 说明：说明： 课堂上讲述该案例，用于让学员明白软件在现代科学中的地位是非常重要的，丝毫软件缺 陷都可能带来严重后果。教师不必全部讲述，需摘略其中重点内容。 内容：内容： 1983 年 9 月 26 日，苏联刚刚启用的早期预警卫星系统也造成了一次假的核攻击警报。苏 联为了监视洲际弹

9、道导弹实际发射情况，为其预警卫星精心选定了一种特殊的轨道，这种 名为“闪电”的卫星，在飞过南半球时，与地球距离极近；但在卫星经过北半球时，与地 球的距离越来越远，相当于距离月球的近十分之一。苏联的“眼睛”早期预警卫星高悬于 欧洲北部上空，可长时间以准确的观察角度监测美国本土的导弹发射基地。然而，在莫斯 科时间 1983 年 9 月 26 日午夜过后不久，太阳、苏联预警卫星与美国导弹基地连成了一条 直线，使阳光在高空云层中的反射强度达到了极点。 这种现象是不可预见的，自从该预警卫星系统在前一年投入运行以来，这种罕见的排列奇 观恐怕还是首次出现。在接受记者采访时，苏联早期预警卫星系统地下秘密监控中

10、心 “谢尔普霍夫-15”的负责人斯坦尼斯拉夫彼得罗夫中校指出，新卫星系统监测到美国从 其本土导弹基地发射了数枚导弹。彼得罗夫曾多次收到报告说，美国将发动大规模核打击，企图凭一次打击就摧毁苏联的武装力量。 这次的假警报为什么未能引发核战争呢？也许苏联指挥机关不想仅凭一种全新而独特的系 统所提供的数据就发动一场毁灭人类的核战争。但从另一个角度考虑，假设阳光反射造成 系统报告说美国发射了数百枚导弹的话，那么苏联就很有可能错误地发射导弹进行“还击” 。 彼得罗夫还说，他拒绝将这一警报向他的上级汇报，是因为“要发动一场战争也绝不会仅 发射五枚导弹，区区五枚导弹不会造成多大的破坏。 ” 案例案例 1-4：

11、两位数加法计算器软件的功能说明：两位数加法计算器软件的功能说明 说明：说明： 该案例介绍了两位数加法计算器软件的功能和操作步骤。需要学员描述如何对该软件进行 测试。 内容：内容： 软件功能说明：完成-99 到 99 的两个数的加法计算，每个数据以回车结束输入。 操作步骤举例说明：假设程序启动命令为 ADDER。所进行的操作操作结果键入 ADDER 后回车屏幕被刷新，在屏幕的左上角看见一个“？”提 示符键入被加数 2在“？”后出现数字“2”回车第二行出现“？”提示符键入加数 3在第二个“？”后出现数字“3”回车在第三行显示“5”，同时下一行出现另一个 “？” 屏幕显示情况是： ？2 ？3 5？案

12、例案例 1-5：案例：案例 1-4 测试总结测试总结 说明：说明： 该案例是案例 1-4 的加法计算器软件的测试总结。 内容：内容： 程序的错误有如下几点： 1.设计错误：没有任何提示信息告诉用户程序的功能，用户怎样才能知道自己处在本程 序的运行环境中？ 2.设计错误：没有在线帮助，用户怎么知道自己要干什么？如果录入了一个错误的数据 会怎么样？这种帮助应该以简洁的语句一直显示在屏幕上。 3.设计错误：用户如何去终止程序的运行？这条帮助信息也应显示在屏幕上。 4.代码错误：计算结果“5”的显示没有与其他输入的数据显示对齐。软件测试人员要做的事情： A.以一个最简单的用例开始，如上所述，以 2+3

13、 开始。 B.设计程序可以进行处理的一组测试用例，这组测试用例的设计并非是很简单的，我们 可以算一算，两位数的范围是从-99 到 99，实现两个两位数的累加意味着有199*199=39601 种可能性，当然没有必要把这 39601 种可能逐个去试，但究竟应该选 择哪些数据测试呢？这里选择了八组数据：测试用例期望结果值说明（备注）99+99198程序所能累加的最大一对数据-99+-99-198程序中并未说明不能对负数进行处理99+-1485第一个大数可能会使程序对第二个数据的处理产生影响-38+9961检查负数与正数的累加56+99155第二个大数对第一个数据的影响9+9189 是一位数中的最大

14、值0+00通常程序对“0”处理时容易出错0+23 -78+023 -78程序可能对“0”作了特殊处理，所以需要对“0”处在 第一位和第二位时的情况均作测试C.对这八组用例进行测试，记录下测试结果。假设测试结果如下： 程序对所有的非负数的处理都是正确的； 程序不允许用户输入两个字符以上的数据，即：当用户输入了两个字符后，再输 入任何字符均作为回车符处理，造成了负数的输入只能从-1 到-9； 输入了负数后，程序陷入死锁状态，即程序并不具备对负数处理的功能。 再做一些数据的测试，并做好测试结果记录。例如输入如下数据：测试用例测试目的记录100+100边缘数据，只比 99 大 1程序只接收数据 10，

15、把第二个 0 作 为回车处理回车+回车没有输入数据会怎么 样输出结果为上次的累加结果123456+0输入一个很大的数试 试与 100 的处理相同1.2+5试试小数输入小数点时程序作为回车处理A+b非法字符的处理敲入 A 再敲回车时，程序陷入死锁+ + +控制符与功能键的处 理中止了程序的运行，而其他 功能键在屏幕上显示为一些图形， 并在回车后陷入死锁状态递交测试总结报告。教师总结： 事实上，作为一个好的测试人员，还需要仔细分析程序，例如：计算结果的存储设计、数 据输入的存储设计。在这个程序中，计算结果的范围是从-198 到 198，但程序只能对非负 数进行处理，因此实际计算结果的范围是从 0

16、到 198。如果程序员以一个字节来存储计算 结果，则要想能够存储负数，一个字节所能表示的数据的范围只能从-127 到 127，这时程 序在处理大于 127 的计算结果时就会出错。如果程序对用户输入的字符是根据字符的 ASCII 码来进行处理的，程序代码表述如下： IF ASCII_CODE_OF_ENTERED_CHAR is less than 48 THEN reject it as a bad character ELSE IF ASCII_CODE_IF_ENTERED_CHAR is greater than 57 THEN reject it as a bad character ELSE it is a digit , so accept it .此时，测试人员就需要对这些判断条件的临界值（47、48、57、58）进行测试，以确定程 序员没有写错判断条件。案例案例 1-6：Win2000 成功内幕成功内幕 说明：说明： 课堂上讲述该案例，用于让学员明白 Windows 2000 操作系统在开发过程