軟件測試案例

1、案例釋疑案例1-1 :終點線前的遺憾 說明： 課堂上講述該案例，目的是讓學(xué)員明白軟件在現(xiàn)代科學(xué)中的地位是非常重要的，絲毫軟件缺陷都可能帶來嚴(yán)重后果。教師不必全部講述，需摘略其中重點內(nèi)容。內(nèi)容：作為長期火星探測戰(zhàn)略的一個步驟， 美國航宇局于1998年12月11日和1999年1月3日先 后將兩顆探測器送往火星。其中先行一步的火星氣候軌道器（MCO ）經(jīng)過6.65億公里的飛咒粧射肯肩誠汗行，終于在9月份飛到了火星，但在準(zhǔn)備進入 繞火星運行的軌道時，卻不慎失手，讓關(guān)注它 的人們大失所望。令人吃驚的是，此次事故的 原因竟是一個非常低級的失誤。根據(jù)對進行入軌機動點火前采集到的跟蹤數(shù) 據(jù)的分析，項目官員認為

2、火星氣候軌道器失蹤 的原因是導(dǎo)航出了重大錯誤，致使探測器飛到 了比預(yù)定高度低很多的高度。實際上，在因飛 入火星背面而與地面正常”地失去聯(lián)絡(luò)之前， 探測器就已經(jīng)走上了一條將把它帶到距火星 表面最近僅 57公里的錯誤路線。這一高度大大低于技術(shù)人員提出的約 85100公里的最小安全距離，與預(yù)定的140150公里高度更是相差甚遠。高度太低，探測器有可能在火星的大氣中因氣動熱而被火葬”甚至還有可能墜毀在火星表面上。事故發(fā)生后，主管該項目的美國航宇局噴氣推進實驗室等部門迅速開始了調(diào)查工作。初步分析時認定，問題可能出在衛(wèi)星軟件上，還可能是地面系統(tǒng)的問題，人員操作失誤的可能性也不能排除。但最后查出的結(jié)果卻讓人

3、難以置信：造成飛行高度太低的原因竟然是公制和英制的轉(zhuǎn)換問題。調(diào)查人員在 9月30日公布的一份報告中稱，探測器制造商洛馬公司對探測器 的一項關(guān)鍵性操作提供的是英制單位的數(shù)據(jù)，而美國航宇局噴推實驗室的導(dǎo)航人員想當(dāng)然地以為是公制，未加換算便直接將英制數(shù)據(jù)輸入了采用公制數(shù)據(jù)的計算機系統(tǒng)內(nèi)，從而造成了嚴(yán)重的導(dǎo)航錯誤。問題出在一個導(dǎo)航軟件表上。這個出錯的推力器校定表用在確定探測器位置的地面導(dǎo)航軟件 中。它的作用是把遙測到的推力器點火工作次數(shù)轉(zhuǎn)換成提供給探測器的沖量，以消除因推力器點火工作造成的彈道計算中的剩余誤差。噴推實驗室在編制表時對推力器每次工作的沖量使用的是牛 秒這一公制單位，但由洛馬公司提供的數(shù)據(jù)

4、使用的卻是英制的磅秒，而這樣計算出的沖量值只是實際值的22%。三軸穩(wěn)定的該探測器使用反動輪控制姿態(tài)，其推力器每隔大約1315小時點火一次，以降低輪的轉(zhuǎn)速。這些點火工作每次只會引起幾毫米/秒的速度變化，但每周要進行 11次以上。起初剩余誤差很小時，彈道計算可以很快收斂，但到后 來收斂性就比較差了。出現(xiàn)這種低級錯誤使有關(guān)部門感到很難堪。美國航宇局負責(zé)空間科學(xué)項目的副局長韋勒稱， 這已不能簡單地說成是錯誤，這是美國航宇局系統(tǒng)工程工作的失敗。案例1-2：一 一五大癱瘓說明：任何設(shè)計上的漏課堂上講述該案例，用于讓學(xué)員明白軟件缺陷的危害及缺陷是不可避免的, 洞都會被別有用心的人利用。教師不必全部講述，需摘

