軟件測試基礎教程第一章

軟件測試的基礎理論

第一章

軟件測試的基礎理論

1.1軟件測試的含義1.2軟件測試的目的與原則1.3軟件測試的生命周期1.4軟件測試與軟件開發的關系習題本章概要第一章

軟件測試的基礎理論

軟件測試的發展歷史及其現狀軟件測試的定義測試目的測試原則測試的生命周期軟件測試與軟件開發的關系1.1軟件測試的含義第一章

軟件測試的基礎理論

1.1.1軟件缺陷1.1.2軟件測試技術的發展歷史及現狀1.1軟件測試的含義第一章

軟件測試的基礎理論

軟件的質量就是軟件的生命，為了保證軟件的質量，人們在長期的開發過程中積累了許多經驗并形成了許多行之有效的方法。但是借助這些方法，我們只能盡量減少軟件中的錯誤和不足，卻不能完全避免所有的錯誤。如果把所開發出來的軟件看作一個企業生產的產品，那么軟件測試就相當于該企業的質量檢測部分。簡單地說，我們在編寫完一段代碼之后，檢查其是否如我們所預期的那樣運行，這個活動就可以看作是一種軟件測試工作。新的測試理論、測試方法、測試技術手段在不斷涌出，軟件測試機構和組織也在迅速產生和發展，由此軟件測試技術職業也同步完善和健全起來。1.1.1軟件缺陷第一章

軟件測試的基礎理論

1．軟件缺陷案例人們常常不把軟件當回事，沒有真正意識到它已經深入滲透到我們的日常生活中,軟件在電子信息領域里無處不在。現在有許多人如果一天不上網查看電子郵件，簡直就沒法過下去。我們已經離不開24小時包裹投遞服務、長途電話服務和最先進的醫療服務了。然而軟件是由人編寫開發的，是一種邏輯思維的產品，盡管現在軟件開發者采取了一系列有效措施，不斷地提高軟件開發質量，但仍然無法完全避免軟件（產品）會存在各種各樣的缺陷。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

下面以實例來說明。（1）迪斯尼的獅子王游戲軟件缺陷。1994年秋天，迪斯尼公司發布了第一個面向兒童的多媒體光盤游戲——獅子王動畫故事書（TheLionKingAnimatedStorybook）。盡管已經有許多其他公司在兒童游戲市場上運作多年，但是這次是迪斯尼公司首次進軍這個市場，所以進行了大量促銷宣傳。結果，銷售額非常可觀，該游戲成為孩子們那年節假日的“必買游戲”。然而后來卻飛來橫禍。12月26日，圣誕節的后一天，迪斯尼公司的客戶支持電話開始響個不停。很快，電話支持技術員們就淹沒在來自于憤怒的家長并伴隨著玩不成游戲的孩子們哭叫的電話之中。報紙和電視新聞進行了大量的報道。后來證實，迪斯尼公司未能對市面上投入使用的許多不同類型的PC機型進行廣泛的測試。軟件在極少數系統中工作正常—-例如在迪斯尼程序員用來開發游戲的系統中——但在大多數公眾使用的系統中卻不能運行。1.1.1軟件缺陷第一章

軟件測試的基礎理論

（2）愛國者導彈防御系統缺陷愛國者導彈防御系統是里根總統提出的戰略防御計劃（即星球大戰計劃）的縮略版本，它首次應用在海灣戰爭中對抗伊拉克飛毛腿導彈的防御戰中。盡管對系統贊譽的報道不絕于耳，但是它確實在對抗幾枚導彈中失利，包括一次在沙特阿拉伯的多哈擊斃了28名美國士兵。分析發現癥結在于一個軟件缺陷，系統時鐘的一個很小的計時錯誤積累起來到14小時后，跟蹤系統不再準確。在多哈的這次襲擊中，系統已經運行了100多個小時。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

（3）千年蟲問題20世紀70年代早期的某個時間，某位程序員正在為本公司設計開發工資系統。他使用的計算機存儲空間很小，迫使他盡量節省每一個字節。他將自己的程序壓縮得比其他任何人都緊湊。使用的其中一個方法是把4位數年份，例如1973年，縮減為2位數，73。因為工資系統相當信賴于日期的處理，所以需要節省大量的存儲空間。他簡單的認為只有在到達2000年，那時他的程序開始計算00或01這樣的年份時問題才會產生。雖然他知道會出這樣的問題，但是他認定在25年之內程序肯定會升級或替換，而且眼前的任務比現在計劃遙不可及的未來更加重要。然而這一天畢竟到來了。1995年他的程序仍然在使用，而他退休了，誰也不會想到如何深入到程序中檢查2000年兼容問題，更不用說去修改了。估計全球各地更換或升級類似的前者程序以解決潛在的2000問題的費用已經達數千億美元。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

（4）美國航天局火星登陸探測器缺陷1999年12月3日，美國航天局的火星極地登陸者號探測器試圖在火星表面著陸時失蹤。一個故障評估委員會調查了故障，認定出現故障的原因極可能是一個數據位被意外置位。最令人警醒的問題是為什么沒有在內部測試時發現呢。從理論上看，著陸的計劃是這樣的：當探測器向火星表面降落時，它將打開降落傘減緩探測器的下降速度。降落傘打開幾秒鐘后，探測器的三條腿將迅速撐開，并鎖定位置，準備著陸。當探測器離地面1800米時，它將丟棄降落傘，點燃著陸推進器，緩緩地降落到地面。美國航天局為了省錢，簡化了確定何時關閉著陸推進器的裝置。為了替代其他太空船上使用的貴重雷達，他們在探測器的腳部裝了一個廉價的觸點開關，在計算機中設置一個數據位來控制觸點開關關閉燃料。很簡單，探測器的發動機需要一直點火工作，直到腳“著地”為止。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

遺憾的是，故障評估委員會在測試中發現，許多情況下，當探測器的腳迅速撐開準備著陸時，機械震動也會觸發著陸觸點開關，設置致命的錯誤數據位。設想探測器開始著陸時，計算機極有可能關閉著陸推進器，這樣火星極地登陸者號探測器飛船下墜1800米之后沖向地面，撞成碎片。結果是災難性的，但背后的原因卻很簡單。登陸探測器經過了多個小組測試。其中一個小組測試飛船的腳折疊過程，另一個小組測試此后的著陸過程。前一個小組不去注意著地數據是否置位——這不是他們負責的范圍；后一個小組總是在開始復位之前復位計算機，清除數據位。雙方獨立工作都做得很好，但合在一起就不是這樣了

1.1.1軟件缺陷第一章

軟件測試的基礎理論

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

1.1.1軟件缺陷第一章

軟件測試的基礎理論

