第一章緒論0.1軟件測試的背景及必要性0.2軟件測試的基礎理論

0.1.1軟件測試的背景

隨著軟件系統(tǒng)的規(guī)模越來越大，復雜性日益增加，軟件的生產成本及軟件中存在的缺陷和故障造成的各類損失也大大增加，有的甚至帶來了災難性的后果。軟件質量問題已成為軟件使用者和軟件開發(fā)者關注的焦點。由于軟件是人類高度智能化的體現(xiàn)和產品，因此軟件與生俱來就有可能存在著缺陷。而事實也恰恰如此，在軟件開發(fā)的歷史上有很多這樣的案例。0.1軟件測試的背景及必要性

1．迪斯尼的獅子王游戲軟件缺陷

1994年秋天，迪斯尼公司發(fā)布了第一個面向兒童的多媒體光盤游戲——獅子王動畫故事書(TheLionKingAnimatedStorybook)。因為前期進行了大量促銷宣傳，所以銷售額非常可觀，該款游戲成為孩子們的必買游戲。然而在孩子們玩的過程中發(fā)現(xiàn)了重大缺陷——迪斯尼公司未能對市面上投入使用的許多不同PC機型進行廣泛的測試，使得游戲軟件只能在極少數(shù)系統(tǒng)中正常運行。12月26日，圣誕節(jié)后第二天，迪斯尼公司的客戶支持電話開始響個不停。很快，電話支持技術員們的耳邊就充斥著家長的聲討聲和玩不成游戲的孩子們的哭叫聲。

2．愛國者導彈防御系統(tǒng)缺陷

愛國者導彈防御系統(tǒng)是里根總統(tǒng)提出的戰(zhàn)略防御計劃(即星球大戰(zhàn)計劃)的縮略版本，它首次應用于海灣戰(zhàn)爭對抗伊拉克飛毛腿導彈的防御戰(zhàn)中。盡管贊譽該系統(tǒng)的報道不絕于耳，但是它確實在幾次對抗中失利，其中一次是在沙特阿拉伯的載赫藍，因該系統(tǒng)未對伊拉克的飛毛腿導彈進行有效攔截，致使軍營中的28名美國士兵被炸死。分析該系統(tǒng)發(fā)現(xiàn)癥結在于一個軟件缺陷：系統(tǒng)時鐘的一個很小的計時誤差在累積14小時后，就會使跟蹤系統(tǒng)不再準確。而在這次襲擊之前，該系統(tǒng)已經(jīng)運行了100多個小時。

3．千年蟲問題

20世紀70年代早期，某位程序員正在為本公司設計開發(fā)工資系統(tǒng)。他使用的計算機存儲空間很小，不得不盡量節(jié)省每一個字節(jié)。他將自己的程序壓縮得比其他任何人的都緊湊，其中的一個方法是把4位數(shù)年份，例如1973年，縮減為2位數(shù)73。因為工資系統(tǒng)的很多數(shù)據(jù)依賴于日期來處理，所以這就能節(jié)省大量的存儲空間。他簡單地認為只有在到達2000年，也就是他的程序開始計算00或01這樣的年份時才會產生問題。他認定在25年之內程序肯定會升級或替換，而且完成眼前的任務比計劃遙不可及的未來更加重要。然而這一天還是到來了，1995年他的程序仍然在使用，而他退休了，誰也不會想到如何深入到程序中檢查2000年兼容問題，更不用說去修改了。

據(jù)估計，全球各地更換或升級類似的程序以解決潛在的2000年問題的費用已經(jīng)達數(shù)千億美元。

4．美國航天局火星登陸探測器缺陷

1999年12月3日，美國航天局的火星極地登陸者號探測器在火星表面著陸時失蹤了。故障評估委員會認定出現(xiàn)故障的原因極可能是一個數(shù)據(jù)位被意外置位。令人費解的是，在內部測試時并未發(fā)現(xiàn)這個缺陷。