5、略其中重點內(nèi)容。內(nèi)容：1990年1月15日，美國電話電報公司的長途電話交換系統(tǒng)陷入全面癱瘓。這是一起奇怪的、可怕的、波及面廣泛的事故。6萬名用戶的電話無法使用。對電話業(yè)來說，服務(wù)中斷是一種由來已久、素為人知的風(fēng)險。颶風(fēng)的侵襲可能會折斷上千條電纜，地震會破壞埋在地下的光纜干線，交換站也有可能被大火燒得精光。電話公司為諸如此類的事情制訂了緊急應(yīng)變計劃， 多年來也在這方面積累了深厚的經(jīng)驗。然而，一 一五”大癱瘓卻令其措手不及。它的影響范圍之大令人難以置信，而且，找不出什么明顯的物理原因。事故發(fā)生在一個星期一的下午，最早是曼哈頓的一家交換站開始出現(xiàn)故障。但是，與一般的物理故障不同，這次故障似乎具有傳染

6、性，美國境內(nèi)一家又一家交換站陸續(xù)感染上此類癥狀。一連串的反應(yīng)最終摧毀了 AT&T電話網(wǎng)的一半，另一半則由于通話量的急劇增加而手忙腳 亂。在9個小時之內(nèi)，AT & T的軟件工程師們設(shè)法弄清了癱瘓的原因。罪犯”是AT & T自己開發(fā)的軟件中的一個 臭蟲”（bug）即程序中的一個錯誤。這起事故使 AT&T忍垢蒙羞。它對公司長久以來引以為自豪的服務(wù)可靠的名聲是一個巨大打擊。幾天后，AT & t的最高首腦鮑勃 艾倫在美國各大報紙上發(fā)表了致用戶的公開信”，其中說：我們沒有達到自己的質(zhì)量標(biāo)準(zhǔn)。事情就是如此簡單。 這對我們來說是不可接受的，對你們來說也是如此 我們十分清楚，人們對 AT &T服務(wù)的依賴性有多強

7、，所以貝爾實 驗室的科學(xué)家和公司的網(wǎng)絡(luò)工程師正在盡其所能，以確保類似事件下再發(fā)生”，在電話業(yè)競爭日趨激烈的形勢下，這樣的聲明當(dāng)然不是這個電信巨頭愿意作出的。雖然AT&T就一 一五”大癱瘓向用戶進行了公開道歉，但由于技術(shù)的復(fù)雜性，事故的全部真相及其含義從未被徹底披露和解釋過。 引發(fā)事故的根本原因鮮有人知，這使它從一開始就 被籠罩在一種撲朔迷離的氣氛當(dāng)中。事情已變得很明白，沒有人能夠保護”系統(tǒng)不受破壞。而系統(tǒng)到目前為止所遭受的最嚴(yán)重的破壞， 都是系統(tǒng)自身造成的。 這次，沒有人再出來說什 么這只是意外事故，永遠不會再發(fā)生了等等。到1991年，用報道過 一 一五”大癱瘓的斯特林的話說，系統(tǒng)的保衛(wèi)者們已

8、經(jīng)遇到了他們最難以捉摸的對手，這個對手就是一一系統(tǒng)本身。案例1-3 :鮮為人知的核危機揭秘說明：課堂上講述該案例，用于讓學(xué)員明白軟件在現(xiàn)代科學(xué)中的地位是非常重要的，絲毫軟件缺陷都可能帶來嚴(yán)重后果。教師不必全部講述，需摘略其中重點內(nèi)容。內(nèi)容：1983年9月26日，蘇聯(lián)剛剛啟用的早期預(yù)警衛(wèi)星系統(tǒng)也造成了一次假的核攻擊警報。蘇聯(lián) 為了監(jiān)視洲際彈道導(dǎo)彈實際發(fā)射情況，為其預(yù)警衛(wèi)星精心選定了一種特殊的軌道，這種名為“閃電”的衛(wèi)星，在飛過南半球時，與地球距離極近；但在衛(wèi)星經(jīng)過北半球時，與地球的距離越來越遠，相當(dāng)于距離月球的近十分之一。蘇聯(lián)的“眼睛”早期預(yù)警衛(wèi)星高懸于歐洲北部上空，可長時間以準(zhǔn)確的觀察角度監(jiān)測

