1、軟件工程,第4章 軟 件 實 現(xiàn),本章要點 ： 程序設計語言及編碼風格 軟件測試的任務、方法及步驟 單元測試、集成測試和系統(tǒng)測試 測試用例的設計 面向?qū)ο蟮能浖y試策略及用例設計 軟件調(diào)試的原則、方法和步驟 軟件可靠性 常用的軟件測試工具,軟件工程,第4章 軟 件 實 現(xiàn),本章學習目標 ： 理解并掌握程序設計語言的分類和選擇，理解程序設計中應注意的問題，培養(yǎng)良好的編程風格。了解常用的程序設計工具及軟件測試CASE工具 掌握測試階段的目的及原則、測試方法和步驟 理解單元測試、集成測試和系統(tǒng)測試方法和策略 深刻理解并掌握白盒、黑盒測試法用例的設計技術(shù) 了解面向?qū)ο蟮臏y試策略及測試用例的設計 理解調(diào)

2、試的原則，掌握調(diào)試的方法和步驟 掌握可靠性概念及指標，MTTF及錯誤總數(shù)的估算方法,軟件工程,第4章 軟 件 實 現(xiàn),軟件編碼和軟件測試通常統(tǒng)稱為軟件實現(xiàn)。 軟件編碼就是平常所說的軟件編程，實質(zhì)上，編碼是把詳細設計的算法翻譯成計算機上可執(zhí)行的語言，翻譯員就是程序員。 程序的質(zhì)量主要取決于軟件設計的質(zhì)量。 在軟件交付使用以前必須經(jīng)過嚴格的軟件測試，通過測試盡可能找出軟件計劃、總體設計、詳細設計、軟件編碼中的錯誤，并加以糾正，才能得到高質(zhì)量的軟件。 通常軟件測試并不是在軟件編碼完全完成后進行，它常常橫跨軟件生命周期中兩個階段。 測試的工作量和成本非常大，據(jù)統(tǒng)計測試工作量要占軟件開發(fā)總工作量的40到

3、50以上，用在測試上的開銷要占軟件開發(fā)總成本的30%至50%。測試的目的是確保軟件的質(zhì)量，盡量找出軟件錯誤并加以糾正，而不是證明軟件沒有錯誤。,軟件工程,4.1 編 碼,4.1.1 程序設計語言 1 程序設計語言的分類 根據(jù)程序設計語言的發(fā)展歷程基本上可以分為低級語言和高級語言兩大類。 (1) 低級語言 低級語言包括機器語言和匯編語言。這兩種語言都依賴于相應的計算機硬件。機器語言屬于第一代語言，匯編語言屬于第二代語言 。 (2) 高級語言 高級語言包括第三代程序設計語言和第四代超高級程序設計語言(簡稱4GL)。第三代程序設計語言利用類英語的語句和命令，盡量不再指導計算機如何去完成一項操作，如B

4、ASIC、COBOL和FORTRAN等。第四代程序設計語言比第三代程序設計語言更像英語但過程更弱，與自然語言非常接近，它兼有過程性和非過程性的兩重特性，如數(shù)據(jù)庫查詢語言、程序生成器等。,軟件工程,高級語言分類,分別從應用特點和語言內(nèi)在特點兩個不同角度對高級語言進行分類,軟件工程,2 程序設計語言的選擇,通常選擇程序設計語言時優(yōu)先考慮高級語言，而不是低級語言(主要是匯編語言)。這是因為高級語言明顯優(yōu)于低級語言。 高級語言的選擇可以參照以下標準。 理想標準 l 為了使程序容易測試和維護以減少軟件的總成本，所選用的高級語言應該有理想的模塊化機制，以及可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)。 l 為了便于調(diào)試和

5、提高軟件可靠性，應該使編譯程序能夠盡可能多地發(fā)現(xiàn)程序中的錯誤。 l為了降低軟件開發(fā)和維護的成本，選用的高級語言應該有良好的獨立編譯機制。,軟件工程,2 程序設計語言的選擇,實用標準 l語言自身的特性 l軟件的應用領(lǐng)域 l軟件開發(fā)的環(huán)境 l軟件開發(fā)的方法 l算法和數(shù)據(jù)結(jié)構(gòu)的復雜性 l軟件可移植性要求 l軟件開發(fā)人員的知識,軟件工程,2 程序設計語言的選擇,目前在軟件實現(xiàn)中使用面向?qū)ο笳Z言非常普遍。到底應該選用面向?qū)ο笳Z言還是非面向?qū)ο笳Z言，關(guān)鍵不在于語言功能強弱。選擇面向?qū)ο笳Z言的關(guān)鍵因素，是語言的一致的表達能力、可重用性及可維護性。開發(fā)人員在選擇面向?qū)ο笳Z言時，除了考慮上述的實用標準以外，還應

6、該著重考慮以下一些實際因素： l可重用性。 l類庫和開發(fā)環(huán)境。 l將來能否占主導地位。 l其他因素。,軟件工程,4.1.2 編碼風格,編碼風格又稱程序設計風格或編程風格。編碼風格實際上指編程的基本原則。 1. 好程序的標準 l能夠工作，即能夠滿足用戶的使用要求。 l 可靠性高。 l 使用方便。 l 簡單、容易理解。 l 易于維護和修改。 l 高效率。 l 易移植性。 l 可重用性。,軟件工程,2. 編程的基本原則,一個公認的、良好的編程風格可以減少編碼的錯誤，減少讀程序的時間，從而提高軟件的開發(fā)效率。為了做到這一點，應該遵循下述一些原則： l源程序文檔化 l數(shù)據(jù)說明：在編寫程序時，要注意數(shù)據(jù)說

7、明的風格。 l語句構(gòu)造 ：構(gòu)造的語句要簡單、直接，不要為了提高效率而使語句更為復雜。 l輸入和輸出：輸入輸出的方式和格式應當盡量作到對用戶友好，盡可能方便用戶的使用。 l效率：選擇良好的設計方法才是提高程序效率的根本途徑，設計良好的數(shù)據(jù)結(jié)構(gòu)與算法，都是提高程序效率的重要方法。,軟件工程,2. 編程的基本原則,由于面向?qū)ο蟮某绦蛟O計語言所具有的特殊性，面向?qū)ο缶幊淘瓌t，除了遵循上述編程的基本原則之外，還包括為適應面向?qū)ο蠓椒ㄋ赜械母拍?如繼承性)而必須遵循的一些新原則： l提高可重用性 l提高可擴充性 l提高健壯性 總之，在編碼時要善于積累編程經(jīng)驗，培養(yǎng)和學習良好的編程風格，使程序清晰易懂，易