從理論上看，著陸計劃是這樣的：當探測器向火星表面降落時，它將打開降落傘減緩探測器的下降速度。降落傘打開幾秒鐘后，探測器的三條腿將迅速撐開，并鎖定位置，準備著陸。當探測器離地面1800米時，它將丟棄降落傘，點燃著陸推進器，緩緩地降落到地面。美國航天局的設計者為了省錢，簡化了確定何時關閉著陸推進器的裝置，他們在探測器的腳部裝了一個廉價的觸點開關，在計算機中設置一個數(shù)據(jù)位來控制觸點開關關閉著陸推進器。故障評估委員會在測試中發(fā)現(xiàn)，在許多情況下，當探測器的三條腿迅速撐開準備著陸時，機械震動也會觸發(fā)著陸觸點開關，設置致命的錯誤數(shù)據(jù)位使著陸推進器關閉。設想探測器開始著陸時，計算機極有可能關閉著陸推進器，這樣探測器在下墜1800米之后沖向地面被撞成了碎片。但其背后的原因卻很簡單，登陸探測器經(jīng)過了多個小組的測試，其中一個小組測試飛船的腳折疊過程，另一個小組測試此后的著陸過程。前一個小組不去注意著陸數(shù)據(jù)是否置位——這不是他們負責的范圍；后一個小組總是在開始就復位計算機，清除數(shù)據(jù)位。雙方獨立工作都做得很好，但合在一起就發(fā)生了這樣災難性的后果。

5．金山詞霸的缺陷

在國內，“金山詞霸”是一個很著名的詞典軟件，應用范圍廣，對使用中文操作的用戶幫助很大，但它也存在不少缺陷。例如輸入“cube”，金山詞霸會在示例中顯示33=9的錯誤；又如，如果用鼠標取詞“dynamically”(力學，動力學)，金山詞霸會出現(xiàn)其他不同的單詞“dynamiten.炸藥”的錯誤顯示。

6．英特爾奔騰PC的浮點除法缺陷

在計算機的“計算器”程序中輸入以下算式：

(4

195

835/3

145

727)

×

3

145

727

-

4

195

835

如果答案是0，就說明計算機沒問題。如果得出其他的結果，就表示計算機使用的中央處理器存在缺陷。1994年10月30日，弗吉尼亞州Lynchburg學院的ThomasR.Nicely博士在他的一個實驗中，用奔騰PC解決一個除法問題時，發(fā)現(xiàn)了一個意想不到的結果，得出了錯誤的結論。他把發(fā)現(xiàn)的問題放到因特網(wǎng)上，隨后引發(fā)了一場風暴，成千上萬的人發(fā)現(xiàn)了同樣的問題，并且發(fā)現(xiàn)在另外一些類似的情形下也會得出錯誤的結果。萬幸的是，這種情況很少見，僅僅在進行精度要求很高的數(shù)學、科學和工程計算時才會出現(xiàn)錯誤。大多數(shù)進行稅務處理和商務應用的用戶根本不會遇到此類問題。0.1.2軟件缺陷的定義

從上述案例中可以看到軟件存在缺陷時將造成災難性危害或對用戶產生各種影響。軟件缺陷(Bug)，即計算機系統(tǒng)或者程序中存在的任何一種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷、瑕疵。缺陷會導致軟件產品在某種程度上不能滿足用戶的需要。

對于軟件缺陷的準確定義，通常包含以下五條規(guī)則：

(1)軟件未實現(xiàn)產品說明書中要求的功能。

(2)軟件出現(xiàn)了產品說明書中指明不會出現(xiàn)的錯誤。

(3)軟件實現(xiàn)了產品說明書中未提到的功能。

(4)軟件未實現(xiàn)產品說明書中雖未明確指出但應該實現(xiàn)的目標。

(5)軟件難以理解，不易使用，運行緩慢或者終端用戶認為不好。

為了更好地理解每一條規(guī)則，我們以計算器為例進行說明。

計算器的產品說明書聲稱它能夠準確無誤地進行加、減、乘、除運算。當拿到計算器后，按下“+”鍵，結果什么反應也沒有，根據(jù)第(1)條規(guī)則，這是一個缺陷。假如得到錯誤答案，根據(jù)第(1)條規(guī)則，這同樣是一個缺陷。

若產品說明書聲稱計算器永遠不會崩潰、鎖死或者停止反應，當隨意敲鍵盤時，計算器停止接收輸入，根據(jù)第(2)條規(guī)則，這是一個缺陷。

若用計算器進行測試，發(fā)現(xiàn)除了加、減、乘、除之外它還可以求平方根，而說明書中從沒提到這一功能，根據(jù)第(3)條規(guī)則，這是軟件缺陷。若在測試計算器時，發(fā)現(xiàn)電池沒電會導致計算不正確，但產品說明書未指出這個問題。根據(jù)第(4)條規(guī)則，這是個缺陷。