(6)英特爾奔騰浮點除法缺陷在計算機的“計算器”程序中輸入以下算式：（4195835/3145727）*3145727-4195835如果答案是0，就說明計算機沒問題。如果得出別的結果，就表示計算機使用的是帶有浮點除法軟件缺陷的老式英特爾奔騰處理器——這個軟件缺陷被燒錄在一個計算機芯片中，并在制作過程中反復生產。1994年10月30日，弗吉利亞州Lynchburg學院的ThomasR.Nicely博士在他的一個實驗中，用奔騰PC機解決一個除法問題時，記錄了一個想不到的結果，得出了錯誤的結論。他把發現的問題放到因特網上，隨后引發了一場風暴，成千上萬的人發現了同樣的問題，并且發現在另外一些情形下也會得出錯誤的結果。萬幸的是，這種情況很少見，僅僅在進行精度要求很高的數學、科學和工程計算中才會導致錯誤。大多數用來進行稅務處理和商務應用的用戶根本不會遇到此類問題。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

這件事情引人關注的并不是這個軟件缺陷，而是英特爾公司解決問題的方式：他們的軟件測試工程師在芯片發布之前進行內部測試時已經發現了這個問題。英特爾的管理層認為這沒有嚴重到要保證修正，甚至公開的程度。當軟件缺陷被發現時，英特爾通過新聞發布和公開聲明試圖弱化這個問題的已知嚴重性。受到壓力時，英特爾承諾更換有問題的芯片，但要求用戶必須證明自己受到缺陷的影響。

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

軟件測試的基礎理論

對于軟件缺陷的準確定義，通常有以下5條描述：（1）軟件未實現產品說明書要求的功能。（2）軟件出現了產品說明書指明不會出現的錯誤。（3）軟件超出實現了產品說明書提到的功能。（4）軟件實現了產品說明書雖未明確指出但應該實現的目標。（5）軟件難以理解，不易使用，運行緩慢或者終端用戶認為不好。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

為了更好地理解每一條規則，我們以計算器為例進行說明。計算器的產品說明書聲稱它能夠準確無誤地進行加、減、乘、除運算。當你拿到計算器后，按下（＋）鍵，結果什么反應也沒有，根據第１條規則，這是一個缺陷。假如得到錯誤答案，根據第１條規則，這同樣是一個缺陷。若產品說明書聲稱計算器永遠不會崩潰、鎖死或者停止反應。當你任意敲鍵盤，計算器停止接受輸入，根據第２條規則，這是一個缺陷。若用計算器進行測試，發現除了加、減、乘、除之外它還可以求平方根，說明書中從沒提到這一功能，根據第３條規則，這是軟件缺陷。軟件實現了產品說明書未提到的功能若在測試計算器時，會發現電池沒電會導致計算不正確，但產品說明書未指出這個問題。根據第４條規則，這是個缺陷。第５條規則是全面的。如果軟件測試員發現某些地方不對勁，無論什么原因，都要認定為缺陷。如“＝”鍵布置的位置使其極其不好按；或在明亮光下顯示屏難以看清。根據第５條規則，這些都是缺陷。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

3．軟件缺陷的種類軟件缺陷表現的形式有多種，不僅僅體現在功能的失效方面，還體現在其他方面。軟件缺陷的主要類型有：功能、特性沒有實現或部分實現。設計不合理，存在缺陷。實際結果和預期結果不一致。運行出錯，包括運行中斷、系統崩潰、界面混亂。數據結果不正確、精度不夠。用戶不能接受的其他問題，如存取時間過長、界面不美觀。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

4．軟件缺陷的級別及軟件缺陷的狀態（1）軟件缺陷的級別作為軟件測試員，可能所發現的大多數問題不是那么明顯、嚴重，而是難以覺察的簡單而細微的錯誤，有些是真正的錯誤，也有些不是。一般來說，問題越嚴重的，其優先級越高，越要得到及時的糾正。軟件公司對缺陷嚴重性級別的定義不盡相同，但一般可以概括為4種級別：致命的：致命的錯誤，造成系統或應用程序崩潰、死機、系統懸掛，或造成數據丟失、主要功能完全喪失等。嚴重的：嚴重錯誤，指功能或特性沒有實現，主要功能部分喪失，次要功能完全喪失，或致命的錯誤聲明。一般的：不太嚴重的錯誤，這樣的軟件缺陷雖然不影響系統的基本使用，但沒有很好地實現功能，沒有達到預期效果。如次要功能喪失，提示信息不太準確，或用戶界面差，操作時間長等。微小的：一些小問題，對功能幾乎沒有影響，產品及屬性仍可使用，如有個別錯別字、文字排列不整齊等。除了這4種之外，有時需要“建議”級別來處理測試人員所提出的建議或質疑，如建議程序做適當的修改，來改善程序運行狀態，或對設計不合理、不明白的地方提出質疑。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

（2）．軟件缺陷的狀態軟件缺陷除了嚴重性之外，還存在反映軟件缺陷處于一種什么樣的狀態，便于跟蹤和管理某個產品的缺陷，可以定義不同的bug狀態。激活狀態：問題還沒有解決，測試人員新報的bug，或驗證后bug仍然存在。已修正狀態：開發人員針對所存在的缺陷，修改程序，認為已解決問題，或通過單元測試。關閉或非激活狀態：測試人員驗證已經修正的bug后，確認bug不存在以后的狀態。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

5．軟件缺陷的原因軟件缺陷的產生，首先是不可避免的。其次我們可以從軟件本身，團隊工作和技術問題等多個方面分析，比較容易確定造成軟件缺陷的原因，歸納如下。技術問題算法錯誤。語法錯誤。計算和精度問題。系統結構不合理，造成系統性能問題。接口參數不匹配出現問題。

團隊工作系統分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。不同階段的開發人員相互理解不一致，軟件設計對需求分析結果的理解偏差，編程人員對系統設計規格說明書中某些內容重視不夠，或存在著誤解。設計或編程上的一些假定或依賴性，沒有得到充分的溝通。軟件本身文檔錯誤、內容不正確或拼寫錯誤。數據考慮不周全引起強度或負載問題。對邊界考慮不夠周全，漏掉某幾個邊界條件造成的錯誤。對一些實時應用系統，保證精確的時間同步，否則容易引起時間上不協調、不一致性帶來的問題。沒有考慮系統崩潰后在系統安全性、可靠性的隱患。硬件或系統軟件上存在的錯誤。軟件開發標準或過程上的錯誤。

1.1.1軟件缺陷第一章

軟件測試的基礎理論

1.1.1軟件缺陷第一章

軟件測試的基礎理論

6．軟件缺陷的組成我們知道軟件缺陷是由很多原因造成的，如果把它們按需求分析結果——規格說明書，系統設計結果，編程的代碼等歸類起來，比較后發現，結果規格說明書是軟件缺陷出現最多的地方，見圖1-1。圖1-1軟件缺陷構成示意圖1.1.2軟件測試技術的發展歷史及現狀

第一章

軟件測試的基礎理論