8、于測試與維護，從而提高軟件的質(zhì)量。,軟件工程,4.1.3 常用程序設計工具簡介,目前不同的程序設計語言相應的程序設計工具非常之多，而且相同的程序設計語言對應的程序設計工具隨各公司不同而五花八門。但比較流行和常用的有：Microsoft系列有Visual Studio和Visual Studio.NET；Borland系列有Delphi、Jbuilder、C+ Builder；其它還有Eclipse、Visual Age for Java、Visual Caf for Java、PowerBuilder和Macromedia系列等。,軟件工程,4.2 軟件測試概述,Grenford JMyers

9、在The Art Of Software Testing一書中的觀點常被許多人作為軟件測試的目的或定義： l 軟件測試是為了發(fā)現(xiàn)缺陷而執(zhí)行程序的過程。 l 測試是為了證明程序中有錯誤，而不是證明程序中無錯誤。 l一個好的測試用例指的是它可能發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的缺陷。 l一次成功的測試指的是發(fā)現(xiàn)了新的軟件缺陷的測試。 測試的目的是想以最少的時間和人力找出軟件中潛在的各種錯誤和缺陷。測試只能盡可能多的查找出程序中錯誤，而不能證明程序中沒有錯誤。,軟件工程,4.2 軟件測試概述,軟件測試的范圍并不只是對編碼階段的語法錯、語義錯、運行錯進行查找的一系列活動。而是對軟件計劃、軟件設計、軟件編碼進行查錯和糾

10、錯的活動，它涉及到軟件開發(fā)周期中各個階段的錯誤，并分析錯誤的性質(zhì)與位置而加以糾正。糾正過程可能涉及到改正或重新設計相關(guān)的文檔活動。找錯的活動稱軟件測試，糾錯的活動稱軟件調(diào)試。,軟件工程,4.2.1 軟件測試的概念和原則,1. 錯誤(error)、缺陷(fault)和故障(failure) 人們在進行軟件開發(fā)的過程中犯了一個錯，則稱為一個錯誤(error)。應用到測試過程時，有兩種不同的使用方式。在第種使用方式中，錯誤是指一個實際測量值與理論預期值之間的差異，這種差異就是錯誤；第二種使用方式中，錯誤是指一些人的行為引起的軟件中的某種故障，通常這些故障是由軟件錯誤造成的。 缺陷(fault)常被稱

11、為bug，它是導致軟件失敗的一個條件。當開發(fā)人員犯了一個錯，就會在軟件中引人一個或多個缺陷。 故障(failure)又稱失效，它是指軟件不能按軟件規(guī)格說明要求執(zhí)行，從而引起軟件行為與用戶需求的不一致現(xiàn)象。失效可能發(fā)生在測試階段，也可能發(fā)生在軟件交付之后的運行階段和維護階段。 缺陷是開發(fā)人員所看到的軟件系統(tǒng)的內(nèi)部問題，而故障是用戶從外部觀察到的軟件行為與軟件需求的偏差。并不是每個軟件缺陷都一定會導致軟件發(fā)生故障，缺陷只有在滿足某種條件的情況下才會導致軟件故障。,軟件工程,4.2.1 軟件測試的概念和原則,2. 軟件測試的基本原則 l不完全原則 ：不完全原則表明測試是不完全的，窮舉測試是不可能的。

12、 l免疫性原則 ：軟件缺陷具有免疫性，測試人員完成的測試越多，其免疫能力就越強，尋找更多軟件缺陷也就更加困難。 l全程測試原則 ：全程測試原則要求軟件測試不僅存在于完成程序之后，而應該跨越整個軟件開發(fā)流程。 l 8020原則 ：8020原則是指80的軟件缺陷存在于軟件20的空間里，軟件缺陷具有空間聚集性。,軟件工程,4.2.2 軟件測試的方法和步驟,1. 軟件測試方法 根據(jù)測試過程是否需要運行被測試的程序，軟件測試方法一般分為靜態(tài)測試方法與動態(tài)測試方法。 靜態(tài)測試 靜態(tài)測試是在對軟件代碼進行分析、檢查和測試時不實際運行被測試的程序，同時它還可以用于對各種軟件文檔進行測試。靜態(tài)測試可以采用人工檢

13、測和計算機輔助的手段進行，它適用于軟件開發(fā)的全過程。 靜態(tài)測試方法主要有代碼走通(Code Walkthrough)和Fagan檢查兩種。,軟件工程,1. 軟件測試方法,動態(tài)測試 動態(tài)測試就是通過運行軟件來檢驗軟件的動態(tài)行為和運行結(jié)果的正確性。動態(tài)測試的主要特征是計算機必須真正運行被測試的程序，通過輸入測試數(shù)據(jù)，對其運行情況(即輸入與輸出之間的對應關(guān)系)進行分析。因此所有動態(tài)測試都必須包括兩個基本要素：被測試軟件和用于運行軟件的數(shù)據(jù)，即測試數(shù)據(jù)。動態(tài)測試根據(jù)測試時的方法不同，分為黑盒測試與白盒測試兩類。,軟件工程,黑盒測試,黑盒測試又稱為功能測試或數(shù)據(jù)驅(qū)動測試。它是在已知軟件所應具有功能的前提

14、下，通過測試來檢測每個功能是否都能正常使用。該方法把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程，只在軟件的界面上進行測試，用來證實軟件功能的可操作性，檢查程序是否滿足功能要求或遺漏了功能，程序是否能正確地接收輸入數(shù)據(jù)并產(chǎn)生正確的輸出信息，數(shù)據(jù)結(jié)構(gòu)是否錯誤或外部數(shù)據(jù)庫訪問是否錯誤，界面和性能是否錯誤，初始化和終止是否錯誤。黑盒測試方法主要有等價類劃分、邊界值分析、錯誤推測等，它主要用于軟件系統(tǒng)測試階段。,軟件工程,白盒測試,白盒測試也稱結(jié)構(gòu)測試或邏輯驅(qū)動測試。它是在已知程序內(nèi)部結(jié)構(gòu)和處理過程的前提下，通過測試來檢測程序中的每條路徑是否按預定要求正常運行。該方法把被測試對

15、象看成一個透明的白盒子，測試人員完全知道程序的內(nèi)部結(jié)構(gòu)和處理算法，并按照程序內(nèi)部的邏輯測試程序，對程序中盡可能多的邏輯路徑進行測試，在所有的點檢驗內(nèi)部控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)是否和預期相同。白盒測試方法主要有邏輯覆蓋、基本路徑測試等，它主要用于驗證測試的充分性。,軟件工程,2.軟件測試過程,一個規(guī)范化的軟件測試過程通常包括以下一些基本測試活動：制定軟件測試計劃、編制軟件測試大綱、設計和生成測試用例、實施測試、生成軟件問題報告。 通?？梢詫y試階段劃分成代碼審查、單元測試、集成測試和系統(tǒng)測試4個階段。 代碼審查 代碼審查是一種非常有效的程序驗證技術(shù)，對于典型的程序來說，可以查出30%70%的邏輯設計錯