如果軟件測試員發(fā)現(xiàn)某些地方有問題，無論什么原因，都要認定為缺陷。例如“=”布置的位置使其極其不好按；或在明亮光下顯示屏難以看清。根據(jù)第(5)條規(guī)則，這些都是缺陷。0.1.3軟件缺陷的種類、級別及狀態(tài)

1．軟件缺陷的種類

軟件缺陷表現(xiàn)的形式有多種，不僅僅體現(xiàn)在功能的失效方面，還體現(xiàn)在其他方面。軟件缺陷的主要類型有：

(1)功能、特性沒有實現(xiàn)或部分實現(xiàn)。

(2)設計不合理，存在缺陷。

(3)實際結果和預期結果不一致。

(4)運行出錯，包括運行中斷、系統(tǒng)崩潰、界面混亂。

(5)數(shù)據(jù)結果不正確、精度不夠。

(6)用戶不能接受的其他問題，如存取時間過長、界面不美觀等。

2．軟件缺陷的級別

作為軟件測試員，可能所發(fā)現(xiàn)的大多數(shù)問題不是那么明顯、嚴重，而是難以覺察且簡單或細微的，這當中有些是真正的錯誤，也有些不是。一般來說，問題越嚴重的，其優(yōu)先級越高，越要得到及時的糾正。軟件公司對缺陷嚴重性級別的定義不盡相同，但一般可以概括為四種級別。

致命的：致命的錯誤會造成系統(tǒng)或應用程序崩潰、死機、系統(tǒng)懸掛，或造成數(shù)據(jù)丟失、主要功能完全喪失等。

嚴重的：嚴重錯誤指功能或特性沒有實現(xiàn)，主要功能部分喪失，次要功能完全喪失，或致命的錯誤聲明。一般的：不太嚴重的錯誤，這樣的軟件缺陷雖然不影響系統(tǒng)的基本使用，但沒有很好地實現(xiàn)功能，沒有達到預期效果。例如次要功能喪失，提示信息不太準確，或用戶界面差、操作時間長等。

微小的：一些小問題，對功能幾乎沒有影響，產品及屬性仍可使用，如有個別錯別字、文字排列不整齊等。

除了這四種之外，有時需要“建議”級別來處理測試人員所提出的建議或質疑，例如建議程序做適當?shù)男薷模瑏砀纳瞥绦蜻\行狀態(tài)，或對設計不合理、不明白的地方提出質疑。

3．軟件缺陷的狀態(tài)

軟件缺陷除了嚴重性級別之外，還由其狀態(tài)來表征。為便于跟蹤和管理某個產品的缺陷，可以定義不同的Bug狀態(tài)。

激活狀態(tài)：問題還沒有解決，測試人員新報Bug，或驗證后Bug仍然存在。

已修正狀態(tài)：開發(fā)人員針對所存在的缺陷修改程序，認為已解決問題，或已通過單元測試。

關閉或非激活狀態(tài)：測試人員驗證已經(jīng)修正的Bug，確認Bug不再存在后的狀態(tài)。0.1.4軟件缺陷產生的原因

軟件缺陷的產生是不可避免的。我們可以從技術問題、團隊工作和軟件本身等多個方面來分析，確定造成軟件缺陷的原因。

1．技術問題

算法錯誤。

計算和精度問題。

系統(tǒng)結構不合理，造成系統(tǒng)性能問題。

接口參數(shù)不匹配出現(xiàn)問題。

2．團隊工作

系統(tǒng)分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。

不同階段的開發(fā)人員相互理解不一致，軟件設計者對需求分析結果的理解偏差，編程人員對系統(tǒng)設計規(guī)格說明書中某些內容重視不夠，或存在誤解。

設計或編程上的一些假定或依賴性沒有得到充分的溝通。

3．軟件本身

文檔錯誤、內容不正確或拼寫錯誤。

數(shù)據(jù)考慮不周全引起強度或負載問題。

對邊界考慮不夠周全，因漏掉某幾個邊界條件而造成的錯誤。

對一些實時應用系統(tǒng)要保證精確的時間同步，否則容易引起時間上不協(xié)調、不一致性問題。

沒有考慮系統(tǒng)崩潰后在系統(tǒng)安全性、可靠性方面存在的隱患。

硬件或系統(tǒng)軟件上存在的錯誤。

軟件開發(fā)標準或過程上的錯誤。