1．軟件測試技術的發展歷史隨著計算機的誕生——在軟件行業發展初期就已經開始實施軟件測試，但這一階段還沒有系統意義上的軟件測試，更多的是一種類似調試的測試。測試是沒有計劃和方法的，測試用例的設計和選取也都是根據測試人員的經驗隨機進行的，大多數測試的目的是為了證明系統可以正常運行。20世紀50年代后期到20世紀60年代，各種高級語言相繼誕生，測試的重點也逐步轉入到使用高級語言編寫的軟件系統中來，但程序的復雜性遠遠超過了以前。盡管如此，由于受到硬件的制約，在計算機系統中，軟件仍然處于次要位置。軟件正確性的把握仍然主要依賴于編程人員的技術水平。因此，這一時期軟件測試的理論和方法發展比較緩慢。

1.1.2軟件測試技術的發展歷史及現狀

第一章

軟件測試的基礎理論

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

1.1.2軟件測試技術的發展歷史及現狀

第一章

軟件測試的基礎理論

2．軟件測試的現狀在我國，軟件測試可能算不上一個真正的產業，軟件開發企業對軟件測試認識淡薄，軟件測試人員與軟件開發人員往往比例失調，而在發達國家和地區軟件測試已經成了一個產業。我們在軟件測試實現方面并不比國外差，國際上優秀的測試工具，我們基本都有，這些工具所體現的思想我們也有深刻的理解，很多大型系統在國內都得到了很好的測試。1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

1．軟件測試的定義軟件測試就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵步驟。通常對軟件測試的定義有如下描述：軟件測試是為了發現錯誤而執行程序的過程。或者說，軟件測試是根據軟件開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，并利用這些測試用例去運行程序，以發現程序錯誤的過程。1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

2．軟件測試的目的基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。從軟件開發者的角度出發，則希望成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。綜上所述，軟件測試的目的包括以下三點：(1)測試是程序的執行過程，目的在于發現錯誤，不能證明程序的正確性，僅限于處理有限種的情況。(2)檢查系統是否滿足需求，這也是測試的期望目標。(3)一個好的測試用例在于發現還未曾發現的錯誤；成功的測試是發現了錯誤的測試。

1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

3．軟件測試的原則軟件測試的目標是想以最少的時間和人力找出軟件中潛在的各種錯誤和缺陷。如果成功地實施了測試，就能夠發現軟件中的錯誤。根據這樣的測試目的，軟件測試的原則應該是：應當把盡早地和不斷地進行軟件測試作為軟件開發者的座右銘。堅持在軟件開發的各個階段的技術評審，這樣才能在開發過程中盡早發現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質量。測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。如果對測試輸入數據沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。程序員應避免檢查自己的程序。如果由別人來測試程序員編寫的程序，可能會更客觀，更有效，并更容易取得成功。

1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的，臨界的，可能引起問題變異的輸入條件。因此，軟件系統處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸入條件測試程序時，往往比用合理的輸入條件進行測試能發現更多的錯誤。充分注意測試中的群集現象。測試時不要以為找到了幾個錯誤問題就已解決，不需繼續測試了。應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。嚴格執行測試計劃，排除測試的隨意性。對于測試計劃，要明確規定，不要隨意解釋。應當對每一個測試結果做全面檢查。這是一條最明顯的原則，但常常被忽視。必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住關鍵，暴露錯誤。妥善保存測試計劃，測試用例，出錯統計和最終分析報告，為維護提供方便。

1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

4．軟件測試的分類從不同的角度，可以把軟件測試技術分成不同種類。（1）從是否需要執行被測軟件的角度分類從是否需要執行被測軟件的角度，可分為靜態測試（StaticTesting）和動態測試(DynamicTesting)。顧名思義，靜態測試就是通過對被測程序的靜態審查，發現代碼中潛在的錯誤。它一般用人工方式脫機完成，故亦稱人工測試或代碼評審（CodeReview）;也可借助于靜態分析器在機器上以自動方式進行檢查，但不要求程序本身在機器上運行。按照評審的不同組織形式，代碼評審又可分為代碼會審，走查以及辦公桌檢查，同行評分4種。對某個具體的程序，通常只使用一種評審方式。動態測試的對象必須是能夠由計算機真正運行的被測試的程序。它分為黑盒測試和白盒測試，也是我們下面將要介紹的內容。

1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

（2）從軟件測試用例設計方法的角度分類從軟件測試用例設計方法的角度，可分為黑盒測試（Black-BoxTesting）和白盒測試（White-BoxTesting）。黑盒測試是一種從用戶觀點出發的測試，又稱為功能測試，數據驅動測試和基于規格說明的測試。若測試用例的設計是基于產品的功能，目的是檢查程序各個功能是否實現，并檢查其中的功能錯誤，則這種測試方法稱為黑盒。白盒測試基于產品的內部結構來進行測試，檢查內部操作是否按規定執行，軟件各個部分功能是否得到充分利用。白盒測試又稱為結構測試，邏輯驅動測試或基于程序的測試。即根據被測程序的內部結構設計測試用例，測試者需事先了解被測試程序的結構。

1.2軟件測試的目的與原則第一章

軟件測試的基礎理論

（3）從軟件測試的策略和過程的角度分類。按照軟件測試的策略和過程分類，軟件測試可分為單元測試（UnitTesting），集成測試（IntegrationTesting）,確認測試（ValidationTesting）,系統測試（SystemTesting）和驗收測試（VerificationTesting）.單元測試是針對每個單元的測試，是軟件測試的最小單位。它確保每個模塊能正常工作。單元測試多數使用白盒測試，用以發現內部錯誤。集成測試是對已測試過的模塊進行組裝，進行集成測試的目的主要在于檢驗與軟件設計相關的程序結構問題。集成測試一般通過黑盒測試方法來完成。確認測試是檢驗所開發的軟件能否滿足所有功能和性能需求的最后手段，通常采用黑盒測試方法。系統測試的主要任務是檢測被測軟件與系統的其他部分的協調性。驗收測試是軟件產品質量的最后一關。這一環節，測試主要從用戶的角度著手，其參與者主要是用戶和少量的程序開發人員。

1.3軟件測試的生命周期第一章

軟件測試的基礎理論

圖1-2給出了軟件測試生命周期的模型．把測試的生命周期分為幾個階段．前３個階段是引入程序錯誤階段，也就是開發過程中的需求規格說明、設計、編碼階段，此時極易引入錯誤或者導致開發過程中其他階段產生錯誤。然后是通過測試發現錯誤的階段，這需要通過使用一些適當的測試技術和方法來共同完成。后3個階段是清除程序錯誤的階段。其主要任務是進行缺陷分類、缺陷隔離和解決缺陷。其中在修復舊缺陷的時候很可能引進新的錯誤，導致原來能夠正確執行的程序出現新的缺陷。圖1-2軟件測試生命周期1.3軟件測試的生命周期第一章

軟件測試的基礎理論

1.3軟件測試的生命周期第一章

軟件測試的基礎理論

在軟件測試生命周期的每個階段都要完成一些確定的任務，在執行每個階段的任務時，可以采用行之有效的結構分析設計技術和適當的輔助工具；在結束每個階段的任務時都進行嚴格的技術審查和管理復審。最后提交最終軟件配置的一個或幾個成分（文檔或程序）。1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