16、誤和編碼錯誤。它是由審查小組通過閱讀、討論和爭議對程序進行靜態(tài)測試的過程。,軟件工程,2.軟件測試過程,單元測試 單元測試就是對軟件中的基本組成單位(如一個類、類中的一個方法、一個模塊等)進行測試。因為需要知道程序內(nèi)部設計和編碼的細節(jié)，所以單元測試一般由程序員而非測試人員來完成。通過測試可發(fā)現(xiàn)實現(xiàn)該模塊的實際功能與定義該模塊的功能說明不符合的情況，以及編碼的錯誤。 集成測試 集成測試又稱組裝測試或聯(lián)合測試。它是指在單元測試的基礎上，將模塊或組件按照設計要求組裝起來同時進行測試，其主要目標是發(fā)現(xiàn)與接口有關(guān)的問題，即模塊或組件之間的協(xié)調(diào)與通信。,軟件工程,2.軟件測試過程,系統(tǒng)測試 集成完模塊或組

17、件后，系統(tǒng)測試是確保整個測試的軟件系統(tǒng)與系統(tǒng)的功能和非功能性需求保持一致。為了完成這一目的，需要開展下面幾種系統(tǒng)測試活動：功能測試、性能測試、驗收測試、安裝測試。 與軟件開發(fā)過程相反，測試是從模塊或組件開始，自底向上逐步集成的過程。代碼審查主要是發(fā)現(xiàn)編碼時產(chǎn)生的錯誤；單元測試主要是發(fā)現(xiàn)詳細設計說明書或源程序代碼的錯誤；集成測試發(fā)現(xiàn)的往往是概要設計中的錯誤或需求說明書中的錯誤；系統(tǒng)測試主要是發(fā)現(xiàn)需求說明書中的錯誤。因此軟件測試就是對軟件開發(fā)各階段產(chǎn)生的錯誤進行檢查，以便得到一個最終滿足用戶需要的軟件系統(tǒng)。,軟件工程,4.3 軟件測試的策略,4.3.1 單元測試 在單元測試時，由于被測試的模塊或組

18、件處于整個軟件結(jié)構(gòu)的某一層位置上，一般是被其它模塊或組件調(diào)用或調(diào)用其它模塊或組件，其本身不能單獨運行，因此需要為被測模塊或組件設計驅(qū)動程序和存根程序。所謂驅(qū)動程序也就是一個“主程序”，它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測試的模塊或組件，并且印出有關(guān)的結(jié)果。存根程序也稱樁(stub)程序，它代替被測試的模塊所調(diào)用的模塊或組件。因此存根程序也可以稱為“虛擬子程序”。 單元測試通常采用白盒測試對模塊或組件進行徹底測試，然后輔之以黑盒測試使之對任何合理和不合理的輸入都能鑒別和響應。所測模塊、驅(qū)動程序和存根程序共同構(gòu)成了一個模塊“測試環(huán)境”。測試主要針對每個模塊或組件的5個基本特征進行測試：模塊或組件接

19、口、局部數(shù)據(jù)結(jié)構(gòu)、重要的執(zhí)行通路、出錯處理通路和影響上述各方面特性的邊界條件等。,軟件工程,4.3 軟件測試的策略,4.3.2 集成測試 在每個模塊完成單元測試以后，需要按照設計時的結(jié)構(gòu)圖，把它們連接起來，進行集成測試。通常將模塊連接成系統(tǒng)主要有兩種方式：非漸增方式、漸增方式。 1. 非漸增方式 不非漸增方式又稱為一次性組裝方式， 也稱為大爆炸集成(Big-bang Integration)。這種方式是在所有模塊進行了單元測試后，將所有模塊按設計的結(jié)構(gòu)圖要求連接起來，連接后的程序作為一個整體來進行測試。 在一些很小型的軟件項目中，可以使用非漸增方式進行系統(tǒng)集成測試，而在大型軟件項目中，這種集成

20、測試策略顯然是不合適的。所以目前在進行集成測試時普遍采用漸增方式來進行測試。,軟件工程,4.3.2 集成測試,2. 漸增方式 漸增方式又稱增殖式組裝方式。該方式是把下一個要測試的模塊同已經(jīng)測試好的模塊連接起來進行測試，測試完以后再把下一個應該測試的模塊連接進來測試。顯然漸增方式的作法與非漸增方式不同。它的集成是逐步實現(xiàn)的，集成測試也是逐步完成的。當使用漸增方式把模塊連接到程序中去，按不同的次序?qū)嵤r有：自頂向下和自底向上兩種策略可供選擇。 自頂向下集成 自頂向下集成首先單獨測試最頂層的模塊或構(gòu)件。最頂層的模塊或構(gòu)件一般是一個控制模塊或構(gòu)件，它可能調(diào)用其他還沒有測試的模塊或構(gòu)件。因此，測試時需要

21、為它編寫存根程序代替所有直接附屬于主控模塊的模塊。存根程序接受被測模塊或構(gòu)件的調(diào)用并且返回結(jié)果數(shù)據(jù)，以便測試能夠進行下去。,軟件工程,2. 漸增方式,自頂向下集成 在組裝過程中，可以使用深度優(yōu)先的策略或?qū)挾葍?yōu)先的策略。深度優(yōu)先的策略是首先集成一個主控路徑下的所有模塊，主控路徑的選擇具有任意性，它依賴于應用程序的特性。寬度優(yōu)先的策略是將每一層中所有直接隸屬于上層的模塊集成起來測試。為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試。 所謂回歸測試就是在對軟件進行修改之后所進行的測試，其目的是檢驗對軟件的修改是否正確?；貧w測試一般在軟件維護階段進行，但在軟件開發(fā)和測試階段也經(jīng)常會用到?；貧w測試

22、通常包括重新運行原有的測試數(shù)據(jù)。因此，需要弄清哪些測試數(shù)據(jù)與被修改部分有關(guān)。,軟件工程,2. 漸增方式,自底向上集成 自底向上集成首先單獨測試位于系統(tǒng)最底層的模塊或構(gòu)件，然后將最底層模塊或構(gòu)件與那些直接調(diào)用最底層模塊或構(gòu)件的上一層模塊或構(gòu)件集成起來一起測試。這個過程一直持續(xù)下去，直到將系統(tǒng)所有的模塊或構(gòu)件都集成起來，形成一個完整的軟件系統(tǒng)進行測試。具體步驟如下： 把低層模塊組合成實現(xiàn)某個特定的軟件子功能的功能集合。 寫一個驅(qū)動程序(用于測試的控制程序)，協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出。 對由模塊組成的子功能集合進行測試。 去掉驅(qū)動程序，沿軟件結(jié)構(gòu)自下而上移動，把子功能集合組合起來形成更大的子功能集合