我們知道軟件缺陷是由很多原因造成的，如果把它們按產品規(guī)格說明書、系統(tǒng)設計、編程代碼及其他原因等歸類，經(jīng)比較后發(fā)現(xiàn)，產品規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方，如圖0-1所示。圖0-1軟件缺陷產生的原因分布

0.2.1軟件測試技術的發(fā)展歷史

在軟件行業(yè)發(fā)展初期就已經(jīng)開始實施軟件測試，但這一階段還沒有系統(tǒng)意義上的軟件測試，更多的是一種類似調試的測試。這種測試是沒有計劃和方法的，測試用例的設計和選取也都是根據(jù)測試人員的經(jīng)驗隨機進行的，大多數(shù)測試是為了證明系統(tǒng)可以正常運行。0.2軟件測試的基礎理論

20世紀50年代后期到20世紀60年代，各種高級語言相繼誕生，測試的重點也逐步轉入到使用高級語言編寫的軟件系統(tǒng)中來，這類程序的復雜性遠遠超過了以前。在這一階段，由于計算機系統(tǒng)中，軟件仍然處于次要位置，軟件正確性主要依賴于編程人員的技術水平，因此這一時期軟件測試的理論和方法發(fā)展比較緩慢。

20世紀70年代以后，隨著計算機處理速度的提高和存儲器容量的快速增加，軟件在整個計算機系統(tǒng)中的地位變得越來越重要。在軟件開發(fā)技術不斷成熟和完善的同時，軟件的規(guī)模越來越大，復雜度也大大增加。因此，軟件的可靠性面臨著前所未有的危機，這給軟件測試工作帶來了更大的挑戰(zhàn)，很多測試理論和測試方法應運而生，逐漸形成了一套完整的體系，培養(yǎng)和造就出了一批批出色的測試人才。如今，在軟件產業(yè)化發(fā)展的大趨勢下，人們對軟件的質量、成本和開發(fā)進度的要求也越來越高，質量控制的含義已經(jīng)超越了傳統(tǒng)意義上的軟件測試的要求及規(guī)范。傳統(tǒng)的軟件測試大多是基于代碼運行的，并且常常是在軟件開發(fā)的后期才開始進行的。但大量研究表明，設計活動引入的錯誤占軟件開發(fā)過程中出現(xiàn)的所有錯誤數(shù)量的50%～65%。因此，越來越多的聲音呼吁，要求有一個規(guī)范的軟件開發(fā)過程。在整個軟件開發(fā)過程中，測試已經(jīng)不再只是基于程序代碼進行的活動，而是一個基于整個軟件生命周期的質量控制活動，貫穿于軟件開發(fā)的各個階段。0.2.2軟件測試的定義

軟件測試就是在軟件投入運行前，對軟件需求分析、設計規(guī)格說明和編碼實現(xiàn)的最終審查，它是保證軟件質量的關鍵步驟。通常對軟件測試的定義有兩種描述：

定義

1

軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

定義2

軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內部結構精心設計一批測試用例(即輸入數(shù)據(jù)及其預期的輸出結果)，并利用這些測試用例運行程序以及發(fā)現(xiàn)錯誤的過程，即執(zhí)行測試步驟。測試是指某個系統(tǒng)或組成部分將在特定條件下的運行，其結果將被觀察和記錄，并對系統(tǒng)或其組成部分進行評價。測試活動有兩種結果：找出缺陷和故障或顯示軟件執(zhí)行正確。測試也是一個或多個測試用例的集合。

測試用例是為特定的目的而設計的一組測試輸入、執(zhí)行條件和預期的結果。測試用例是執(zhí)行測試的最小實體。

測試步驟詳細規(guī)定了如何設置、執(zhí)行、評估特定的測試用例。對軟件測試的理解應基于以下三點：

(1)軟件測試不等于程序調試。

(2)軟件測試貫穿于軟件定義和開發(fā)的整個過程。

(3)軟件開發(fā)過程中所產生的需求規(guī)格說明、概要設計規(guī)格說明、詳細設計規(guī)格說明以及源程序都是軟件測試的對象。

軟件測試在軟件生命周期的每個時刻都存在。軟件從開發(fā)設計、運行直到結束使用的全過程中，主要包含兩個測試階段：第一個階段是單元測試階段，即在每個模塊編寫完以后所做的必要測試；第二個階段是綜合測試階段，即在完成單元測試后進行的測試，如集成測試、系統(tǒng)測試、驗收測試。0.2.3軟件測試與軟件開發(fā)