9、美國本土的導(dǎo)彈發(fā)射基地。然而，在莫斯科時間1983年9月26日午夜過后不久，太陽、蘇聯(lián)預(yù)警衛(wèi)星與美國導(dǎo)彈基地連成了一條直線，使陽光 在高空云層中的反射強度達到了極點。這種現(xiàn)象是不可預(yù)見的，自從該預(yù)警衛(wèi)星系統(tǒng)在前一年投入運行以來，這種罕見的排列奇觀恐怕還是首次出現(xiàn)。在接受記者采訪時，蘇聯(lián)早期預(yù)警衛(wèi)星系統(tǒng)地下秘密監(jiān)控中心一一“謝爾普霍夫-15”的負責(zé)人斯坦尼斯拉夫彼得羅夫中校指出，新衛(wèi)星系統(tǒng)監(jiān)測到美國從其本 土導(dǎo)彈基地發(fā)射了數(shù)枚導(dǎo)彈。彼得羅夫曾多次收到報告說，美國將發(fā)動大規(guī)模核打擊，企圖 憑一次打擊就摧毀蘇聯(lián)的武裝力量。這次的假警報為什么未能引發(fā)核戰(zhàn)爭呢？也許蘇聯(lián)指揮機關(guān)不想僅憑一種全新而獨特的系

10、 統(tǒng)所提供的數(shù)據(jù)就發(fā)動一場毀滅人類的核戰(zhàn)爭。但從另一個角度考慮， 假設(shè)陽光反射造成系統(tǒng)報告說美國發(fā)射了數(shù)百枚導(dǎo)彈的話，那么蘇聯(lián)就很有可能錯誤地發(fā)射導(dǎo)彈進行“還擊” 彼得羅夫還說，他拒絕將這一警報向他的上級匯報，是因為“要發(fā)動一場戰(zhàn)爭也絕不會僅發(fā)射五枚導(dǎo)彈，區(qū)區(qū)五枚導(dǎo)彈不會造成多大的破壞?！卑咐?-4 :兩位數(shù)加法計算器軟件的功能說明說明：該案例介紹了兩位數(shù)加法計算器軟件的功能和操作步驟。需要學(xué)員描述如何對該軟件進行測 內(nèi)容：軟件功能說明：完成-99到99的兩個數(shù)的加法計算，每個數(shù)據(jù)以回車結(jié)束輸入。 操作步驟舉例說明：假設(shè)程序啟動命令為ADDER 。所進行的操作操作結(jié)果鍵入ADDER后回車屏幕被

11、刷新，在屏幕的左上角看見一個“？”提 示符鍵入被加數(shù)2在“？”后出現(xiàn)數(shù)字“ 2”回車第二行出現(xiàn)“？”提示符鍵入加數(shù)3在第二個“？”后出現(xiàn)數(shù)字“3”回車在第三行顯示“5”，同時下一行出現(xiàn)另一個“？”屏幕顯示情況是:？ 2？ 35？案例1-5:案例 1-4測試總結(jié)說明： 該案例是案例1-4的加法計算器軟件的測試總結(jié)。內(nèi)容：程序的錯誤有如下幾點：1. 設(shè)計錯誤：沒有任何提示信息告訴用戶程序的功能，用戶怎樣才能知道自己處在本程序的運行環(huán)境中？2. 設(shè)計錯誤：沒有在線幫助，用戶怎么知道自己要干什么？如果錄入了一個錯誤的數(shù)據(jù)會 怎么樣？這種幫助應(yīng)該以簡潔的語句一直顯示在屏幕上。3. 設(shè)計錯誤：用戶如何去終