23、。 重復步。 自底向上集成測試一般適用于底層存在眾多通用例行子程序、采用面向?qū)ο笤O計方法以及系統(tǒng)使用了大量單獨的可重用模塊的地方。,軟件工程,2. 漸增方式,自頂向下測試方法的主要優(yōu)點是不需要測試驅(qū)動程序，能夠在測試階段的早期實現(xiàn)并驗證系統(tǒng)的主要功能，而且能在早期發(fā)現(xiàn)上層模塊的接口錯誤。自頂向下測試方法的主要缺點是需要存根程序，可能遇到與此相聯(lián)系的測試困難，低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚，而且用這種方法在早期不能充分展開人力。因此在實際的集成測試中，往往采用將兩種策略進行混合使用的策略。 改進的自頂向下集成。 混合法或三明治集成(Sandwich Integration)。,軟件工程,4.3.3

24、 系統(tǒng)測試,系統(tǒng)測試的目的是保證所實現(xiàn)的系統(tǒng)確實是用戶所想要的。為了到達此目的，需要完成一系列測試活動。這些活動包括功能測試、性能測試、驗收測試、安裝測試。 1. 功能測試 功能測試也稱為需求測試，主要測試系統(tǒng)的功能性需求，找出功能性需求和系統(tǒng)之間的差異，即檢查軟件系統(tǒng)是否完成了需求規(guī)格中所指定的功能。功能測試主要使用黑盒測試技術(shù)。 2. 性能測試 性能測試主要測試系統(tǒng)的非功能性需求，找出非功能性需求和系統(tǒng)之間的差異，即檢查軟件系統(tǒng)是否完成了需求規(guī)格中所指定的非功能性要求，如安全性、計算精度、運行速度以及安全性等。性能測試期間要進行很多項測試活動，下面是主要的一些活動。,軟件工程,4.3.3

25、系統(tǒng)測試,2. 性能測試 強度測試 安全性測試 恢復測試 軟件配置審查 兼容性測試 通過功能測試和性能測試后有下述兩種可能的結(jié)果： 功能和性能與用戶要求一致，軟件是可以接受的； 功能和性能與用戶要求有差距。 如出現(xiàn)中的結(jié)果，則可進行以未來用戶為主的驗收測試。如出現(xiàn)中的情況，則問題就比較復雜。在這個階段發(fā)現(xiàn)的問題往往和需求分析階段的差錯有關(guān)，涉及面通常比較廣，因此解決起來也比較困難。為了制定解決該測試過程中發(fā)現(xiàn)的軟件缺陷或錯誤的策略，通常需要和用戶充分協(xié)商。,軟件工程,4.3.3 系統(tǒng)測試,3.驗收測試 驗收測試的目的是使得未來的用戶能夠確認所開發(fā)的系統(tǒng)滿足了他們的需求，并確實是他們所想要的系統(tǒng)

26、。在此階段開發(fā)人員提供必要的支持和幫助，由用戶自己設計和運行測試數(shù)據(jù)，驗收測試一般采用黑盒測試。驗收測試的組織一般有三種方式：基準測試、典型測試和并行測試。 l 基準測試 基準測試有一個很特殊的應用場合：用戶具有明確的項目需求，為了降低開發(fā)風險，用戶同時要求兩個或兩個以上的開發(fā)團隊按照他們給出的一份相同的需求各自獨立地開發(fā)系統(tǒng)。待各個系統(tǒng)開發(fā)完成之后，用戶組織基準測試。首先，用戶準備一個測試用例集合，這個集合代表了系統(tǒng)運行的典型情況。然后，用戶在各個系統(tǒng)中運行每個測試用例，并就系統(tǒng)所實現(xiàn)的功能和性能情況作出評價。最后，基于基準測試的結(jié)果，用戶選擇購買其中的一個軟件系統(tǒng)。,軟件工程,3.驗收測試

27、,l 典型測試 它是在試用的基礎上來運行系統(tǒng)，依賴于每天對系統(tǒng)的操作來測試各項功能。如果一個軟件是為許多客戶開發(fā)的（例如，向大眾公開出售的盒裝軟件產(chǎn)品），那么，讓每個客戶都進行典型測試是不現(xiàn)實的。在這種情況下，絕大多數(shù)軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程，來發(fā)現(xiàn)那些看起來只有最終用戶才能發(fā)現(xiàn)的錯誤。 Alpha測試由用戶在開發(fā)環(huán)境下進行的測試，并且在開發(fā)者對用戶的“指導”下進行測試。開發(fā)者坐在用戶旁邊，負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題?？傊珹lpha測試是在受控的環(huán)境中進行的。,軟件工程,3.驗收測試,Beta測試由軟件的最終用戶們在一個或多個用戶的實際使用環(huán)境下進行

28、的測試。與Alpha測試不同，開發(fā)者通常不在Beta測試的現(xiàn)場，因此，Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應用。用戶記錄在Beta測試過程中遇到的一切問題（真實的或想像的），并且定期把這些問題報告給開發(fā)者。接收到在Beta測試期間報告的問題之后，開發(fā)者對軟件產(chǎn)品進行必要的修改，并準備向全體客戶發(fā)布最終的軟件產(chǎn)品。 l 并行測試 當新開發(fā)的系統(tǒng)是用來替代一個老系統(tǒng)時，常常采用并行測試方法。并行測試方法是將新系統(tǒng)和老系統(tǒng)并行運行，并行測試可以使得用戶能夠逐漸熟悉新系統(tǒng)的使用，可以驗證用戶指南和使用手冊之類的文檔，還能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，可以用測試結(jié)果驗證性能指標。

29、,軟件工程,4. 安裝測試,系統(tǒng)驗收后，就在用戶環(huán)境中進行安裝并測試。在大多數(shù)情況下，安裝測試重復用戶環(huán)境中功能測試和性能測試時執(zhí)行的測試數(shù)據(jù)。如果驗收測試是在目標環(huán)境中進行的，就不需要進行安裝測試。,軟件工程,4.4 測試用例的設計,設計測試方案是測試的首要任務。測試方案包括具體的測試目的（如預定要測試的具體功能）和測試用例(test case)。一個測試用例是用來執(zhí)行被測代碼的系統(tǒng)的一個輸入集合或一個場景。通常又把測試數(shù)據(jù)和預期的輸出結(jié)果稱為測試用例。理想情況下選擇的測試用例，應使這些用例的成功執(zhí)行能保證軟件中無故障。由于窮舉測試用例集是不現(xiàn)實的，我們只能選擇一個能逼近理想情況的測試用例集

30、。,軟件工程,4.4 測試用例的設計,4.4.1 白盒測試法用例的設計 白盒測試法設計用例的指導思想是選擇測試用例集檢驗代碼的內(nèi)部結(jié)構(gòu)是否正確，因此它是在清楚地知道了程序的內(nèi)部結(jié)構(gòu)和處理算法的基礎上進行的測試用例設計。 1. 邏輯覆蓋 所謂邏輯覆蓋是對一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。邏輯覆蓋要求對某些程序的結(jié)構(gòu)特性做到一定程度的覆蓋，或者說是“基于覆蓋的測試”，即有選擇地執(zhí)行程序中某些最有代表性的通路。,軟件工程,1. 邏輯覆蓋,語句覆蓋 語句覆蓋是指使用足夠多的測試數(shù)據(jù)，使被測試程序中每個語句至少執(zhí)行一次。 分支覆蓋 分支覆蓋又叫判定覆蓋，是指設計出足夠多的測