1．測試與軟件開發各階段的關系軟件開發過程是一個自頂向下，逐步細化的過程，首先在軟件計劃階段定義了軟件的作用域，然后進行軟件需求分析，建立軟件的數據域、功能和性能需求、約束和一些有效性準則。接著進入軟件開發，首先是軟件設計，然后再把設計用某種程序設計語言轉換成程序代碼。而測試過程則是依相反的順序安排的自底向上，逐步集成的過程，低一級測試為上一級測試準備條件。此外還有兩者平行地進行測試。如圖1-3，首先對每一個程序模塊進行單元測試，消除程序模塊內部在邏輯上和功能上的錯誤和缺陷。再對照軟件設計進行集成測試，檢測和排除子系統（或系統）結構上的錯誤。隨后再對照需求，進行確認測試。最后從系統全體出發，運行系統，看是否滿足要求。

1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

圖1-3軟件測試與軟件開發過程的關系1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

2．測試與開發的并行性在軟件的需求得到確認并通過評審后，概要設計工作和測試計劃制定設計工作就要并行進行。如果系統模塊已經建立，對各個模塊的詳細設計、編碼、單元測試等工作又可并行。待每個模塊完成后，可以進行集成測試、系統測試。并行流程如圖1-4所示。1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

圖1-4軟件測試與軟件開發的并行性1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

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

1.4軟件測試與軟件開發的關系第一章

軟件測試的基礎理論

圖1-5軟件測試與開發的完整流程習題第一章

軟件測試的基礎理論

1.名詞解釋：軟件缺陷、軟件測試、靜態測試、動態測試、黑盒測試、白盒測試、單元測試、集成測試。2．簡述缺陷產生的原因。3．簡述軟件測試發展歷史及軟件測試的現狀。4．簡述軟件測試的目的。5．簡述軟件測試的原則。6．簡述軟件測試與軟件開發的關系。7．談談你對軟件測試重要性的理解。

第二章軟件測試方法第二章軟件測試方法2.1軟件測試方法概述2.2靜態測試與動態測試2.3黑盒測試2.4白盒測試習題本章概要第二章軟件測試方法軟件測試方法概述靜態測試和動態測試黑盒測試和白盒測試2.1軟件測試方法概述第二章軟件測試方法軟件測試的方法多種多樣，可以從不同角度加以分類：從是否需要執行被測軟件的角度，分為靜態測試和動態測試；從是針對系統的外部功能還是針對系統的內部結構的角度，分為黑盒測試和白盒測試；從軟件測試的策略和過程的角度，分為單元測試、集成測試、確認測試、系統測試和驗收測試等。2.1軟件測試方法概述第二章軟件測試方法1．從是否需要執行被測軟件的角度分類從是否需要執行被測軟件的角度，軟件測試可分為靜態測試（StaticTesting）和動態測試(DynamicTesting)。顧名思義，靜態測試就是通過對被測程序的靜態審查，發現代碼中潛在的錯誤。它一般用人工方式脫機完成，故亦稱人工測試或代碼評審（CodeReview）;也可借助于靜態分析器在機器上以自動方式進行檢查，但不要求程序本身在機器上運行。按照評審的不同組織形式，代碼評審又可分為代碼會審，走查以及辦公桌檢查，同行評分4種。對某個具體的程序，通常只使用一種評審方式。動態測試是通常意義上的測試，即使用和運行被測軟件。動態測試的對象必須是能夠由計算機真正運行的被測試的程序，它包含黑盒測試和白盒測試，在2.3節將會具體介紹這兩種方法。

2.1軟件測試方法概述第二章軟件測試方法2．從軟件測試用例設計方法的角度分類從軟件測試用例設計方法的角度，可分為黑盒測試（Black-BoxTesting）和白盒測試（White-BoxTesting）。黑盒測試是一種從用戶角度出發的測試，又稱為功能測試。數據驅動測試和基于規格說明的測試。使用這種方法進行測試時，把被測試程序當作一個黑盒，忽略程序內部的結構的特性，測試者在只知道該程序輸入和輸出之間的關系或程序功能的情況下，依靠能夠反映這一關系和程序功能需求規格的說明書，來確定測試用例和推斷測試結果的正確性。簡單地說，若測試用例的設計是基于產品的功能，目的是檢查程序各個功能是否實現，并檢查其中的功能錯誤，則這種測試方法稱為黑盒。白盒測試基于產品的內部結構來進行測試，檢查內部操作是否按規定執行，軟件各個部分功能是否得到充分利用。白盒測試又稱為結構測試，邏輯驅動測試或基于程序的測試。即根據被測程序的內部結構設計測試用例，測試者需要預先了解被測試程序的結構。

2.1軟件測試方法概述第二章軟件測試方法3．從軟件測試的策略和過程的角度分類。按照軟件測試的策略和過程分類，軟件測試可分為單元測試（UnitTesting），集成測試（IntegrationTesting），確認測試（ValidationTesting），系統測試（SystemTesting）和驗收測試（VerificationTesting）。單元測試是針對每個單元的測試，是軟件測試的最小單位。它確保每個模塊能正常工作。單元測試主要采用白盒測試方法，用以發現內部錯誤。集成測試是對已測試過的模塊進行組裝，進行集成測試的目的主要在于檢驗與軟件設計相關的程序結構問題。在集成測試過程中，測試人員采用黑盒測試和白盒測試兩種方法，來驗證多個單元模塊集成到一起后是否能夠協調工作。確認測試是檢驗所開發的軟件能否滿足所有功能和性能需求的最后手段，通常采用黑盒測試方法。系統測試的主要任務是檢測被測軟件與系統的其他部分的協調性，通常采用黑盒測試方法。驗收測試是軟件產品質量的最后一關。這一環節，測試主要從用戶的角度著手，其參與者主要是用戶和少量的程序開發人員，通常采用黑盒測試方法。

2.2靜態測試與動態測試第二章軟件測試方法根據程序是否運行可以把軟件測試方法分為靜態測試（StaticTesting）和動態測試（DynamicTesting）兩大類。圖2-1是靜態測試與動態測試的比喻圖。圖2-1靜態測試與動態測試的比喻圖2.2.1靜態測試第二章軟件測試方法靜態方法的主要特征是在用計算機測試源程序時，計算機并不真正運行被測試的程序，只對被測程序進行特性分析。因此，靜態方法常稱為“分析”，靜態分析是對被測程序進行特性分析的一些方法的總稱。所謂靜態分析，就是不需要執行所測試的程序，而只是通過掃描程序正文，對程序的數據流和控制流等信息進行分析，找出系統的缺陷，得出測試報告。

靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。2.2.1靜態測試第二章軟件測試方法通常在靜態測試階段進行以下一些測試活動：檢查算法的邏輯正確性，確定算法是否實現了所要求的功能；檢查模塊接口的正確性，確定形參的個數、數據類型、順序是否正確，確定返回值類型及返回值的正確性；檢查輸入參數是否有合法性檢查。如果沒有合法性檢查，則應確定該參數是否不需要合法性檢查，否則應加上參數的合法性檢查；檢查調用其他模塊的接口是否正確，檢查實參類型、實參個數是否正確，返回值是否正確。若被調用模塊出現異常或錯誤，程序是否有適當的出錯處理代碼；檢查是否設置了適當的出錯處理，以便在程序出錯時，能對出錯部分進行重做安排，保證其邏輯的正確性；檢查表達式、語句是否正確，是否含有二義性。例如，下列表達式或運算符的優先級：<=、=、>=、&&、||、++、--等；檢查常量或全局變量使用是否正確；檢查標識符的使用是否規范、一致，變量命名是否能夠望名知義、簡潔、規范和易記；檢查程序風格的一致性、規范性，代碼是否符合行業規范，是否所有模塊的代碼風格一致、規范；檢查代碼是否可以優化，算法效率是否最高；檢查代碼注釋是否完整，是否正確反映了代碼的功能，并查找錯誤的注釋。2.2.1靜態測試第二章軟件測試方法2.2.1靜態測試第二章軟件測試方法靜態分析的差錯分析功能是編譯程序所不能替代的。編譯系統雖然能發現某些程序錯誤，但這些錯誤遠非軟件中存在的大部分錯誤。目前，已經開發了一些靜態分析系統作為軟件靜態測試的工具，靜態分析已被當作一種自動化的代碼校驗方法。2.2.2動態測試

第二章軟件測試方法

動態方法是通過源程序運行時所體現出來的特征，來進行執行跟蹤、時間分析以及測試覆蓋等方面的測試。動態測試是真正運行被測程序，在執行過程中，通過輸入有效的測試用例，對其輸入與輸出的對應關系進行分析，以達到檢測的目的。動態測試方法的基本步驟：選取定義域的有效值，或選取定義域外的無效值；對已選取值決定預期的結果；用選取值執行程序；執行結果與預期的結果相比，不吻合則說明程序有錯。

不同的測試方法各自的目標和側重點不一樣，在實際工作中要將靜態測試和動態測試結合起來，以達到更加完美的效果。在動態測試中，又可有基于程序結構的白盒測試（或稱為覆蓋測試）和基于功能的黑盒測試。

2.3黑盒測試方法

第二章軟件測試方法黑盒測試（Black-boxTesting）又稱為功能測試、數據驅動測試和基于規格說明的測試。是一種從用戶觀點出發的測試，主要以軟件規格說明書為依據，對程序功能和程序接口進行的測試。黑盒測試的基本觀點是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數過程，被測程序被認為是一個打不開的黑盒子，黑盒中的內容（實現過程）完全不知道，只明確要做到什么。黑盒測試作為軟件功能的測試手段，是重要的測試方法。它主要根據規格說明設計測試用例，并不涉及程序內部結構和內部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。2.3.1黑盒測試方法概述

第二章軟件測試方法黑盒測試是以用戶的觀點，從輸入數據與輸出數據的對應關系出發進行測試的，它不涉及到程序的內部結構。很明顯，如果外部特性本身有問題或規格說明書的規定有誤，用黑盒測試方法是發現不了的。黑盒測試方法著重測試軟件的功能需求，是在程序接口上進行測試，主要是為了發現以下錯誤：1.是否有不正確的功能，是否有遺漏的功能；2.在接口上，是否能夠正確地接收輸入數據并產生正確的輸出結果；3.是否有數據結構錯誤或外部信息訪問錯誤；4.性能上是否能夠滿足要求；5.是否有程序初始化和終止方面的錯誤。2.3.1黑盒測試方法概述

第二章軟件測試方法黑盒測試有兩個顯著的特點：黑盒測試不考慮軟件的具體實現過程，當在軟件實現的過程發生變化時，測試用例仍然可以使用；黑盒測試用例的設計可以和軟件實現同時進行，這樣能夠壓縮總的開發時間。黑盒測試不僅能夠找到大多數其他測試方法無法發現的錯誤，而且一些外購軟件、參數化軟件包以及某些自動生成的軟件，由于無法得到源程序，在一些情況下只能選擇黑盒測試。2.3.1黑盒測試方法概述

第二章軟件測試方法黑盒測試有兩種基本方法，即通過測試和失敗測試。在進行通過測試時，實際上是確認軟件能做什么，而不會去考驗其能力如何，軟件測試人員只是運用最簡單，最直觀的測試案例。在設計和執行測試案例時，總是先要進行通過測試，驗證軟件的基本功能是否都已實現。在確信了軟件正確運行之后，就可以采取各種手段通過搞垮軟件來找出缺陷。純粹為了破壞軟件而設計和執行的測試案例，被稱為失敗測試或迫使出錯測試。黑盒測試的具體技術方法主要包括邊界值分析法、等價類劃分法、因果圖法、決策表法等。這些方法是比較實用的，在項目中采用什么方法，在設計具體的測試方案時自然要針對開發項目的特點對設計方法進行適當的選擇。2.3.2等價類劃分法

第二章軟件測試方法1.等價類劃分法概述等價類劃分法是黑盒測試用例設計中一種常用的設計方法，它將不能窮舉的測試過程進行合理分類，從而保證設計出來的測試用例具有完整性和代表性。等價類劃分法是把所有可能的輸入數據，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。所謂等價類是指輸入域的某個子集合，所有等價類的并集就是整個輸入域。在等價類中，各個輸入數據對于揭露程序中的錯誤都是等效的，它們具有等價特性。因此，測試某個等價類的代表值就是等價于對這一類中其他值的測試。也就是說，如果某一類中的一個例子發現了錯誤，這一等價類中的其他例子也能發現同樣的錯誤；反之，如果某一類中的一個例子沒有發現錯誤，則這一類中的其他例子也不會查出錯誤。2.3.2等價類劃分法

第二章軟件測試方法軟件不能只接收合理有效的數據，也要具有處理異常數據的功能，這樣的測試才能確保軟件具有更高的可靠性。因此，在劃分等價類的過程中，不但要考慮有效等價類劃分，同時也要考慮無效等價類劃分。有效等價類是指對軟件規格說明來說，合理、有意義的輸入數據所構成的集合。利用有效等價類可以檢驗程序是否滿足規格說明所規定的功能和性能。無效等價類則和有效等價類相反，即不滿足程序輸入要求或者無效的輸入數據所構成的集合。利用無效等價類可以檢驗程序異常情況的處理。使用等價類劃分法設計測試用例，首先必須在分析需求規格說明的基礎上劃分等價類，然后列出等價類表。

2.3.2等價類劃分法

第二章軟件測試方法輸入條件有效等價類無效等價類………………在確立了等價類之后，建立等價類表，列出所有劃分出的等價類，如表2-1所示。表2-1等價類表再根據已列出的等價類表，按以下步驟確定測試用例：為每一個等價類規定一個唯一的編號；設計一個新的測試用例，使其盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這個過程，直至所有的有效等價類均被測試用例所覆蓋；設計一個新的測試用例，使其僅覆蓋一個無效等價類，重復這個過程，直至所有的無效等價類均被測試用例所覆蓋。以三角形問題為例，輸入條件是：三個數，分別作為三角形的三條邊都是整數取值范圍在1～100之間認真分析上述的輸入條件，可以得出相關的等價類表（包括有效等價類和無效等價類），如表2-2所示。2.3.2等價類劃分法