12、止程序的運行？這條幫助信息也應(yīng)顯示在屏幕上。4. 代碼錯誤：計算結(jié)果“ 5”的顯示沒有與其他輸入的數(shù)據(jù)顯示對齊。軟件測試人員要做的事情：A. 以一個最簡單的用例開始，如上所述，以2+3開始。B. 設(shè)計程序可以進行處理的一組測試用例，這組測試用例的設(shè)計并非是很簡單的，我們可以算一算，兩位數(shù)的范圍是從-99到99,實現(xiàn)兩個兩位數(shù)的累加意味著有199*199=39601種可能性，當(dāng)然沒有必要把這39601種可能逐個去試，但究竟應(yīng)該選擇哪些數(shù)據(jù)測試呢？這里選擇了八組數(shù)據(jù)：測試用例期望結(jié)果值說明（備注）99+99198程序所能累加的最大一對數(shù)據(jù)-99+-99-198程序中并未說明不能對負數(shù)進行處理99+

13、-1485第一個大數(shù)可能會使程序?qū)Φ诙€數(shù)據(jù)的處理產(chǎn)生影響-38+9961檢查負數(shù)與正數(shù)的累加56+99155第二個大數(shù)對第一個數(shù)據(jù)的影響9+9189是一位數(shù)中的最大值0+00通常程序?qū)Α?0”處理時容易出錯0+2323程序可能對“ 0”作了特殊處理，所以需要對“ 0”處在第-78+0-78一位和第二位時的情況均作測試C. 對這八組用例進行測試，記錄下測試結(jié)果。假設(shè)測試結(jié)果如下：? 程序?qū)λ械姆秦摂?shù)的處理都是正確的；? 程序不允許用戶輸入兩個字符以上的數(shù)據(jù)，即:當(dāng)用戶輸入了兩個字符后，再輸入任何字符均作為回車符處理，造成了負數(shù)的輸入只能從-1到-9 ；? 輸入了負數(shù)后，程序陷入死鎖狀態(tài)，即程

14、序并不具備對負數(shù)處理的功能。? 再做一些數(shù)據(jù)的測試，并做好測試結(jié)果記錄。例如輸入如下數(shù)據(jù)：測試用例測試目的記錄100+100邊緣數(shù)據(jù)，只比99大1程序只接收數(shù)據(jù)10,把第二個0作 為回車處理回車+回車沒有輸入數(shù)據(jù)會怎么 樣輸出結(jié)果為上次的累加結(jié)果123456+0輸入一個很大的數(shù)試 試與100的處理相同1.2+5試試小數(shù)輸入小數(shù)點時程序作為回車處理A+b非法字符的處理敲入A再敲回車時，程序陷入死鎖+控制符與功能鍵的處 理中止了程序的運行，而其他 功能鍵在屏幕上顯示為一些圖形，并在回車后陷入死鎖狀態(tài)遞交測試總結(jié)報告。教師總結(jié)：事實上，作為一個好的測試人員，還需要仔細分析程序，例如：計算結(jié)果的存儲設(shè)

15、計、數(shù)據(jù)輸入的存儲設(shè)計。在這個程序中，計算結(jié)果的范圍是從-198到198，但程序只能對非負數(shù)進行處理，因此實際計算結(jié)果的范圍是從0到198。如果程序員以一個字節(jié)來存儲計算結(jié)果，則要想能夠存儲負數(shù)，一個字節(jié)所能表示的數(shù)據(jù)的范圍只能從-127到127,這時程序在處理大于127的計算結(jié)果時就會出錯。如果程序?qū)τ脩糨斎氲淖址歉鶕?jù)字符的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成功內(nèi)幕說明課堂上講述該案例，用于讓學(xué)員明白Windows 2000操作系統(tǒng)在開發(fā)過程中，測試所起到的作用。教師不必全部講述，需摘略其中重點內(nèi)容。內(nèi)容：2000年2月17日，在舊金山的 BILL GRAHAM 市政演講大廳，比爾 蓋茨的主題演講中， 除了向到場的商家和記者介紹和展示視窗20