31、試用例，使得被測程序中每個判定表達式都執(zhí)行一次“真”和一次“假”，從而使程序的每一個分支至少都通過一次。 條件覆蓋 條件覆蓋要求不僅每個語句至少執(zhí)行一次，而且使得判定表達式中每個條件的各種可能的值都至少執(zhí)行一次。,軟件工程,1. 邏輯覆蓋,判定-條件覆蓋 判定-條件覆蓋要求設計足夠的測試用例，使得判定表達式中的每個條件的所有可能取值至少出現(xiàn)一次，并使每個判定表達式所有可能的結(jié)果也至少出現(xiàn)一次。 條件組合覆蓋 條件組合覆蓋它要求選取足夠多的測試數(shù)據(jù)，使得每個判定表達式中條件的各種可能組合都至少執(zhí)行一次。 路徑覆蓋 路徑覆蓋就是要求設計足夠多的測試數(shù)據(jù)，可以覆蓋被測程序中所有可能的路徑。,軟件工程

32、,邏輯覆蓋舉例,語句覆蓋的測試用例是： 【A=2，B=0，X=4，A=2，B=0，X=3】 覆蓋sacbed 分支覆蓋的測試用例是： 【A=3，B=0，X=3，A=3，B=0，X=1】 覆蓋sacbd 【A=2，B=1，X=1，A=2，B=1，X=2】 覆蓋sabed 覆蓋的測試用例是： 【A=2，B=0，X=4，A=2，B=0，X=3】 覆蓋sacbed (滿足A1，BO，A2和x1的條件) 【A=1，B=1，X=1，A=1，B=1，X=1】 覆蓋sabd (滿足A1，BO，A2和x1的條件),軟件工程,邏輯覆蓋舉例,判定-條件覆蓋的測試用例是： 【A=2，B=0，X=4，A=2，B=0，X

33、=3】 覆蓋sacbed 【A=1，B=1，X=1，A=1，B=1，X=1】 覆蓋sabd 條件組合覆蓋的測試用例是： 【A=2，B=0，X=4，A=2，B=0，X=3】 覆蓋sacbed (滿足A1，BO，A2和x1的條件) 【A=2，B=1，X=1，A=2，B=1，X=2】 覆蓋sabed (滿足A1，BO，A2和x1的條件) 【A=1，B=0，X=3，A=1，B=0，X=4】 覆蓋sabed (滿足A1，BO，A2和x1的條件) 【A=1，B=1，X=1，A=1，B=1，X=1】 覆蓋sabd (滿足A1，BO，A2和x1的條件),軟件工程,2.基本路徑測試,使用這種技術(shù)設計測試用例時，

34、首先計算程序的環(huán)形復雜度，并用該復雜度為指南定義執(zhí)行路徑的基本集合，從該基本集合導出的測試用例可以保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值?；韭窂綔y試技術(shù)設計測試用例的步驟： 第一步：將詳細設計結(jié)果或程序編碼映射成程序控制結(jié)構(gòu)圖。 第二步：根據(jù)程序控制結(jié)構(gòu)圖計算程序的環(huán)形復雜度。 第三步：確定線性獨立路徑的基本集合。 第四步：設計測試用例，確?；韭窂郊忻織l路徑的執(zhí)行。,軟件工程,4.4.2 黑盒測試法用例的設計,黑盒測試法用例的設計有等價類劃分、邊界值分析、錯誤推測等。根據(jù)這些方法來生成測試用例，可以提前到需求分析階段或設計階段。同時使用這些方法很可能

35、發(fā)現(xiàn)白盒測試不易發(fā)現(xiàn)的其他類型的錯誤。 等價類劃分 等價類劃分的基本思想是將程序的所有可能輸入數(shù)據(jù)(有效與無效的)劃分為若干等價類。當程序輸入數(shù)據(jù)集合的等價類確定以后，從每個等價類任取一組代表值就可以產(chǎn)生一個測試用例。等價類的劃分有兩種不同情況：,軟件工程,等價類劃分,有效等價類：是指對于軟件的需求規(guī)格說明來說，是合理的、有意義的輸入數(shù)據(jù)集合。 無效等價類：是指對于軟件的需求規(guī)格說明來說，是不合理的、無意義的輸入數(shù)據(jù)集合。 利用等價類劃分產(chǎn)生測試用的具體步驟如下： 第一步：劃分等價類。 第二步：設計測試用例。根據(jù)等價類設計測試用例時主要使用下面兩個步驟： 設計一個有效等價類的測試用例。對于各個

36、輸入條件，以盡可能多地覆蓋尚未被覆蓋的有效等價類，重復這一步驟直到所有有效等價類都被覆蓋為止； 設計一個無效等價類的測試用例。使它覆蓋一個而且只覆蓋一個尚未被覆蓋的無效等價類，重復這一步驟直到所有無效等價類都被覆蓋為止。注意因為在輸入中有一個錯誤存在時，往往會屏蔽掉其它錯誤顯示，所以設計無效等價類的測試用例時，一次只覆蓋一個無效等價類。,軟件工程,等價類劃分舉例,例 某城市電話號碼組成規(guī)則是：地區(qū)碼+前綴+后綴。 地區(qū)碼：空白或者3位數(shù)字； 前綴：非0或者1開頭的3位數(shù)字： 后綴：4位數(shù)字。 某程序接受符合以上條件的電話號碼，拒絕所有不符合規(guī)定的號碼。對該程序使用等價類劃分法設計測試用例。 (

37、 略 ),軟件工程,2. 邊界值分析,在等價類劃分中，測試用例從各等價類中任意選取，沒有考慮同一等價類中各組數(shù)據(jù)對于發(fā)現(xiàn)隱藏錯誤的差異。實踐經(jīng)驗證明，程序往往在處理邊界情況時會發(fā)生錯誤。如果將測試值選取在等價類的邊界附近，可以期望得到高效的測試用例，可以查出更多的錯誤和問題。這就是邊界值分析的出發(fā)點。 通常設計測試用例時總是聯(lián)合使用等價類劃分和邊界值分析兩種技術(shù)。一般先采用邊界值分析設計測試用例，再用等價類劃分補充之。,軟件工程,2. 邊界值分析,典型邊界值包括下面一些情況： l如果輸入條件說明了輸入值的范圍，則應該在范圍的邊界上取值；另外還應該剛好越過邊界的值作為無效情況的測試用例。 l如果