第二章軟件測試方法2.3.2等價類劃分法

第二章軟件測試方法輸入條件等價類編號有效等價類等價類編號無效等價類三個數1三個數4只有一條邊5只有兩條邊6多于三條邊整數2整數7一邊為非整數8兩邊為非整數9三邊為非整數取值范圍在1~10031≤a≤1001≤b≤1001≤c≤10010一邊為011兩邊為012三邊為013一邊小于014兩邊小于015三邊小于016一邊大于10017兩邊大于10018三邊大于100表2-2三角形問題的等價類2.3.2等價類劃分法

第二章軟件測試方法2.常見等價類劃分形式針對是否對無效數據進行測試，可以將等價類測試分為標準等價類測試、健壯等價類測試以及對等區間的劃分。(1)標準等價類測試標準等價類測試不考慮無效數據值，測試用例使用每個等價類中的一個值。通常，標準等價類測試用例的數量和最大等價類中元素的數目相等。以三角形問題為例，要求輸入三個整數a、b、c，分別作為三角形的三條邊，取值范圍在1～100之間，判斷由三條邊構成的三角形類型為等邊三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。在多數情況下，是從輸入域劃分等價類，但對于三角形問題，從輸出域來定義等價類是最簡單的劃分方法。因此，利用這些信息可以確定下列值域等價類：R1={〈a，b，c〉：邊為a，b，c的等邊三角形}R2={〈a，b，c〉：邊為a，b，c的等腰三角形}R3={〈a，b，c〉：邊為a，b，c的一般三角形}R4={〈a，b，c〉：邊為a，b，c不構成三角形}4個標準等價類測試用例如表2-3所示。2.3.2等價類劃分法

第二章軟件測試方法測試用例abc預期輸出TestCase1101010等邊三角形TestCase210105等腰三角形TestCase3345一般三角形TestCase4115不構成三角形表2-3三角形問題的標準等價類測試用例2.3.2等價類劃分法

第二章軟件測試方法(2)健壯等價類測試健壯等價類測試主要的出發點是考慮了無效等價類。對有效輸入，測試用例從每個有效等價類中取一個值；對無效輸入，一個測試用例有一個無效值，其他值均取有效值。健壯等價類測試存在兩個問題：需要花費精力定義無效測試用例的期望輸出；對強類型的語言沒有必要考慮無效的輸入

。2.3.2等價類劃分法

第二章軟件測試方法(3)對等區間劃分對等區間劃分是測試用例設計的非常規形式化的方法。它將被測對象的輸入/輸出劃分成一些區間，被測軟件對一個特定區間的任何值都是等價的。形成測試區間的數據不只是函數/過程的參數，也可以是程序可以訪問的全局變量、系統資源等，這些變量或資源可以是以時間形式存在的數據，或以狀態形式存在的輸入/輸出序列。對等區間劃分假定位于單個區間的所有值對測試都是對等的，應為每個區間的一個值設計一個測試用例。舉例說明如下：平方根函數要求當輸入值為0或大于0時，返回輸入數的平方根；當輸入值小于0時，顯示錯誤信息“平方根錯誤，輸入值小于0”，并返回0。輸入區間輸出區間ⅰ<0A>=0ⅱ>=0BError考慮平方根函數的測試用例區間，可以劃分出兩個輸入區間和兩個輸出區間，如表2-5所示。表2-5區間劃分通過分析，可以用兩個測試用例來測試4個區間：測試用例1：輸入4，返回2//區間ⅱ和A測試用例2：輸入-4，返回0，輸出“平方根錯誤，輸入值小于0”//區間ⅰ和B上例的對等區間劃分是非常簡單的。當軟件變得更加復雜時，對等區間的確定就越難，區間之間的相互依賴性就越強，使用對等區間劃分設計測試用例技術的難度會增加。2.3.2等價類劃分法

第二章軟件測試方法2.3.3邊界值分析法

第二章軟件測試方法1.邊界值分析法邊界值分析法（BoundaryValueAnalysis，BVA）是一種補充等價類劃分法的測試用例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試用例。在測試過程中，可能會忽略邊界值的條件，而軟件設計中大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是發生在輸入輸出范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。在實際的軟件設計過程中，會涉及到大量的邊界值條件和過程，這里有一個簡單的VB程序的例子：Dimdata(10)asIntegerDimiasIntegerFori=1to10data(i)=1Nexti2.3.3邊界值分析法

第二章軟件測試方法在這個程序中，目標是為了創建一個擁有10個元素的一維數組，看似合理，但是，在大多數Basic語言中，當一個數組被定義時，其第一個元素所對應的數組下標是0而不是1。由此，上述程序運行結束后，數組中成員的賦值情況如下：data(0)=0，data(1)=1，data(2)=1，...，data(10)=1這時，如果其他程序員在使用這個數組的時候，可能會造成軟件的缺陷或者錯誤的產生。使用邊界值分析方法設計測試用例，首先應確定邊界情況。通常輸入和輸出等價類的邊界，就是應著重測試的邊界情況。應當選取正好等于、剛剛大于或剛剛小于邊界的值作為測試數據，而不是選取等價類中的典型值或任意值作為測試數據。

2.3.3邊界值分析法

第二章軟件測試方法在應用邊界值分析法設計測試用例時，應遵循以下幾條原則：如果輸入條件規定了值的范圍，則應該選取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入數據。如果輸入條件規定了值的個數，則用最大個數、最小個數、比最小個數少1、比最大個數多1的數作為測試數據。根據規格說明的每一個輸出條件，分別使用以上兩個原則。如果程序的規格說明給出的輸入域或者輸出域是有序集合（如有序表、順序文件等），則應選取集合的第一個元素和最后一個元素作為測試用例。如果程序中使用了一個內部數據結構，則應當選擇這個內部數據結構的邊界值作為測試用例。分析規格說明，找出其他可能的邊界條件。第二章軟件測試方法2.邊界條件與次邊界條件邊界值分析法是對輸入的邊界值進行測試。在測試用例設計中，需要對輸入的條件進行分析并且找出其中的邊界值條件，通過對這些邊界值的測試來查出更多的錯誤。提出邊界條件時，一定要測試臨近邊界的有效數據，測試最后一個可能有效的數據，同時測試剛超過邊界的無效數據。通常情況下，軟件測試所包含的邊界檢驗有幾種類型：數值、字符、位置、數量、速度、尺寸等，在設計測試用例時要考慮邊界檢驗的類型特征：第一個/最后一個、開始/完成、空/滿、最大值/最小值、最快/最慢、最高/最低、最長/最短等。這些不是確定的列表，而是一些可能出現的邊界條件。

2.3.3邊界值分析法

第二章軟件測試方法2.3.3邊界值分析法