1．軟件測試與軟件開發(fā)的回溯性

軟件開發(fā)過程是一個自頂向下、逐步細化的過程。首先在軟件計劃階段定義了軟件的作用域；然后進行軟件需求分析，建立軟件的數(shù)據(jù)域、功能和性能需求、約束和一些有效性準則；接著進入軟件開發(fā)，先是進行軟件設計，然后再把設計用某種程序設計語言轉換成程序代碼。而測試過程則是以相反的順序安排的自底向上、逐步集成的過程，低一級測試為高一級測試準備條件。首先對每一個程序模塊進行單元測試，消除程序模塊內部的邏輯和功能錯誤及缺陷；再對照軟件設計進行集成測試，檢測和排除子系統(tǒng)(或系統(tǒng))結構上的錯誤；隨后再對照需求，進行確認測試；最后從系統(tǒng)全局出發(fā)，運行系統(tǒng)，看其是否滿足要求。軟件測試與軟件開發(fā)過程的關系如圖0-2所示。

圖0-2軟件測試與軟件開發(fā)過程的關系

2．軟件測試與軟件開發(fā)的并行性

在軟件的需求得到確認并通過評審后，概要設計工作和測試計劃制定工作就可以并行進行。如果系統(tǒng)模塊已經(jīng)建立，對各個模塊的詳細設計、編碼、單元測試等工作又可并行。等待每個模塊完成后，可以進行集成測試、系統(tǒng)測試。

圖0-3軟件測試與軟件開發(fā)的并行性

3．軟件測試與軟件開發(fā)的V模型

軟件測試不僅僅是執(zhí)行測試，而是一個包含很多復雜活動的過程，并且這些過程應該貫穿于整個軟件開發(fā)過程。在軟件開發(fā)過程中，應該什么時候進行測試、如何更好地把軟件開發(fā)和測試活動集成到一起，是軟件測試工作人員必須考慮的問題。因為只有這樣，才能提高軟件測試工作的效率，提高軟件產品的質量，最大限度地降低軟件開發(fā)與測試的成本，減少重復勞動。如圖0-4所示為軟件測試與軟件開發(fā)的完整流程模型。

圖0-4軟件測試與開發(fā)的完整流程模型0.2.4軟件測試的目的

基于不同的立場，存在著兩種完全不同的測試目的：

(1)從用戶的角度出發(fā)，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。

(2)從軟件開發(fā)者的角度出發(fā)，則希望軟件測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現(xiàn)了用戶的要求，確立人們對軟件質量的信心。

綜上所述，軟件測試的目的包括以下幾點：

(1)軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。

(2)測試是為了證明程序有錯，而不是證明程序無錯。即測試能證明程序的正確性，僅限于有限種情況。

(3)檢查系統(tǒng)是否滿足需求，這是測試期望的目標。

(4)一個好的測試用例在于它發(fā)現(xiàn)了還未曾發(fā)現(xiàn)的錯誤。

(5)一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

上述幾點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這些觀點可能會產生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目的，查找不出錯誤的測試就是沒有價值的，其實事實并非如此。首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，通過分析也能幫助人們設計出有針對性的檢測方法，改善測試的有效性。

其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的。完整的測試是評定測試質量的一種方法，詳細而嚴謹?shù)目煽啃栽鲩L模型可以證明這一點。例如，有人發(fā)現(xiàn)一個經(jīng)過測試能正常運行N個小時的系統(tǒng)有繼續(xù)正常運行N個小時的可能。0.2.5軟件測試的原則

軟件測試的目標是希望能夠以最少的時間和人力找出軟件中潛藏的各種錯誤和缺陷。如果成功地實施了測試，就能夠發(fā)現(xiàn)軟件中的錯誤。

根據(jù)這樣的測試目的，軟件測試的原則應該有以下幾點：

(1)應當把“盡早地和不斷地進行軟件測試”作為軟件開發(fā)者的座右銘。原始問題的復雜性、軟件的復雜性和抽象性、軟件開發(fā)各個階段工作的多樣性以及開發(fā)過程中各種層次的人員之間工作的配合關系等因素，導致開發(fā)的每個環(huán)節(jié)都可能產生錯誤。所以不應把軟件測試僅僅看做軟件開發(fā)的一個獨立階段，而應當把它貫穿到軟件開發(fā)的各個階段中，堅持在軟件開發(fā)的各個階段進行技術評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預防錯誤，杜絕某些隱患，提高軟件質量。