38、輸入條件指出了輸入數(shù)據(jù)個數(shù)，則應為最小個數(shù)、最大個數(shù)、低于最小個數(shù)，高于最大個數(shù)分別設計測試用例。 l對于輸出結(jié)果應該作類似于輸入一樣的處理。 l如果程序的輸入輸出數(shù)據(jù)是有序集合，則應該特別注意表中第一個、最后一個元素，以及集合中僅有1個元素的情況。 l對于輸入輸出為線性表的程序，應該考慮輸入輸出有0個、1個和可能的最大元素個數(shù)情況。,軟件工程,3. 錯誤推測,有經(jīng)驗的測試人員往往根據(jù)經(jīng)驗與直覺，推測程序中可能存在的各種錯誤，從而有針對性的編寫檢查這些錯誤的測試用例，實現(xiàn)高效的測試，這就是錯誤推測法。 對于測試對象中可能存在何種類型的錯誤，是挑選測試用例應該考慮的重要因素。推測的重要依據(jù)是程序

39、設計規(guī)格說明書(或者代碼的序言性注釋)，不但要考慮它告訴了我們什么，還應該考慮說明中遺漏了什么，或者是否存在可能的沖突。,軟件工程,測試用例設計小結(jié),在實際應用中通常以黑盒測試法設計測試用例為主，白盒測試法設計測試用例為輔。并可以考慮以下測試策略： l任何情況下都應該使用邊界值分析設計測試用例； l必要時采用等價類劃分法補充用例； l必要時再用錯誤推測法補充用例； l對照程序內(nèi)部邏輯，檢查已設計用例的邏輯覆蓋。根據(jù)程序可靠性要求，補充用例使之達到規(guī)定的邏輯覆蓋要求。,軟件工程,4.5 面向?qū)ο蟮能浖y試,從“小型測試”開始逐步過渡到“大型測試”，這是軟件軟件測試經(jīng)典的策略和經(jīng)典的用例生成技術(shù)。

40、測試面向?qū)ο筌浖牟呗院陀美杉夹g(shù)與上述策略基本相同，但由于面向?qū)ο蟪绦虻奶厥庑再|(zhì)，測試的焦點不是模塊而是對象類，因此必須增加一系列措施和手段，來保證最大限度地發(fā)現(xiàn)軟件中潛在的各種錯誤和缺陷。 通常認為面向?qū)ο蟮男再|(zhì)有助于簡化測試，其實并非如此。,軟件工程,4.5.1 面向?qū)ο蟮臏y試策略,面向?qū)ο蟮臏y試應該針對4個不同的層次：功能、類、聚類（彼此協(xié)作的對象的交互群）和整個系統(tǒng)。在面向?qū)ο蟮拿總€不同測試階段，都有其不同層次的側(cè)重點，如在面向?qū)ο蟮膯卧獪y試中側(cè)重于類層次，面向?qū)ο蟮募蓽y試側(cè)重于聚類，而面向?qū)ο蟮南到y(tǒng)測試則是整個系統(tǒng)。 1. 面向?qū)ο蟮膯卧獪y試 面向?qū)ο蟮膯卧獪y試主要是對每個類進

41、行單元測試。在對對象類進行測試時，可從2個層次來進行：測試與對象關(guān)聯(lián)的單個操作；測試單個對象類。對象關(guān)聯(lián)的單個操作是一些函數(shù)或程序，可以使用白盒測試方法和黑盒測試方法來進行測試。對于單個對象類應該把操作作為類的一部分來測試，不能再孤立地測試單個操作。黑盒測試的原理不變，但等價類劃分這個概念需要擴展以便適合操作序列的情況。劃分測試（partition testing）和基于故障的測試（fault based testing）就是對原概念擴展的方法。,軟件工程,2.面向?qū)ο蟮募蓽y試,由于構(gòu)成類的各個成分彼此間存在直接或間接的交互，一次集成一個操作到類中通常是不現(xiàn)實的。Murphy等認為一組對象類

42、通過組合行為提供一組服務，它們應該一起測試即所謂集群測試（cluster testing）。集群測試使用的測試用例主要是力圖發(fā)現(xiàn)相互協(xié)作的類之間的協(xié)作錯誤。 在面向?qū)ο笙到y(tǒng)的集成測試中通常有2種不同的策略： 基于線程的測試（thread based testing） 基于使用的測試（use based testing）,軟件工程,3.面向?qū)ο蟮南到y(tǒng)測試,在系統(tǒng)測試層次，面向?qū)ο蟮南到y(tǒng)測試集中檢查用戶可見的動作和用戶可識別的輸出，不再考慮類之間相互連接的細節(jié)。系統(tǒng)測試時的用例生成可使用上節(jié)介紹的黑盒測試方法，但是，基于用例或場景的測試是面向?qū)ο笙到y(tǒng)測試的主要方法。 基于用例或場景的測試是根據(jù)用例

43、或場景對系統(tǒng)使用的描述來制定測試用例?；谟美驁鼍暗臏y試通常是最有效的方法，因為它是這樣組織測試過程的，先測試那些最平常的場景，不尋常的或異常的場景故在稍后測試。這樣做符合測試的基本原理，即最大的測試努力應詼用于系統(tǒng)最常用到的部分。此外，測試用例還可以從動態(tài)模型中導出。,軟件工程,4.5.2 面向?qū)ο蟮臏y試用例設計,面向?qū)ο鬁y試關(guān)注于設計合適的操作序列以測試類的狀態(tài)。 Berard提出了面向?qū)ο蟮能浖y試用例設計的整體方法： l 每個測試用例應該被惟一標識，并且和將被測試的類顯式地相關(guān)聯(lián)； 應該陳述測試的目的； 對每個測試應該開發(fā)一組測試步驟，應該包含： 將被測試的對象的一組特定狀態(tài) 將作為

44、測試的結(jié)果使用的一組消息和操作 當測試對象時可能產(chǎn)生的一組例外 一組外部條件，即為了適當?shù)剡M行測試而必須存在的軟件外部環(huán)境的變化 輔助理解或?qū)崿F(xiàn)測試的補充消息,軟件工程,1.類的測試方法,對面向?qū)ο蟮能浖碚f，單元測試著重測試單個類和類中封裝的方法。測試單個類的方法主要有隨機測試、劃分測試和基于故障的測試等3種。 l 隨機測試 l 劃分測試 劃分測試（partition testing）可以減少測試類時所需要的測試用例的數(shù)量，它是等價類劃分法思想的擴展。首先，把輸入和輸出分類，然后設計測試用例以測試劃分出的每個類別。劃分類別的3種方法： （1） 基于狀態(tài)的劃分 （2） 基于屬性的劃分 （3）