在多數情況下，邊界值條件是基于應用程序的功能設計而需要考慮的因素，可以從軟件的規格說明或常識中得到，也是最終用戶通常最容易發現問題的。然而，在測試用例設計過程中，某些邊界值條件是不需要呈現給用戶的，或者說用戶是很難注意到這些問題，但這些邊界條件同時確實屬于檢驗范疇內的邊界條件，稱為內部邊界值條件或次邊界值條件。主要有下面幾種：第二章軟件測試方法2.3.3邊界值分析法

項范圍或值位（bit）0或1字節（byte）0~255字（word）0~65、535（單字）或0~4、294、967、295（雙字）千（K）1024兆（M）1048576吉（G）1073741824太（T）1099511627776數值的邊界值檢驗計算機是基于二進制進行工作的，因此，任何數值運算都有一定的范圍限制，如表2-7所示。

表2-7計算機數值運算的范圍例如對字節進行檢驗，邊界值條件可以設置成254、255和256。第二章軟件測試方法2.3.3邊界值分析法

字符ASCII碼值字符ASCII碼值空（null）0A65空格（space）32a97斜杠（/）47左中括號（[）91048Z122冒號（：）58Z90@64單引號（‘）96字符的邊界值檢驗在字符的編碼方式中，ASCII和Unicode是比較常見的編碼方式，表2-8中列出了一些簡單的ASCII碼對應表。表2-8字符的ASCII碼對應表第二章軟件測試方法2.3.3邊界值分析法

在做文本輸入或者文本轉換的測試過程中，需要非常清晰地了解ASCII碼的一些基本對應關系，例如小寫字母z和大寫字母Z在表中的對應是不同的，這些也必須被考慮到數據區域劃分的過程中，從而定義等價有效類，來設計測試用例。其他邊界值檢驗

包括默認值/空值/空格/未輸入值/零、無效數據/不正確數據和干擾數據等。

在實際的測試用例設計中，需要將基本的軟件設計要求和程序定義的要求結合起來，即結合基本邊界值條件和子邊界值條件來設計有效的測試用例。第二章軟件測試方法2.3.3邊界值分析法

3.邊界值分析法測試用例以三角形問題為例，要求輸入三個整數a、b、c，分別作為三角形的三條邊，取值范圍在1～100之間，判斷由三條邊構成的三角形類型為等邊三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。如表2-9所示給出了邊界值分析測試用例。第二章軟件測試方法2.3.3邊界值分析法

測試用例abc預期輸出TestCase115050等腰三角形TestCase225050等腰三角形TestCase3505050等邊三角形TestCase4995050等腰三角形TestCase51005050非三角形TestCase650150等腰三角形TestCase750250等腰三角形TestCase8509950等腰三角形TestCase95010050非三角形TestCase1050501等腰三角形TestCase1150502等腰三角形TestCase12505099等腰三角形TestCase135050100非三角形表2-9邊界值分析測試用例2.3.4決策表法

第二章軟件測試方法1.決策表法在所有的黑盒測試方法中，基于決策表（也稱判定表）的測試是最為嚴格、最具有邏輯性的測試方法。決策表是分析和表達多個邏輯條件下執行不同操作情況的工具。由于決策表可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確，在程序設計發展的初期，決策表就已被當作編寫程序的輔助工具了。決策表通常由四個部分組成，如圖2-2所示。條件樁：列出了問題的所有條件，通常認為列出的條件的先后次序無關緊要。動作樁：列出了問題規定的可能采取的操作，這些操作的排列順序沒有約束。條件項：針對條件樁給出的條件列出所有可能的取值。動作項：與條件項緊密相關，列出在條件項的各組取值情況下應該采取的動作。2.3.4決策表法

第二章軟件測試方法圖2-2決策表的組成2.3.4決策表法

第二章軟件測試方法任何一個條件組合的特定取值及其相應要執行的操作稱為一條規則，在決策表中貫穿條件項和動作項的一列就是一條規則。顯然，決策表中列出多少組條件取值，也就有多少條規則，即條件項和動作項有多少列。根據軟件規格說明，建立決策表的步驟如下：確定規則的個數。假如有n個條件，每個條件有兩個取值，故有2n種規則。列出所有的條件樁和動作樁。填入條件項。填入動作項，得到初始決策表。化簡。合并相似規則（相同動作）。2.3.4決策表法

第二章軟件測試方法以下列問題為例給出構造決策表的具體過程。如果某產品銷售好并且庫存低，則增加該產品的生產；如果該產品銷售好，但庫存量不低，則繼續生產；若該產品銷售不好，但庫存量低，則繼續生產；若該產品銷售不好，且庫存量不低，則停止生產。2.3.4決策表法

第二章軟件測試方法解法如下：確定規則的個數。對于本題有2個條件（銷售、庫存），每個條件可以有兩個取值，故有22=4種規則。列出所有的條件樁和動作樁。填入條件項。填入動作項，得到初始決策表，如表2-10所示。每種測試方法都有適用的范圍，決策表法適用于下列情況：規格說明以決策表形式給出，或很容易轉換成決策表。條件的排列順序不會也不應影響執行哪些操作。規則的排列順序不會也不應影響執行哪些操作。每當某一規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則。如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。2.3.4決策表法

第二章軟件測試方法

規則選項1234條件：C1：銷售好?C2：庫存低?TTTFFTFF動作：a1：增加生產a2：繼續生產a3：停止生產√√√√表2-10產品銷售問題的決策表2.3.4決策表法

第二章軟件測試方法2.決策表法的應用決策表最突出的優點是，能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用決策表能夠設計出完整的測試用例集合。運用決策表設計測試用例，可以將條件理解為輸入，將動作理解為輸出。以三角形問題為例，要求輸入三個整數a、b、c，分別作為三角形的三條邊，取值范圍在1～100之間，判斷由三條邊構成的三角形類型為等邊三角形、等腰三角形、一般三角形（包括直角三角形）以及非三角形。2.3.4決策表法

第二章軟件測試方法分析如下：確定規則的個數。例如，三角形問題的決策表有4個條件，每個條件可以取兩個值（真值和假值），所以應該有24=16種規則。列出所有條件樁和動作樁。填寫條件項。填寫動作項，從而得到初始決策表。如表2-11所示。簡化決策表。合并相似規則后得到三角形問題的簡化決策表。如表2-12所示。2.3.4決策表法

第二章軟件測試方法

規則

選項12345678條件：C1：a，b，c構成一個三角形？C2：a=b？C3：b=c？C4：a=c？FTTTFTTFFTFTFTFFFFTTFFTFFFFTFFFF動作：a1：非三角形a2：一般三角形a3：等腰三角形a4：等邊三角形a5：不可能√√√√√√√√表2-11三角形問題的初始決策表2.3.4決策表法

第二章軟件測試方法

規則選項910111213141516條件：C1：a，b，c構成一個三角形？C2：a=b？C3：b=c？C4：a=c？TTTTTTTFTTFTTTFFTFTTTFTFTFFTTFFF動作：a1：非三角形a2：一般三角形a3：等腰三角形a4：等邊三角形a5：不可能

√√√√√√√√2.3.4決策表法

第二章軟件測試方法

規則

選項1～8910111213141516

條件：C1：a，b，c構成一個三角形？C2：a=b？C3：b=c？C4：a=c？F－－－TTTTTTTFTTFTTTFFTFTTTFTFTFFTTFFF

動作：a1：非三角形a2：一般三角形a3：等腰三角形a4：等邊三角形a5：不可能√

√√√√√√√√表2-12三角形問題的簡化決策表2.3.4決策表法

第二章軟件測試方法測試用例abc預期輸出TestCase11044非三角形TestCase2444等邊三角形TestCase3???不可能TestCase4???不可能TestCase5445等腰三角形TestCase6???不可能TestCase7544等腰三角形TestCase8454等腰三角形TestCase9345一般三角形根據決策表2-12，可設計測試用例，如表2-13所示。表2-13三角形問題的決策表測試用例2.3.5因果圖法

第二章軟件測試方法1.因果圖法前面介紹的等價類劃分法和邊界值分析法都著重考慮輸入條件，而沒有考慮到輸入條件的各種組合情況，也沒有考慮到各個輸入條件之間的相互制約關系。因此，必須考慮采用一種適合于多種條件的組合，相應能產生多個動作的形式來進行測試用例的設計，這就需要采用因果圖法。因果圖法就是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種情況的組合。在因果圖中使用4種符號分別表示4種因果關系，如圖2-3所示。用直線連接左右節點，其中左節點Ci表示輸入狀態（或稱原因），右節點ei表示輸出狀態（或稱結果）。Ci和ei都可取值0或1，0表示某狀態不出現，1表示某狀態出現。2.3.5因果圖法

第二章軟件測試方法

（a）恒等

圖2-3因果圖的基本符號（b）非（c）或（d）與2.3.5因果圖法

第二章軟件測試方法圖2-3中各符號的含義如下：圖(a)：表示恒等。若C1是1，則e1也是1；若C1是0，則e1為0。圖(b)：表示非。若C1是1，則e1是0；若C1是0，則e1為1。圖(c)：表示或。若C1或C2或C3是1，則e1是1；若C1、C2、C3全為0，則e1為0。圖(d)：表示與。若C1和C2都是1，則e1是1；只要C1、C2、C3中有一個為0，則e1為0。在實際問題中，輸入狀態相互之間還可能存在某些依賴關系，我們稱之為約束。例如，某些輸入條件不可能同時出現。輸出狀態之間也往往存在約束，在因果圖中，以特定的符號標明這些約束，如圖2-4所示。2.3.5因果圖法

第二章軟件測試方法

（a）異（b）或（c）惟一

圖2-4約束符號（d）要求（e）強制2.3.5因果圖法

第二章軟件測試方法2.3.5因果圖法

第二章軟件測試方法圖2-4中對輸入條件的約束如下：圖(a)：表示E約束（異）。a和b中最多有一個可能為1，即a和b不能同時為1。圖(b)：表示I約束（或）。a、b和c中至少有一個必須是1，即a、b和c不能同時為0。圖(c)：表示O約束（唯一）。a和b中必須有一個且僅有一個為1。圖(d)：表示R約束（要求）。a是1時，b必須是1，即a是1時，b不能是0。對輸出條件的約束只有M約束。M約束（強制）：若結果a是1，則結果b強制為0。因果圖法最終要生成決策表。2.3.5因果圖法

第二章軟件測試方法利用因果圖法生成測試用例需要以下幾個步驟：分析軟件規格說明書中的輸入輸出條件，并且分析出等價類。分析規格說明中的語義的內容，通過這些語義來找出相對應的輸入與輸入之間，輸入與輸出之間的對應關系。將對應的輸入與輸入之間，輸入與輸出之間的關系連接起來，并且將其中不可能的組合情況標注成約束或者限制條件，形成因果圖。將因果圖轉換成決策表。將決策表的每一列作為依據，設計測試用例。上述步驟如圖2-5所示。從因果圖生成的測試用例中包括了所有輸入數據取真值和假值的情況，構成的測試用例數目達到最少，且測試用例數目隨輸入數據數目的增加而線性地增加。2.3.5因果圖法

第二章軟件測試方法某軟件規格說明中包含這樣的要求：輸入的第一個字符必須是A或B，第二個字符必須是一個數字，在此情況下進行文件的修改；但如果第一個字符不正確，則給出信息L；如果第二個字符不是數字，則給出信息M。2.3.5因果圖法

第二章軟件測試方法圖2-5因果圖法示例2.3.5因果圖法

第二章軟件測試方法解法如下：分析程序的規格說明，列出原因和結果。原因：C1第一個字符是AC2第一個字符是BC3第二個字符是一個數字結果：e1給出信息L

e2修改文件

e3給出信息M2.3.5因果圖法

第二章軟件測試方法將原因和結果之間的因果關系用邏輯符號連接起來，得到因果圖，如圖2-6所示。編號為11的中間節點是導出結果的進一步原因。圖2-6因果圖示例2.3.5因果圖法

第二章軟件測試方法因為C1和C2不可能同時為1，即第一個字符不可能既是A又是B，在因果圖上可對其施加E約束，得到具有約束的因果圖，如圖2-7所示。圖2-7具有E約束的因果圖2.3.5因果圖法

第二章軟件測試方法將因果圖轉換成決策表，如表2-14所示。規則選項12345678條件C111110000C211001100C31010101011111100動作e1000011e2101000e3010101不可能11測試用例A5A#B9B?X2Y%表2-14決策表2.3.5因果圖法

第二章軟件測試方法設計測試用例。表2-14中的前兩種情況，因為C1和C2不可能同時為1，所以應排除這兩種情況。根據此表，可以設計出6個測試用例，如表2-15所示。編號輸入數據預期輸出TestCase1A5修改文件TestCase2A#給出信息MTestCase3B9修改文件TestCase4B?給出信息MTestCase5X2給出信息LTestCase6Y%給出信息L和信息M表2-15測試用例2.3.6各種黑盒測試方法的選擇第二章軟件測試方法為了最大程度地減少測試遺留的缺陷，同時也為了最大限度地發現存在的缺陷，在測試實施之前，測試工程師必須確定將要采用的黑盒測試策略和方法，并以此為依據制定詳細的測試方案。通常，一個好的測試策略和測試方法必將給整個測試工作帶來事半功倍的效果。如何才能確定好的黑盒測試策略和測試方法呢？通常，在確定黑盒測試方法時，應該遵循以下原則：根據程序的重要性和一旦發生故障將造成的損失程度來確定測試等級和測試重點。認真選擇測試策略，以便能盡可能少地使用測試用例，發現盡可能多的程序錯誤。因為一次完整的軟件測試過后，如果程序中遺留的錯誤過多并且嚴重，則表明該次測試是不足的，而測試不足則意味著讓用戶承擔隱藏錯誤帶來的危險，但測試過度又會帶來資源的浪費。因此，測試需要找到一個平衡點。以下是各種黑盒測試方法選擇的綜合策略，可在實際應用過程中參考。首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率的最有效方法。在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。如