(2)測試用例應由測試輸入數(shù)據(jù)和與之對應的預期輸出結果兩部分組成。在進行測試之前應當根據(jù)測試的要求設計測試用例(TestCase)。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數(shù)據(jù)，而且需要針對這些輸入數(shù)據(jù)的預期輸出結果。如果對測試輸入數(shù)據(jù)沒有給出預期的程序輸出結果，那么就缺少了檢驗實際測試結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。

(3)程序員應避免檢查自己的程序。測試工作需要嚴謹?shù)淖黠L、客觀的態(tài)度和冷靜的情緒。人們常常由于各種原因而產生一種不愿否定自己工作的心理，認為揭露自己程序中的問題不是一件愉快的事。這一心理狀態(tài)就成為測試自己編寫的程序的障礙。另外，由于程序員對軟件規(guī)格說明的錯誤理解而引入的錯誤很難發(fā)現(xiàn)，如果由別人來測試程序員編寫的程序，可能會更客觀、更有效，并更容易取得成功。要注意的是，這點不能與程序的調試(Debug)相混淆，調試由程序員自己來做可能更有效。

(4)在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確性的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問題異變的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶在鍵盤上按錯了鍵或輸入了非法的命令。如果軟件對這種情況不能做出適當?shù)姆磻?，給出相應的信息，那么就容易產生故障，輕則給出錯誤的結果，重則導致軟件失效。因此，軟件系統(tǒng)處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試更能發(fā)現(xiàn)錯誤。

(5)充分注意測試中的群集現(xiàn)象。測試時不要以為找到了幾個錯誤就不需要繼續(xù)測試了。經(jīng)驗表明，測試后程序中殘存的錯誤數(shù)目與該程序中已發(fā)現(xiàn)的錯誤數(shù)目或檢錯率成正比。根據(jù)這個規(guī)律，應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。

在所測程序段中，若發(fā)現(xiàn)錯誤數(shù)目較多，則殘存錯誤數(shù)目也比較多，這種錯誤群集性現(xiàn)象已被許多程序的測試實踐所證實。例如，美國IBM公司的OS/370操作系統(tǒng)中，47%的錯誤僅與該系統(tǒng)4%的程序模塊有關。這種現(xiàn)象對測試很有用，如果發(fā)現(xiàn)某一程序模塊似乎比其他程序模塊有更多的錯誤傾向，則應當花費較多的時間和代價測試這個程序模塊。

(6)嚴格執(zhí)行測試計劃，排除測試的隨意性。測試計劃應包括：所測軟件的功能、輸入和輸出、測試內容、各項測試的進度安排、資源要求、測試資料、測試工具、測試用例的選擇、測試的控制方式和過程、系統(tǒng)組裝方式、跟蹤規(guī)程、總體流程圖調試規(guī)程、回歸測試的規(guī)定以及評價標準等。對于測試計劃，要明確規(guī)定，不要隨意更改。

(7)應當對每一個測試結果做全面檢查。這是一條最明顯的原則，但常常被忽視。有些錯誤的征兆在輸出實測結果時已經(jīng)明顯地出現(xiàn)了，但是如果不仔細、全面地檢查測試結果，就會使這些錯誤被忽略。所以必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住征候，暴露錯誤。

(8)妥善保存測試計劃、測試用例、出錯統(tǒng)計和最終分析報告，為維護提供方便。0.2.6軟件測試的分類

從不同的角度，可以把軟件測試技術分成不同種類。

1．從是否需要執(zhí)行被測軟件的角度分類

從是否需要執(zhí)行被測軟件的角度，可將軟件測試分為靜態(tài)測試(StaticTesting)和動態(tài)測試(DynamicTesting)。

顧名思義，靜態(tài)測試就是通過對被測程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛藏的錯誤。它一般用人工方式脫機完成，故亦稱為人工測試或代碼評審(CodeReview)；也可借助于靜態(tài)分析器在機器上以自動方式進行檢查，但不要求程序本身在機器上運行。按照評審的不同組織形式，代碼評審又可分為代碼會審、走查以及辦公桌檢查、同行評分四種。對某個具體的程序，通常只使用一種評審方式。

動態(tài)測試是通常意義上的測試，即使用和運行被測軟件。動態(tài)測試的對象必須是能夠由計算機真正運行的被測試的程序。

2．從軟件測試用例設計方法的角度分類

從軟