45、基于類操作的劃分,軟件工程,1.類的測試方法,l 基于故障的測試 基于故障的測試（fault based testing）就是設計最有可能發(fā)現(xiàn)故障的測試用例來進行測試，它是錯誤推測法思想在面向?qū)ο鬁y試中的應用。首先，推測軟件中可能有的錯誤，然后設計出最可能發(fā)現(xiàn)這些錯誤的測試用例。,軟件工程,2 類間測試方法,當面向?qū)ο蟮南到y(tǒng)開始集成時，測試用例的設計變得更加復雜。在這個測試階段，必須對類間協(xié)作進行測試。和測試單個類相似，測試類協(xié)作可以使用隨機測試方法和劃分測試方法，以及基于情景的測試和行為測試來完成。 類的動態(tài)行為可以用狀態(tài)轉(zhuǎn)換圖來表達。利用類的狀態(tài)圖可以幫助我們導出測試該類（及與其協(xié)作的那些

46、類）的動態(tài)行為的測試用例。在遍歷狀態(tài)模型時，可以按“深度優(yōu)先的方式”和“寬度優(yōu)先的方式”。在類的行為導致與一個或多個類協(xié)作的情況下，應該使用多個狀態(tài)圖去跟蹤系統(tǒng)的行為流。,軟件工程,4.6 軟件調(diào)試,調(diào)試(debug)又稱排錯或糾錯。調(diào)試的任務就是根據(jù)測試時所發(fā)現(xiàn)的錯誤，找出原因和具體的位置，進行改正。準確的說，調(diào)試工作包括：對錯誤進行定位并分析原因，即診斷；對于錯誤部分重新編碼以改正錯誤；重新測試。調(diào)試工作的重點是診斷，通常診斷約占調(diào)試工作量的90以上。 軟件測試應該由他人進行，調(diào)試工作主要由程序開發(fā)人員來進行，誰開發(fā)的程序就由誰來進行調(diào)試。 調(diào)試是一件很困難的工作，之所以困難，是由于人的心

47、理因素以及技術(shù)方面的原因而致，其中心理方面的原因可能多于技術(shù)方面的原因。,軟件工程,4.6.1 調(diào)試原則,1.診斷原則 用頭腦去分析思考與錯誤征兆有關(guān)的信息。 避開死胡同。 只把調(diào)試工具當做輔助手段來使用。 避免用猜測或試探的辦法，最多只能把它當作最后手段。 2.修改原則 修改錯誤前一定要仔細考慮。 在出現(xiàn)錯誤的地方，很可能還有別的錯誤。 修改錯誤的一個常見失誤是只修改了這個錯誤的征兆或這個錯誤的表現(xiàn)，而沒有修改錯誤的本質(zhì)。 當心修正一個錯誤的同時有可能會引入新的錯誤。 修改錯誤的過程將迫使人們暫時回到程序設計階段。 修改源代碼程序，不要改變目標代碼。,軟件工程,4.6.2 調(diào)試步驟,調(diào)試的步

48、驟如下： 調(diào)試過程從執(zhí)行一個測試用例開始，然后從錯誤的外部表現(xiàn)形式入手，確定程序中出錯位置； 研究有關(guān)部分的程序，找出錯誤的內(nèi)在原因； 修改設計和代碼，以排除這個錯誤； 重復進行暴露了這個錯誤的原始測試或某些有關(guān)測試，以確認： 1) 是否排除了該錯誤；2) 是否引進了新的錯誤。 如果所做的修正無效，則撤消這次改動，恢復程序修改之前的狀態(tài)。重復上述過程，直到找到一個有效的解決辦法為止。,軟件工程,4.6.3 調(diào)試方法,目前常用的調(diào)試方法有如下幾種： 1.試探法:試探法又稱蠻干法。該方法一般由調(diào)試人員分析錯誤的癥狀，猜測問題的所在位置，利用在程序中設置輸出語句，分析寄存器、存儲器的內(nèi)容等手段來獲得

49、錯誤的線索，一步步地試探和分析出錯誤所在。該方法的排錯能力主要依賴于調(diào)試人員的經(jīng)驗、直覺和運氣。 2.回溯法：調(diào)試人員從發(fā)現(xiàn)錯誤癥狀的位置開始，人工沿著程序的控制流程往回跟蹤程序代碼，直到找出錯誤根源為止。這是一種適合于小型程序排錯的有效方法，對于大規(guī)模程序，由于其需要回溯的路徑太多而變得不可操作。,軟件工程,4.6.3 調(diào)試方法,3.對分查找法：對分查找法的基本思路是，如果已經(jīng)知道每個變量在程序內(nèi)若干個關(guān)鍵點的正確值，則可以用賦值語句或輸入語句在程序中點附近“注入”這些變量的正確值，然后運行程序并檢查所得到的輸出。如果輸出結(jié)果是正確的，則錯誤原因在程序的前半部分；反之，錯誤原因在程序的后半部

50、分。對錯誤原因所在的那部分再重復使用這個方法，直到把出錯范圍縮小到容易診斷的程度為止。 4.歸納法：歸納法是一種從特殊推斷一般的系統(tǒng)化思考方法。歸納法排錯的基本思想是：從一些錯誤征兆的線索著手，通過分析它們之間的關(guān)系來找出錯誤。它一般從測試所暴露的問題出發(fā)，收集所有正確或不正確的數(shù)據(jù)，分析它們之間的關(guān)系，提出假想的錯誤原因，用這些數(shù)據(jù)來證明或反駁，從而查出錯誤所在。,軟件工程,4.6.3 調(diào)試方法,5.演繹法：演繹法是一種從一般原理或前提出發(fā)，經(jīng)過排除和精化的過程來推導出結(jié)論的思考方法。演繹法排錯是測試人員根據(jù)測試結(jié)果，列出所有可能的錯誤原因。分析已有的數(shù)據(jù)，排除不可能和彼此矛盾的原因。對余下

51、的原因，選擇可能性最大的，利用已有的數(shù)據(jù)完善該假設，使假設更具體。用假設來解釋所有的原始測試結(jié)果，如果能解釋這一切，則假設得以證實，也就找出錯誤；否則，要么是假設不完備或不成立，要么有多個錯誤同時存在，需要重新分析，提出新的假設，直到發(fā)現(xiàn)錯誤為止。 對分查找法、歸納法和演繹法都是對錯誤發(fā)生有關(guān)的數(shù)據(jù)進行分析，來尋找到潛在的原因，因此它們都屬于原因排除法。,軟件工程,4.7 軟件可靠性,4.7.1 軟件可靠性概念 1.軟件可靠性定義 軟件可靠性是軟件在給定的時間間隔內(nèi)及給定的環(huán)境條件下，按照規(guī)格說明書的規(guī)定成功地運行的概率。定義中“時間間隔”是一個隨機變量，它隨運行時間的增加，程序運行中出現(xiàn)故障