17、00的強大功能外，還道出了它的研制內(nèi)幕?？梢哉f，微軟視窗 2000的開發(fā)過程堪稱迄今為止世界上最龐大的軟件設(shè)計工程之一。其間 巨大的投資，沒完沒了的分析測試，數(shù)千萬行程序代碼的編輯，所有這一切最終凝結(jié)為微軟 有史以來最完美的操作系統(tǒng)版本一一視窗2000。毋庸置疑，產(chǎn)品的成功首先還要歸功于杰出的開發(fā)研制隊伍。部分開發(fā)人員來到了發(fā)布會現(xiàn)場，當(dāng)蓋茨向開發(fā)人員致謝時，他們博得了全場最熱烈的掌聲。據(jù)介紹，整個視窗2000項目組有近5000人，其中除微軟的開發(fā)人員之外，還包括合作伙伴，以及美國當(dāng)?shù)睾腿虻?合作開發(fā)人員?？偟恼f來，這個龐大的項目組包括四大部分：程序管理員、程序開發(fā)員、測 試者和外部的合作伙

18、伴及客戶。在視窗2000開發(fā)過程中的4年時間里，整個項目組的人員將視窗 2000納入為他們生活的主 題，下面的日程表描述了他們的典型的一天。每天的工作周期是從下午 3 : 00開始，因為項目組的開發(fā)人員在這一時間開始構(gòu)建產(chǎn)品。開發(fā)人員要對有關(guān)管理和組織代碼的所有方面負責(zé)。他們要設(shè)計出基于最初方案的原始代碼框架，評測其他開發(fā)人員的代碼以確保質(zhì)量，并尋求最好的產(chǎn)品可靠性和安全性。這個構(gòu)建過程包括連接和編譯數(shù)十億的視窗2000代碼行。晚8 : 00 ,構(gòu)建過程結(jié)束。開發(fā)人員完成的產(chǎn)品將移交給校驗小組”，也就是測試人員。測試人員負責(zé)檢驗產(chǎn)品的各個性能特征，以保證產(chǎn)品的質(zhì)量和運行可靠性。這還意味著他們要

19、基于預(yù)計的產(chǎn)品性能要求建立許多測試模塊和應(yīng)用，并開發(fā)一些工具以識別BUG （程序缺陷）。他們將開發(fā)人員做好的模塊安裝在自己的臺式機上以及實驗室環(huán)境進行全面的測試。據(jù)統(tǒng)計，這部分人員超過了1500人。除此之外，還有數(shù)以百計的微軟beta級合作伙伴。小范圍的測試之外，更大范圍的測試將徹夜不停地運行，包括產(chǎn)品在網(wǎng)絡(luò)上的使用情況、最新的補丁程序的性能改進等等。據(jù)介紹，視窗2000的測試代碼程序的長度同樣是數(shù)千萬行。而在頭一天的構(gòu)建和整夜的測試之后，第二天早9 : 30程序管理員們將準(zhǔn)時聚在一起。所謂程序管理員就是客戶代言人，他們要做的事情是寫下客戶需求的每一個細節(jié)，并把測試版的有關(guān)客戶反饋信息傳達給開發(fā)人員。程序管理員每天一早，根據(jù)前一天的進展以及客戶的需求將提出新的意見和思路，供開發(fā)人員參考。這就是項目組的典型而又完整的一天。日復(fù)一日，就是這樣經(jīng)過將近 4年的時間，我們見到了視窗2000。案例1-7:浮點運算不精確產(chǎn)生的災(zāi)難說明：課堂上講述該案例，讓學(xué)員明白軟件缺陷的可能會發(fā)生在任何地方，甚至是一些簡單的運算中。教師不必全部講述，需摘略其中重點內(nèi)容。內(nèi)容：1991年2月25日，在海