52、的概率也增大。定義中的“成功地運行”，是指不僅程序能正確地運行，滿足用戶對它的功能要求，而且當程序一旦受到意外的傷害，或系統(tǒng)錯誤時，能盡快恢復，仍能正常地運行。,軟件工程,4.7.1 軟件可靠性概念,2. 軟件可靠性的主要指標 平均無故障時間MTTF(Mean Time To Failure)和平均故障間隔時間MTBF(Mean Time Between Failures)。 假設某軟件系統(tǒng)運行時發(fā)生了n+1次故障，每兩次故障之間所經(jīng)歷的時間間隔為t1，t2，t3，tn。那么這n個時間段的平均值就是平均無故障時間。即： MTTF=(t1t2t3tn)/n 平均故障間隔時間MTBF是指兩次相繼故

53、障之間的平均時間。平均修復時間(MTTR)描述的是修復一個軟件缺陷所花費的平均時間，將平均無故障時間和平均修復時間加起來，就是每兩次故障之間的平均時間。,軟件工程,4.7.2 軟件測試中可靠性分析,1.估算平均無故障時間MTTF 平均無故障時間MTTF通常是通過Shooman模型來估算。Shooman模型MTTF估算公式是： MTTF=1/K(ET/IT-Ec()/IT) 其中，K是一個經(jīng)驗常數(shù)，它的值應該根據(jù)經(jīng)驗選取(美國的一些統(tǒng)計數(shù)字表明，K的典型值是200)。ET是測試之前程序中原有或固有的錯誤總數(shù)，IT是程序長度(機器指令條數(shù)或簡單匯編語句條數(shù))，是測試(包括排錯)的時間，Ec()是在

54、Ot期間內(nèi)檢出并排除的錯誤總數(shù)。 測試時根據(jù)發(fā)現(xiàn)和改正錯誤的個數(shù)，利用MTTF=1/Kr()式，其中r()=ET/IT -Ec()/IT可以計算出平均無故障時間MTTF。 利用Ec= ET - IT /(KMTTF)式，可以根據(jù)軟件規(guī)格說明對軟件平均無故障時間MTTF的要求，估計需要改正多少個錯誤之后，測試工作可以停止，以此來評價軟件測試的進展情況。,軟件工程,2.估算軟件中錯誤總數(shù),估計ET的兩種方法： 植入錯誤法 這種估算法的主要思想是：假設測試時使用測試用例發(fā)現(xiàn)植入錯誤和固有錯誤的概率相同。因此，在測試之前由專人在程序中隨機地植入一些錯誤，測試之后，根據(jù)測試小組發(fā)現(xiàn)的錯誤中原有的和植入的

55、兩種錯誤的比例，來估計程序中原有錯誤的總數(shù)ET。 若設Ns是測試之前人為地植入的錯誤數(shù),經(jīng)過一段時間的測試之后發(fā)現(xiàn)s個植入的錯誤，此外還發(fā)現(xiàn)了個程序固有的錯誤數(shù)。如果認為測試用例發(fā)現(xiàn)植入錯誤和發(fā)現(xiàn)固有錯誤的能力相同，則能夠估計出程序中原有錯誤的總數(shù)為： =Ns /s 上式中即是錯誤總數(shù)ET的估計值。所以在測試結(jié)束時，程序中殘存的固有錯誤數(shù)為：-個。,軟件工程,2.估算軟件中錯誤總數(shù),分別測試法 分別測試法使用兩個測試員（或測試小組）同時互相獨立地測試同一程序的兩個副本。具體做法是，在測試過程的早期階段，由測試員甲和測試員乙分別測試同一個程序的兩個副本，另一名分析員分析他們的測試結(jié)果。用表示測試

56、時間，假設： =0時錯誤總數(shù)為B0； =1時測試員甲發(fā)現(xiàn)的錯誤數(shù)為B1； =1時測試員乙發(fā)現(xiàn)的錯誤數(shù)為B2； =1時兩個測試員發(fā)現(xiàn)的相同錯誤數(shù)為bc。 如果把測試員甲發(fā)現(xiàn)的錯誤作為植入錯誤，即程序中植入錯誤的總數(shù)為B1,則測試員乙發(fā)現(xiàn)的B2個錯誤中有bc個相當于是植入錯誤。假定測試員乙發(fā)現(xiàn)各種錯誤的概率相同，則可以估計出測試前程序中的錯誤總數(shù)為：,軟件工程,分別測試法,B0= B1B2/bc 使用分別測試法，在測試階段的早期，分析員每隔一段時間分析兩名測試員的測試結(jié)果，并且用上式計算B0。如果幾次估算的結(jié)果相差很多，還需要繼續(xù)估算B0，直到幾次估算的結(jié)果相差不多，則可用B0的平均值作為ET的估

57、計值。此后一名測試員可以改做其他工作，余下的一名測試員繼續(xù)完成剩余的測試工作，因為他可以繼承另一名測試員的測試結(jié)果，所以分別測試法增加的測試成本并不太多。,軟件工程,4.8 軟件測試CASE工具,通過應用測試工具可以提高測試質(zhì)量和測試效率，這是測試工具的價值所在。軟件測試工具的開發(fā)較之于其他CASE工具的開發(fā)，難度最大。這是由于適用于所有軟件系統(tǒng)的測試工具是不存在的。一般來說，軟件測試工具至少應滿足下列基本功能： (1)測試工具能夠根據(jù)特定的度量標準度量軟件的若干質(zhì)量指標。 (2)查找并定位軟件中所包括的錯誤并進行提示(不少工具要求有自動修正功能)。 (3)成測試報告。 作為軟件測試工具其構(gòu)成

58、至少包括5方面的要素：,軟件工程,4.8 軟件測試CASE工具,(1)用戶接口：最好采用基于GUI的界面方式，通過統(tǒng)一的交互式用戶接口以協(xié)調(diào)其他各子系統(tǒng)的工作。 (2)系統(tǒng)配置管理子系統(tǒng)：對評測系統(tǒng)的系統(tǒng)參數(shù)進行管理，通過修改這些參數(shù)可以重新配置評測系統(tǒng)和對軟件進行不同驗收標準的測試。 (3)軟件評價方法編輯子系統(tǒng)：可以編輯對語言描述進行評價的方法。該系統(tǒng)可進行詞法分析、語法分析和錯誤檢查，從而形成軟件評價方法的內(nèi)部表現(xiàn)形式，并將其存放于軟件評測方法庫中。 (4)軟件評測子系統(tǒng)：對被評測軟件進行分析和測試，通過調(diào)用軟件評測方法庫中的方法和評測標準對被評測軟件進行評測。軟件評測子系統(tǒng)應該既可采用人機交互的方式進行評測，又可采用自動方式進行評測并將軟件評測數(shù)據(jù)放入評測數(shù)據(jù)庫中。 (5)評測報告生成子系統(tǒng)：創(chuàng)建、編輯評測報告的模板，放入評測報告模板庫中，用戶可以根據(jù)具體模板生成符合特定需要的測試報告。,軟件工程,4.8.1 軟件測試工具分類,測試工具一般可分為白盒測試工具、黑盒測試工具、性能測試工具，另外還有用于測試管理(測試流程管理、缺陷跟蹤