軟件工程課件：第7章實現(xiàn)

1、第7章 實現(xiàn)7.1 編碼7.2 軟件測試基礎(chǔ)7.3 單元測試7.4 集成測試7.5 確認測試7.6 白盒測試技術(shù)7.7 黑盒測試技術(shù)7.8 調(diào)試7.9 軟件可靠性 “實現(xiàn)”: 編碼和測試。所謂編碼就是把軟件設(shè)計結(jié)果翻譯成用某種程序設(shè)計語言書寫的程序。程序的質(zhì)量主要取決于？ ：設(shè)計的質(zhì)量。 但是，所選用的程序設(shè)計語言的特點及編碼風格也將對程序的可靠性、可讀性、可測試性和可維護性產(chǎn)生深遠的影響。 測試的目的: 在軟件投入生產(chǎn)性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。無論怎樣強調(diào)軟件測試的重要性和它對軟件可靠性的影響都不過分。我們力求在每個階段結(jié)束之前通過嚴格的技術(shù)審查，盡可能早地發(fā)現(xiàn)并糾正差錯，但是

2、在軟件生命周期的每個階段都不可避免地會產(chǎn)生差錯:審查不能發(fā)現(xiàn)所有差錯編碼過程中還會引入新的錯誤目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟，它是對軟件規(guī)格說明、設(shè)計和編碼的最后復(fù)審。軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(jié)束之后，對軟件系統(tǒng)還應(yīng)該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔這項工作。大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40%以上，在極端情況，測試那種關(guān)系人的生命安全的軟件所花費的成

3、本，可能相當于軟件工程其他開發(fā)步驟總成本的3倍到5倍。因此，必須高度重視軟件測試工作，絕不要以為寫出程序之后軟件開發(fā)工作就接近完成了，實際上，大約還有同樣多的開發(fā)工作量需要完成。僅就測試而言，它的目標是發(fā)現(xiàn)軟件中的錯誤，但是，發(fā)現(xiàn)錯誤并不是最終目的。軟件工程的根本目標是開發(fā)出高質(zhì)量的完全符合用戶需要的軟件，因此，通過測試發(fā)現(xiàn)錯誤之后還必須診斷并改正錯誤，這就是調(diào)試的目的。 調(diào)試是測試階段最困難的工作程序設(shè)計語言是人和計算機通信的最基本的工具，它的特點必然會影響人的思維和解題方式，會影響人和計算機通信的方式和質(zhì)量，也會影響其他人閱讀和理解程序的難易程度。因此，編碼之前的一項重要工作就是選擇一種適

4、當?shù)某绦蛟O(shè)計語言。7.1 編碼 7.1.1 選擇程序設(shè)計語言由于軟件系統(tǒng)的絕大部分成本用在生命周期的測試和維護階段，所以容易測試和容易維護是極端重要的。如何選擇適宜的程序設(shè)計語言：根據(jù)設(shè)計去完成編碼時困難最少可以減少程序測試量程序更容易閱讀程序更容易維護總的說來，高級語言明顯優(yōu)于匯編語言，因此，除了一些特殊情況，都應(yīng)該用高級語言書寫。特殊情況包括：特殊的應(yīng)用領(lǐng)域：對程序執(zhí)行時間和使用的空間都有很嚴格限制的情況；需要產(chǎn)生任意的甚至非法的指令序列；體系結(jié)構(gòu)特殊的微處理機，以致在這類機器上通常不能實現(xiàn)高級語言編譯程序。大型系統(tǒng)中執(zhí)行時間非常關(guān)鍵的(或直接依賴于硬件的)一些代碼需要用匯編語言書寫。所選

5、用的高級語言應(yīng)該具有的特點：具有理想的模塊化機制具有可讀性好的控制結(jié)構(gòu)和數(shù)據(jù)結(jié)構(gòu)編譯程序應(yīng)該能夠盡可能多地發(fā)現(xiàn)程序中的錯誤應(yīng)該有良好的獨立編譯機制一些與應(yīng)用有關(guān)的考慮：(1) 用戶的要求。如果所開發(fā)的系統(tǒng)由用戶負責維護，用戶通常要求用他們熟悉的語言書寫程序。(2) 可以使用的編譯程序。運行目標系統(tǒng)的環(huán)境中可以提供的編譯程序限制了可選用語言的范圍。(3) 可以得到的軟件工具。如果某種語言有支持程序開發(fā)的軟件工具可以利用，則目標系統(tǒng)的實現(xiàn)和驗證都變得比較容易。(4) 工程規(guī)模。如果工程規(guī)模很龐大，現(xiàn)有的語言又不完全適用，那么設(shè)計并實現(xiàn)一種供這個工程項目專用的程序設(shè)計語言，可能是一個正確的選擇。(5

6、) 程序員的知識。雖然對于有經(jīng)驗的程序員來說，學習一種新語言并不困難，但是要完全掌握一種新語言卻需要實踐。如果和其他標準不矛盾，那么應(yīng)該選擇一種已經(jīng)為程序員所熟悉的語言。(6) 軟件可移植性要求。如果目標系統(tǒng)將在幾臺不同的計算機上運行，或者預(yù)期的使用壽命很長，那么選擇一種標準化程度高、程序可移植性好的語言就是很重要的。(7) 軟件的應(yīng)用領(lǐng)域。所謂的通用程序設(shè)計語言實際上并不是對所有應(yīng)用領(lǐng)域都同樣適用。因此，選擇語言時應(yīng)該充分考慮目標系統(tǒng)的應(yīng)用范圍。源程序代碼的邏輯簡明清晰、易讀易懂是好程序的一個重要標準，為了做到這一點，應(yīng)該遵循下述規(guī)則。1. 程序內(nèi)部的文檔程序內(nèi)部的文檔包括：恰當?shù)臉俗R符、適

7、當?shù)淖⒔夂统绦虻囊曈X組織等等。選取含義鮮明的名字，使它能正確地提示程序?qū)ο笏淼膶嶓w，這對于幫助閱讀者理解程序是很重要的。如果使用縮寫，那么縮寫規(guī)則應(yīng)該一致，并且應(yīng)該給每個名字加注解。7.1.2 編碼風格 注解是程序員和程序讀者通信的重要手段，正確的注解非常有助于對程序的理解。 通常在每個模塊開始處有一段序言性的注解，簡要描述模塊的功能、主要算法、接口特點、重要數(shù)據(jù)以及開發(fā)簡史。 插在程序中間與一段程序代碼有關(guān)的注解，主要解釋包含這段代碼的必要性。 對于高級語言書寫的源程序，不需要用注解的形式把每個語句翻譯成自然語言，應(yīng)該利用注解提供一些額外的信息。 應(yīng)該用空格或空行清楚地區(qū)分注解和程序。

8、程序清單的布局對于程序的可讀性也有很大影響，應(yīng)該利用適當?shù)碾A梯形式使程序的層次結(jié)構(gòu)清晰明顯。function varargout = HSBP1(varargin)% HSBP1 MATLAB code for HSBP1.fig% HSBP1, by itself, creates a new HSBP1 or raises the existing singleton*.% H = HSBP1 returns the handle to a new HSBP1 or the handle to the existing singleton*.% HSBP1(CALLBACK,hObject

9、,eventData,handles,.) calls the local% function named CALLBACK in HSBP1.M with the given input arguments.% HSBP1(Property,Value,.) creates a new HSBP1 or raises the% existing singleton. All inputs are passed to HSBP1_OpeningFcn via varargin.% Last Modified by GUIDE v2.5 27-Mar-2015 23:16:23gui_Singl

10、eton = 1;if nargout varargout1:nargout = gui_mainfcn(gui_State, varargin:); if nargin & ischar(varargin1) gui_State.gui_Callback = str2func(varargin1); view(net) % 顯示出net的結(jié)構(gòu)圖 end else gui_mainfcn(gui_State, varargin:);end% End initialization code - DO NOT EDIT2. 數(shù)據(jù)說明數(shù)據(jù)說明的次序應(yīng)該標準化。有次序就容易查閱，因此能夠加速測試、調(diào)試

11、和維護的過程。當多個變量名在一個語句中說明時，應(yīng)該按字母順序排列這些變量。如果設(shè)計時使用了一個復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，則應(yīng)該用注解說明用程序設(shè)計語言實現(xiàn)這個數(shù)據(jù)結(jié)構(gòu)的方法和特點。3. 語句構(gòu)造構(gòu)造語句時應(yīng)該遵循的原則是，每個語句都應(yīng)該簡單而直接，不能為了提高效率而使程序變得過分復(fù)雜。下述規(guī)則有助于使語句簡單明了：不要為了節(jié)省空間而把多個語句寫在同一行； X=a+b: Y=c+d:Z=X+Y盡量避免復(fù)雜的條件測試； If (x =y-z+2*a/c) or (x+z a*y-sin(c ) or (xz)盡量減少對“非”條件的測試； If not(x=0) 避免大量使用循環(huán)嵌套和條件嵌套；利用括號使邏輯

12、表達式或算術(shù)表達式的運算次序清晰直觀。4. 輸入輸出在設(shè)計和編寫程序時應(yīng)該考慮下述有關(guān)輸入輸出風格的規(guī)則：對所有輸入數(shù)據(jù)都進行檢驗；檢查輸入項重要組合的合法性；保持輸入格式簡單；使用數(shù)據(jù)結(jié)束標記，不要要求用戶指定數(shù)據(jù)的數(shù)目；明確提示交互式輸入的請求，詳細說明可用的選擇或邊界數(shù)值；設(shè)計良好的輸出報表。5. 效率效率主要指處理機時間和存儲器容量兩個方面。三條原則：（1）效率是性能要求，因此應(yīng)該在需求分析階段確定效率方面的要求。軟件應(yīng)該像對它要求的那樣有效，而不應(yīng)該如同人類可能做到的那樣有效。（2）效率是靠好的設(shè)計來提高的。（3）程序的效率和程序的簡單程度是一致的，不要犧牲程序的清晰性和可讀性來不必

13、要地提高效率。(1) 程序運行時間源程序的效率直接由詳細設(shè)計階段確定的算法的效率決定，但是，寫程序的風格也能對程序的執(zhí)行速度和存儲器要求產(chǎn)生影響?？梢詰?yīng)用下述規(guī)則：寫程序之前先簡化算術(shù)的和邏輯的表達式；仔細研究嵌套的循環(huán)，以確定是否有語句可以從內(nèi)層往外移；盡量避免使用多維數(shù)組；盡量避免使用指針和復(fù)雜的表；使用執(zhí)行時間短的算術(shù)運算；不要混合使用不同的數(shù)據(jù)類型；盡量使用整數(shù)運算和布爾表達式。在效率是決定性因素的應(yīng)用領(lǐng)域，盡量使用有良好優(yōu)化特性的編譯程序，以生成高效目標代碼。(2) 存儲器效率在大型計算機中必須考慮操作系統(tǒng)頁式調(diào)度的特點，一般說來，使用能保持功能域的結(jié)構(gòu)化控制結(jié)構(gòu)，是提高效率的好方法

14、。在微處理機中如果要求使用最少的存儲單元，則應(yīng)選用有緊縮存儲器特性的編譯程序，在非常必要時可以使用匯編語言。提高執(zhí)行效率的技術(shù)通常也能提高存儲器效率。提高存儲器效率的關(guān)鍵同樣是“簡單”。(3) 輸入輸出的效率簡單清晰同樣是提高人機通信效率的關(guān)鍵。硬件之間的通信效率是很復(fù)雜的問題，但是，從寫程序的角度看，卻有些簡單的原則可以提高輸入輸出的效率。例如：所有輸入輸出都應(yīng)該有緩沖，以減少用于通信的額外開銷；對二級存儲器(如磁盤)應(yīng)選用最簡單的訪問方法；二級存儲器的輸入輸出應(yīng)該以組為單位進行；如果“超高效的”輸入輸出很難被人理解，則不應(yīng)采用這種方法。軟件編程規(guī)范表面看來，軟件測試的目的與軟件工程所有其他

15、階段的目的都相反。軟件工程的其他階段都是“建設(shè)性”的：軟件工程師力圖從抽象的概念出發(fā)，逐步設(shè)計出具體的軟件系統(tǒng)，直到用一種適當?shù)某绦蛟O(shè)計語言寫出可以執(zhí)行的程序代碼。但是，在測試階段測試人員努力設(shè)計出一系列測試方案，目的卻是為了“破壞”已經(jīng)建造好的軟件系統(tǒng)竭力證明程序中有錯誤不能按照預(yù)定要求正確工作。7.2 軟件測試基礎(chǔ)測試的目標:(1) 測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程；(2) 好的測試方案是極可能發(fā)現(xiàn)迄今為止尚未發(fā)現(xiàn)的錯誤的測試方案；(3) 成功的測試是發(fā)現(xiàn)了至今為止尚未發(fā)現(xiàn)的錯誤的測試。7.2.1 軟件測試的目標從上述規(guī)則可以看出，測試的正確定義是“為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序

16、的過程”。這和某些人通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”等等是完全相反的。正確認識測試的目標是十分重要的，測試目標決定了測試方案的設(shè)計。如果為了表明程序是正確的而進行測試，就會設(shè)計一些不易暴露錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設(shè)計出最能暴露錯誤的測試方案。由于測試的目標是暴露程序中的錯誤，從心理學角度看，由程序的編寫者自己進行測試是不恰當?shù)?。因此，在綜合測試階段通常由其他人員組成測試小組來完成測試工作。此外，應(yīng)該認識到測試決不能證明程序是正確的。即使經(jīng)過了最嚴格的測試之后，仍然可能還有沒被發(fā)現(xiàn)的錯誤潛藏在程序中。測試只能查找出

17、程序中的錯誤，不能證明程序中沒有錯誤。為了能設(shè)計出有效的測試方案，軟件工程師必須深入理解并正確運用指導(dǎo)軟件測試的基本準則。下面講述主要的測試準則。（1） 所有測試都應(yīng)該能追溯到用戶需求。正如上一小節(jié)講過的，軟件測試的目標是發(fā)現(xiàn)錯誤。從用戶的角度看，最嚴重的錯誤是導(dǎo)致程序不能滿足用戶需求的那些錯誤。7.2.2 軟件測試準則（2） 應(yīng)該遠在測試開始之前就制定出測試計劃。實際上，一旦完成了需求模型就可以著手制定測試計劃，在建立了設(shè)計模型之后就可以立即開始設(shè)計詳細的測試方案。因此，在編碼之前就可以對所有測試工作進行計劃和設(shè)計。（3） 測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。當然，問

18、題是怎樣找出這些可疑的模塊并徹底地測試它們。（4） 應(yīng)該從“小規(guī)模”測試開始，并逐步進行“大規(guī)?！睖y試。通常，首先重點測試單個程序模塊，然后把測試重點轉(zhuǎn)向在集成的模塊簇中尋找錯誤，最后在整個系統(tǒng)中尋找錯誤。（5） 窮舉測試是不可能的。所謂窮舉測試就是把程序所有可能的執(zhí)行路徑都檢查一遍的測試。即使是一個中等規(guī)模的程序，其執(zhí)行路徑的排列數(shù)也十分龐大，由于受時間、人力和資源的限制，在測試過程中不可能執(zhí)行每個可能的路徑。因此，測試只能證明程序中有錯誤，不能證明程序中沒有錯誤。但是，精心地設(shè)計測試方案，有可能充分覆蓋程序邏輯并使程序達到所要求的可靠性。（6） 為了達到最佳的測試效果，應(yīng)該由獨立的第三方從

19、事測試工作。所謂“最佳效果”是指有最大可能性發(fā)現(xiàn)錯誤的測試。由于前面已經(jīng)講過的原因，開發(fā)軟件的軟件工程師并不是完成全部測試工作的最佳人選（通常他們主要承擔模塊測試工作）。測試有兩種方法。黑盒測試：如果已經(jīng)知道了產(chǎn)品應(yīng)該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用。又稱為功能測試。黑盒測試法把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程，是在程序接口進行的測試。它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)亟邮蛰斎霐?shù)據(jù)并產(chǎn)生正確的輸出信息，程序運行過程中能否保持外部信息的完整性。7.2.3 測試方法白盒測試：如果知道產(chǎn)品的內(nèi)部工作過程，可以通過測試來檢驗

20、產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行。白盒測試又稱為結(jié)構(gòu)測試。白盒測試法與黑盒測試法相反，它的前提是可以把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結(jié)構(gòu)和處理算法。這種方法按照程序內(nèi)部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預(yù)定要求正確工作。除非是測試一個小程序，否則一開始就把整個系統(tǒng)作為一個單獨的實體來測試是不現(xiàn)實的。測試過程也必須分步驟進行，后一個步驟在邏輯上是前一個步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個子系統(tǒng)組成，每個子系統(tǒng)又由許多模塊組成，因此，大型軟件系統(tǒng)的測試過程基本上由下述幾個步驟組成。7.2.4 測試步驟1. 模塊測試在設(shè)計得好的軟件系統(tǒng)中，每個模塊完

21、成一個清晰定義的子功能，而且這個子功能和同級其他模塊的功能之間沒有相互依賴關(guān)系。因此，有可能把每個模塊作為一個單獨的實體來測試，而且通常比較容易設(shè)計檢驗?zāi)K正確性的測試方案。模塊測試的目的: 保證每個模塊作為一個單元能正確運行，所以模塊測試通常又稱為單元測試。在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細設(shè)計的錯誤。2. 子系統(tǒng)測試子系統(tǒng)測試是把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是這個測試過程中的主要問題，因此，這個步驟著重測試模塊的接口。3. 系統(tǒng)測試系統(tǒng)測試是把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。在這個過程中不僅應(yīng)該發(fā)現(xiàn)設(shè)計和編碼的錯誤，還應(yīng)該發(fā)現(xiàn)軟件

22、設(shè)計中的錯誤、需求說明中的錯誤。子系統(tǒng)測試和系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。4. 驗收測試驗收測試把軟件系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但是它是在用戶積極參與下進行的，而且可能主要使用實際數(shù)據(jù)(系統(tǒng)將來要處理的信息)進行測試。驗收測試的目的是驗證系統(tǒng)確實能夠滿足用戶的需要，在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。驗收測試也稱為確認測試。5. 平行運行關(guān)系重大的軟件產(chǎn)品在驗收之后往往并不立即投入生產(chǎn)性運行，而要再經(jīng)過一段平行運行時間的考驗。平行運行就是同時運行新開發(fā)的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結(jié)果。這樣做的目的有

23、如下幾點：(1) 可以在準生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風險；(2) 用戶能有一段熟悉新系統(tǒng)的時間；(3) 可以驗證用戶指南和使用手冊之類的文檔；(4) 能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，可以用測試結(jié)果驗證性能指標。軟件配置：需求說明書、設(shè)計說明書、源程序清單、測試配置、測試的實際結(jié)果和調(diào)試記錄。測試配置：測試計劃和測試方案。測試方案：具體的測試目的（例如，要測試的具體功能），應(yīng)該輸入的測試數(shù)據(jù)和預(yù)期的結(jié)果。測試用例：測試數(shù)據(jù)和預(yù)期的輸出結(jié)果。7.2.5 測試階段的信息流測試之前的準備圖7.1 測試階段的信息流比較測試得出的實際結(jié)果和預(yù)期的結(jié)果，如果兩者不一致則很可能是程序中有錯誤。設(shè)法確

24、定錯誤的準確位置并且改正它，這就是調(diào)試的任務(wù)。與測試不同，通常由程序的編寫者負責調(diào)試。如果經(jīng)常出現(xiàn)要求修改設(shè)計的嚴重錯誤，那么軟件的質(zhì)量和可靠性是值得懷疑的，應(yīng)該仔細測試。如果經(jīng)過測試，一個錯誤也沒有被發(fā)現(xiàn)，則很可能是因為對測試配置思考不充分，以致不能暴露軟件中潛藏的錯誤。這些錯誤最終將被用戶發(fā)現(xiàn)，而且需要在維護階段改正它們(但是改正同一個錯誤需要付出的代價比在開發(fā)階段高出許多倍)。如果看起來軟件功能完成得很正常，遇到的錯誤也很容易改正，有兩種可能： (1)軟件的可靠性是可以接受的； (2)所進行的測試尚不足以發(fā)現(xiàn)嚴重的錯誤。單元測試集中檢測軟件設(shè)計的最小單元模塊。通常，單元測試和編碼屬于軟件

25、過程的同一個階段。在編寫出源程序代碼并通過了編譯程序的語法檢查之后，就可以用詳細設(shè)計描述作指南，對重要的執(zhí)行通路進行測試，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。通常，單元測試主要使用白盒測試技術(shù)，而且對多個模塊的測試可以并行地進行。7.3 單元測試1. 模塊接口首先應(yīng)該對通過模塊接口的數(shù)據(jù)流進行測試，如果數(shù)據(jù)不能正確地進出，所有其他測試都是不切實際的。對模塊接口進行測試時主要檢查下述幾個方面：參數(shù)的數(shù)目、次序、屬性等；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。7.3.1 單元測試的重點2. 局部數(shù)據(jù)結(jié)構(gòu)對于模塊來說，局部數(shù)據(jù)結(jié)構(gòu)是常見的錯誤來源。應(yīng)該仔細設(shè)計測試方案，以便發(fā)現(xiàn)局部

26、數(shù)據(jù)說明、初始化、默認值等方面的錯誤。3. 重要的執(zhí)行通路由于通常不可能進行窮盡測試，因此，在單元測試期間選擇最有代表性、最可能發(fā)現(xiàn)錯誤的執(zhí)行通路進行測試就是十分關(guān)鍵的。4. 出錯處理通路應(yīng)該能預(yù)見出現(xiàn)錯誤的條件，并且設(shè)置適當?shù)奶幚礤e誤的通路。應(yīng)該著重測試下述一些可能發(fā)生的錯誤：(1) 對錯誤的描述是難以理解的；(2) 記下的錯誤與實際遇到的錯誤不同；(3) 在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)干預(yù)；(4) 對錯誤的處理不正確；(5) 描述錯誤的信息不足以幫助確定造成錯誤的位置。5. 邊界條件軟件常常在它的邊界上失效，例如，處理n元數(shù)組的第n個元素時，或做到i次循環(huán)中的第i次重復(fù)時，往往

27、會發(fā)生錯誤。因此，邊界測試是單元測試中最后的也可能是最重要的任務(wù)。使用剛好小于、剛好等于和剛好大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制量和數(shù)據(jù)值的測試方案，非?？赡馨l(fā)現(xiàn)軟件中的錯誤。人工測試源程序可以由編寫者本人非正式地進行，也可以由審查小組正式進行。后者稱為代碼審查。審查小組最好由下述4人組成：(1) 組長，應(yīng)該是一個很有能力的程序員，而且沒有直接參與這項工程；(2) 程序的設(shè)計者；(3) 程序的編寫者；(4) 程序的測試者。7.3.2 代碼審查審查之前，小組成員應(yīng)該先研究設(shè)計說明書，力求理解這個設(shè)計。為了幫助理解，可以先由設(shè)計者扼要地介紹他的設(shè)計。在審查會上由程序的編寫者解釋他是怎樣用程序代碼實

28、現(xiàn)這個設(shè)計的，通常是逐個語句地講述程序的邏輯，小組其他成員仔細傾聽他的講解，并力圖發(fā)現(xiàn)其中的錯誤。審查會上進行的另外一項工作是，對照“程序設(shè)計常見錯誤清單”，分析審查這個程序。當發(fā)現(xiàn)錯誤時由組長記錄下來，審查會繼續(xù)進行(審查小組的任務(wù)是發(fā)現(xiàn)錯誤而不是改正錯誤)。 審查會還有另外一種常見的進行方法，稱為預(yù)排：由一個人扮演“測試者”，其他人扮演“計算機”。會前測試者準備好測試方案，會上由扮演計算機的成員模擬計算機執(zhí)行被測試的程序。 當然，由于人執(zhí)行程序速度極慢，因此測試數(shù)據(jù)必須簡單，測試方案的數(shù)目也不能過多。但是，測試方案本身并不十分關(guān)鍵，它只起一種促進思考引起討論的作用。 代碼審查比計算機測試優(yōu)

29、越的是：一次審查會上可以發(fā)現(xiàn)許多錯誤。用計算機測試的方法發(fā)現(xiàn)錯誤之后，通常需要先改正這個錯誤才能繼續(xù)測試，因此錯誤是一個一個地發(fā)現(xiàn)并改正的。 對于查找某些類型的錯誤來說，人工測試比計算機測試更有效；對于其他類型的錯誤來說則剛好相反。 因此，人工測試和計算機測試是互相補充，相輔相成的，缺少其中任何一種方法都會使查找錯誤的效率降低。模塊并不是一個獨立的程序，因此必須為每個單元測試開發(fā)驅(qū)動軟件和(或)存根軟件。通常驅(qū)動程序也就是一個“主程序”，它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測試的模塊，并且印出有關(guān)的結(jié)果。存根程序代替被測試的模塊所調(diào)用的模塊。因此存根程序也可以稱為“虛擬子程序”。它使用被它代替的

30、模塊的接口，可能做最少量的數(shù)據(jù)操作，印出對入口的檢驗或操作結(jié)果，并且把控制歸還給調(diào)用它的模塊。7.3.3 計算機測試例：圖7.2是一個正文加工系統(tǒng)的部分層次圖，假定要測試其中編號為3.0的關(guān)鍵模塊正文編輯模塊。 需要有一個測試驅(qū)動程序來調(diào)用它。這個驅(qū)動程序說明必要的變量，接收測試數(shù)據(jù)字符串，并且設(shè)置正文編輯模塊的編輯功能。用控制變量CFUNCT標記要實現(xiàn)的編輯功能。 正文編輯模塊需要調(diào)用它的下層模塊來完成具體的編輯功能，所以需要有存根程序簡化地模擬這些下層模塊。TEST STUB(*測試正文編輯模塊用的存根程序 “修改3.4”*)初始化；輸出信息“輸入的控制信息是：修改” ；輸出信息 “修改前

31、的信息：”緩沖區(qū)中的字符串；把緩沖區(qū)中第二個字改為* ；輸出信息 “修改后的信息：”緩沖區(qū)中的新字符串；END TEST STUB編輯 3.0這才是要測試的TEST DRIVER(*測試正文編輯模塊用的驅(qū)動程序*)聲明長度為2500個字符的一個緩沖區(qū)；把CFUNCT置為希望測試的狀態(tài)（修改、刪除等）；輸入一個字符串；調(diào)用編輯模塊；停止或再次初啟；END TEST DRIVER編輯 3.0這才是要測試的驅(qū)動程序和存根程序代表開銷，也就是說，為了進行單元測試必須編寫測試軟件，但是通常并不把它們作為軟件產(chǎn)品的一部分交給用戶。7.4 集成測試由模塊組裝成程序時有兩種方法。一種方法是先分別測試每個模塊，

32、再把所有模塊按設(shè)計要求放在一起結(jié)合成所要的程序，這種方法稱為非漸增式測試方法；另一種方法是把下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進行測試，測試完以后再把下一個應(yīng)該測試的模塊結(jié)合進來測試。這種每次增加一個模塊的方法稱為漸增式測試，這種方法實際上同時完成單元測試和集成測試。對比它們的主要優(yōu)缺點： 非漸增式測試一下子把所有模塊放在一起，把龐大的程序作為一個整體來測試。測試時會遇到許許多多的錯誤，想要診斷、定位、改正錯誤更是極端困難。而且一旦改正一個錯誤之后，馬上又會遇到新的錯誤，看起來好像永遠也沒有盡頭。 漸增式測試則相反，它把程序劃分成小段來構(gòu)造和測試，比較容易定位和改正錯誤；對接口可

33、以進行更徹底的測試。 因此，目前在進行集成測試時普遍采用漸增式測試方法。 當使用漸增方式把模塊結(jié)合到程序中去時，有兩種策略：自頂向下的集成策略自底向上的集成策略自頂向下集成方法是一個廣泛采用的測試和組裝軟件的途徑。從主控制模塊開始，沿著程序的控制層次向下移動，逐漸把各個模塊結(jié)合起來。深度優(yōu)先的結(jié)合方法：先組裝在軟件結(jié)構(gòu)的一條主控制通路上的所有模塊。寬度優(yōu)先的結(jié)合方法：是沿軟件結(jié)構(gòu)水平地移動，把處于同一個控制層次上的所有模塊組裝起來。7.4.1 自頂向下集成 自頂向下結(jié)合的具體過程由下述4個步驟完成：第一步，對主控制模塊進行測試，測試時用存根程序代替所有直接附屬于主控制模塊的模塊；第二步，根據(jù)選

34、定的結(jié)合策略(深度優(yōu)先或?qū)挾葍?yōu)先)，每次用一個實際模塊代換一個存根程序(新結(jié)合進來的模塊往往又需要新的存根程序)；第三步，在結(jié)合進一個模塊的同時進行測試；第四步，為了保證加入模塊沒有引進新的錯誤，可能需要進行回歸測試(即，全部或部分地重復(fù)以前做過的測試)。圖7.3 自頂向下結(jié)合 從第二步開始不斷地重復(fù)進行上述過程，直到構(gòu)造起完整的軟件結(jié)構(gòu)為止。 圖7.3描繪了這個過程。自頂向下結(jié)合策略的特點：能夠在測試的早期對主要的控制或關(guān)鍵的抉擇進行檢驗。在一個分解得好的軟件結(jié)構(gòu)中，關(guān)鍵的抉擇位于層次系統(tǒng)的較上層，因此首先碰到。如果選擇深度優(yōu)先的結(jié)合方法，可以在早期實現(xiàn)軟件的一個完整的功能并且驗證這個功能。

35、可以增強開發(fā)人員和用戶雙方的信心。自頂向下的方法講起來比較簡單，但是實際使用時可能遇到邏輯上的問題。在自頂向下測試的初期，存根程序代替了低層次的模塊，因此，在軟件結(jié)構(gòu)中沒有重要的數(shù)據(jù)自下往上流。為了解決這個問題，測試人員有兩種選擇： 1、把許多測試推遲到用真實模塊代替了存根程序以后再進行。但是這樣又失去了在特定的測試和組裝特定的模塊之間的精確對應(yīng)關(guān)系，這可能導(dǎo)致在確定錯誤的位置和原因時發(fā)生困難。 2、從層次系統(tǒng)的底部向上組裝軟件。這種方法就是自底向上的測試。自底向上測試從“原子”模塊(即在軟件結(jié)構(gòu)最低層的模塊)開始組裝和測試。因為是從底部向上結(jié)合模塊，總能得到所需的下層模塊處理功能，所以不需要

36、存根程序。7.4.2 自底向上集成自底向上結(jié)合的步驟：1、把低層模塊組合成實現(xiàn)某個特定的軟件子功能的族；2、寫一個驅(qū)動程序(用于測試的控制程序)，協(xié)調(diào)測試數(shù)據(jù)的輸入和輸出；3、對由模塊組成的子功能族進行測試；4、去掉驅(qū)動程序，沿軟件結(jié)構(gòu)自下向上移動，把子功能族組合起來形成更大的子功能族。圖7.4 自底向上結(jié)合一般說來，一種方法的優(yōu)點正好對應(yīng)于另一種方法的缺點。自頂向下測試方法的主要優(yōu)點：不需要測試驅(qū)動程序能在測試的早期實現(xiàn)并驗證系統(tǒng)的主要功能能在早期發(fā)現(xiàn)上層模塊的接口錯誤自頂向下測試方法的主要缺點：需要存根程序低層關(guān)鍵模塊中的錯誤發(fā)現(xiàn)較晚而且用這種方法在早期不能充分展開人力7.4.3 不同集成

37、測試策略的比較在測試實際的軟件系統(tǒng)時，應(yīng)該根據(jù)軟件的特點以及工程進度安排，選用適當?shù)臏y試策略。一般說來，純粹自頂向下或純粹自底向上的策略可能都不實用，人們在實踐中創(chuàng)造出許多混合策略：(1) 改進的自頂向下測試方法。基本上使用自頂向下的測試方法，但是在早期使用自底向上的方法測試軟件中的少數(shù)關(guān)鍵模塊。一般的自頂向下方法所具有的優(yōu)點在這種方法中也都有，而且能在測試的早期發(fā)現(xiàn)關(guān)鍵模塊中的錯誤；但是，它的缺點也比自頂向下方法多一條，即測試關(guān)鍵模塊時需要驅(qū)動程序。（2） 混合法。對軟件結(jié)構(gòu)中較上層使用的自頂向下方法與對軟件結(jié)構(gòu)中較下層使用的自底向上方法相結(jié)合。 這種方法兼有兩種方法的優(yōu)點和缺點，當被測試的

38、軟件中關(guān)鍵模塊比較多時，這種混合法可能是最好的折衷方法。在集成測試過程中每當一個新模塊結(jié)合進來時，程序就發(fā)生了變化：建立了新的數(shù)據(jù)流路徑，可能出現(xiàn)了新的I/O操作，激活了新的控制邏輯。這些變化有可能使原來工作正常的功能出現(xiàn)問題。在集成測試的范疇中，所謂回歸測試是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證上述這些變化沒有帶來非預(yù)期的副作用。7.4.4 回歸測試 更廣義地說，任何成功的測試都會發(fā)現(xiàn)錯誤，而且錯誤必須被改正。每當改正軟件錯誤的時候，軟件配置的某些成分（程序、文檔或數(shù)據(jù)）也被修改了?；貧w測試就是用于保證由于調(diào)試或其他原因引起的變化，不會導(dǎo)致非預(yù)期的軟件行為或額外錯誤的測試活動。 回歸測

39、試可以通過重新執(zhí)行全部測試用例的一個子集人工地進行，也可以使用自動化的捕獲回放工具自動進行。利用捕獲回放工具，軟件工程師能夠捕獲測試用例和實際運行結(jié)果，然后可以回放（即重新執(zhí)行測試用例），并且比較軟件變化前后所得到的運行結(jié)果?；貧w測試集（已執(zhí)行過的測試用例的子集）包括下述3類不同的測試用例：（1） 檢測軟件全部功能的代表性測試用例（2）針對被修改過的軟件成分的測試（3）專門針對可能受修改影響的軟件功能的附加測試 確認測試也稱為驗收測試，它的目標是驗證軟件的有效性。軟件有效性的一個簡單定義是： 如果軟件的功能和性能如同用戶所合理期待的那樣，軟件就是有效的。需求分析階段產(chǎn)生的軟件需求規(guī)格說明書，準

40、確地描述了用戶對軟件的合理期望，是軟件有效性的標準，也是進行確認測試的基礎(chǔ)。7.5 確認測試確認測試必須有用戶積極參與，或者以用戶為主進行。用戶應(yīng)該參與設(shè)計測試方案，使用用戶界面輸入測試數(shù)據(jù)并且分析評價測試的輸出結(jié)果。為了使得用戶能夠積極主動地參與確認測試，特別是為了使用戶能有效地使用這個系統(tǒng)，通常在驗收之前由開發(fā)單位對用戶進行培訓。7.5.1 確認測試的范圍確認測試通常使用黑盒測試法。通過測試和調(diào)試要保證軟件能滿足所有功能要求，能達到每個性能要求，文檔資料是準確而完整的，此外，還應(yīng)該保證軟件能滿足其他預(yù)定的要求（例如，安全性、可移植性、兼容性和可維護性等）。確認測試有下述兩種可能的結(jié)果：（1

41、） 功能和性能與用戶要求一致，軟件是可以接受的；（2） 功能和性能與用戶要求有差距。在這個階段發(fā)現(xiàn)的問題往往和需求分析階段的差錯有關(guān)，涉及的面通常比較廣，因此解決起來也比較困難。確認測試的一個重要內(nèi)容是復(fù)查軟件配置。復(fù)查的目的: 保證軟件配置的所有成分都齊全，質(zhì)量符合要求，文檔與程序完全一致，具有完成軟件維護所必須的細節(jié)，而且已經(jīng)編好目錄。7.5.2 軟件配置復(fù)查如果軟件是專為某個客戶開發(fā)的，驗收測試是由最終用戶而不是系統(tǒng)的開發(fā)者進行的。事實上，驗收測試可以持續(xù)幾個星期甚至幾個月，因此能夠發(fā)現(xiàn)隨著時間流逝可能會降低系統(tǒng)質(zhì)量的累積錯誤。7.5.3 Alpha和Beta測試如果一個軟件是為許多客戶

42、開發(fā)的（例如，向大眾公開出售的盒裝軟件產(chǎn)品），那么，讓每個客戶都進行正式的驗收測試是不現(xiàn)實的。在這種情況下，絕大多數(shù)軟件開發(fā)商都使用被稱為Alpha測試和Beta測試的過程。Alpha測試由用戶在開發(fā)者的場所進行，并且在開發(fā)者對用戶的“指導(dǎo)”下進行測試。開發(fā)者負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題。總之，Alpha測試是在受控的環(huán)境中進行的。Beta測試由軟件的最終用戶們在一個或多個客戶場所進行。Beta測試是軟件在開發(fā)者不能控制的環(huán)境中的“真實”應(yīng)用。用戶記錄在Beta測試過程中遇到的一切問題（真實的或想像的），并且定期把這些問題報告給開發(fā)者。接收到在Beta測試期間報告的問題之后，開發(fā)者對軟

43、件產(chǎn)品進行必要的修改，并準備向全體客戶發(fā)布最終的軟件產(chǎn)品。不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大，為了提高測試效率降低測試成本，應(yīng)該選用高效的測試數(shù)據(jù): 選用少量“最有效的”測試數(shù)據(jù)，做到盡可能完備的測試。設(shè)計測試方案是測試階段的關(guān)鍵技術(shù)問題。7.6 白盒測試技術(shù) 邏輯覆蓋是對一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。 7.6.1 邏輯覆蓋1. 語句覆蓋語句覆蓋的含義是，選擇足夠多的測試數(shù)據(jù)，使被測程序中每個語句至少執(zhí)行一次。例如，圖7.5所示的程序流程圖描繪了一個被測模塊的處理算法。為了使每個語句都執(zhí)行一次，程序的執(zhí)行路徑應(yīng)該是sacbed,為此只需要輸入下面的測試數(shù)

44、據(jù)(實際上X可以是任意實數(shù))：A=2，B=0，X=4圖7.5 被測試模塊的流程圖語句覆蓋：A=2，B=0，X=4語句覆蓋的問題？1、對程序的邏輯覆蓋很少。2、只關(guān)心判定表達式的值，而沒有分別測試判定表達式中每個條件取不同值時的情況。語句覆蓋是很弱的邏輯覆蓋標準。2. 判定覆蓋判定覆蓋又叫分支覆蓋: 不僅每個語句必須至少執(zhí)行一次，而且每個判定的每種可能的結(jié)果都應(yīng)該至少執(zhí)行一次。也就是每個判定的每個分支都至少執(zhí)行一次。判定覆蓋（分支覆蓋）A=3，B=0，X=3。sacbdA=2，B=1，X=1。sabed問題？判定覆蓋比語句覆蓋強，但是對程序邏輯的覆蓋程度仍然不高。3. 條件覆蓋條件覆蓋的含義是：

45、不僅每個語句執(zhí)行一次，還要使判定表達式中的每個條件都取到各種可能的結(jié)果。條件覆蓋通常比判定覆蓋強，因為它使判定表達式中每個條件都取到了兩個不同的結(jié)果，判定覆蓋卻只關(guān)心整個判定表達式的值。應(yīng)選取適當?shù)臏y試數(shù)據(jù)，使得：(1)在a點，出現(xiàn)下列各種結(jié)果： A1， A1，B=0，B 0(2)在b點，出現(xiàn)下列各種結(jié)果： A=2，A2，X1，X1 注意：分別出現(xiàn)即可，不是組合條件同時出現(xiàn)條件覆蓋：在a點出現(xiàn)下列各種結(jié)果： A1， A1，B=0，B 0在b點出現(xiàn)下列各種結(jié)果：A=2，A2，X1，X1用下面兩組測試數(shù)據(jù)即可：A=2,B=0,X=4 sacbedA=1,B=1,X=1 sabd判定覆蓋不一定包含條

46、件覆蓋，條件覆蓋也不一定包含判定覆蓋！由此提出一種能同時滿足這兩種覆蓋標準的邏輯覆蓋：4. 判定/條件覆蓋選取足夠多的測試數(shù)據(jù)，使得判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結(jié)果。然而，有時判定/條件覆蓋也并不比條件覆蓋更強。5. 條件組合覆蓋條件組合覆蓋是更強的邏輯覆蓋標準，它要求選取足夠多的測試數(shù)據(jù)，使得每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次。條件組合覆蓋：選取四組數(shù)據(jù)即可使8種條件組合都至少出現(xiàn)一次。SacbedSabedSabedsabd 滿足條件組合覆蓋標準的測試數(shù)據(jù)，也一定滿足判定覆蓋、條件覆蓋和判定/條件覆蓋標準。因此，條件組合覆蓋是

47、前述幾種覆蓋標準中最強的。 但是，滿足條件組合覆蓋標準的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到（原因：雖然每一個判定表達式取了各種值，但全部表達式的取值組合才決定著整個程序的路徑）程序:if ( Condition1 and Condition2 ) then Do_something;EndIfAnother_thing;測試用例:Condition1 = True , Condition2 = True語句覆蓋程序:if ( Condition1 and Condition2 ) then Do_something;EndIfAnother_thing;測試用例: Condition

48、1 = True , Condition2 = True Condition1 = False 判斷覆蓋(每個分支都執(zhí)行到了)程序:if ( Condition1 and Condition2 ) then Do_something;EndIfAnother_thing;測試用例: Condition1 = True , Condition2 = False Condition1 = False, Condition2 = True 條件覆蓋在上面的分析過程中常常談到測試數(shù)據(jù)執(zhí)行的程序路徑，顯然，測試數(shù)據(jù)可以檢測的程序路徑的多少，也反映了對程序測試的詳盡程度。從對程序路徑的覆蓋程度分析，能夠提

49、出下述一些主要的邏輯覆蓋標準。6. 點覆蓋在第6.5節(jié)中已經(jīng)講述了從程序流程圖導(dǎo)出流圖的方法。在正常情況下流圖是連通的有向圖。滿足點覆蓋標準要求選取足夠多的測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖的每個結(jié)點一次。由于流圖的每個結(jié)點與一條或多條語句相對應(yīng)，顯然，點覆蓋標準和語句覆蓋標準是相同的。7. 邊覆蓋為了滿足邊覆蓋的測試標準，要求選取足夠多測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖中每條邊一次。通常邊覆蓋和判定覆蓋是一致的。8. 路徑覆蓋路徑覆蓋的含義是：選取足夠多測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次(如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次)。 路徑覆蓋是白盒測試中覆蓋率最高的一種覆

50、蓋方法, 可以對程序進行徹底的測試。 它需要對所有可能的路徑進行測試（包括循環(huán)、條件組合、分支選擇等），需要設(shè)計大量、復(fù)雜的測試用例，使得工作量呈指數(shù)級增長。ESTCA (Error Sensitive Test Cases Analysis)對于 A rel B (rel為)型的分支謂詞,應(yīng)適當?shù)剡x擇A與B的值,使得測試執(zhí)行到該分支語句時,AB的情況分別出現(xiàn)一次.對于A rel C (rel為;A是變量,C是常量)型的分支謂詞,當rel為時,適當選擇A,使A= C+M.對外部輸入的變量進行賦值,使其每一測試用例均有不同的值和符號,并與同一組測試用例中其它變量的值和符號不一致.其它覆蓋準則MC

51、/DC覆蓋 (Modified Conditional / Decision Coverage)(更改條件 / 判定 覆蓋)被測試程序模塊的每個入口點和出口點都必須至少被執(zhí)行一次,并且每一個程序判斷的結(jié)果至少被覆蓋一次.程序的判斷被分解為基本的布爾條件表達式,每個條件獨立的作用于判斷的結(jié)果,覆蓋所有條件的可能結(jié)果.1. 基本路徑測試基本路徑測試是Tom McCabe提出的一種白盒測試技術(shù)。使用這種技術(shù)設(shè)計測試用例時，首先計算程序的環(huán)形復(fù)雜度，并用該復(fù)雜度為指南定義執(zhí)行路徑的基本集合，從該基本集合導(dǎo)出的測試用例可以保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值。使用

52、基本路徑測試技術(shù)設(shè)計測試用例的步驟如下：第一步，根據(jù)過程設(shè)計結(jié)果畫出相應(yīng)的流圖。7.6.2 控制結(jié)構(gòu)測試例如，為了用基本路徑測試技術(shù)測試下列的用PDL描述的求平均值過程，首先畫出圖7.6所示的流圖。注意，為了正確地畫出流圖，我們把被映射為流圖結(jié)點的PDL語句編了序號。PROCEDURE average;/* 這個過程計算不超過100個在規(guī)定值域內(nèi)的有效數(shù)字的平均值；同時計算有效數(shù)字的總和及個數(shù)。*/ INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; TY

53、PE value1100 IS SCALAR ARRAY; TYPE average, total.input, total.valid; minimum,maximum, sum IS SCALAR; TYPE i IS INTEGER;1: i=1;total.input=total.valid=0;sum=0;2:DO WHILE valuei -9993: AND total.input=minimum6: AND valuei011:THEN average=sum/total.valid;12:ELSE average=-999;13:ENDIF END average第二步，計算

54、流圖的環(huán)形復(fù)雜度。環(huán)形復(fù)雜度定量度量程序的邏輯復(fù)雜性。有了描繪程序控制流的流圖之后，可以用第6.5.1小節(jié)講述的3種方法之一計算環(huán)形復(fù)雜度。經(jīng)計算，圖7.6所示流圖的環(huán)形復(fù)雜度為6。第三步，確定線性獨立路徑的基本集合。圖7.6 求平均值過程的流圖所謂獨立路徑是指至少引入程序的一個新處理語句集合或一個新條件的路徑，用流圖術(shù)語描述，獨立路徑至少包含一條在定義該路徑之前不曾用過的邊。使用基本路徑測試法設(shè)計測試用例時，程序的環(huán)形復(fù)雜度決定了程序中獨立路徑的數(shù)量，而且這個數(shù)是確保程序中所有語句至少被執(zhí)行一次所需的測試數(shù)量的上界。對于圖7.6所描述的求平均值過程來說，由于環(huán)形復(fù)雜度為6，因此共有6條獨立路

55、徑。通常在設(shè)計測試用例時，識別出判定結(jié)點是很有必要的。本例中結(jié)點2、3、5、6和10是判定結(jié)點。第四步，設(shè)計可強制執(zhí)行基本集合中每條路徑的測試用例。應(yīng)該選取測試數(shù)據(jù)使得在測試每條路徑時都適當?shù)卦O(shè)置好了各個判定結(jié)點的條件。在測試過程中，執(zhí)行每個測試用例并把實際輸出結(jié)果與預(yù)期結(jié)果相比較。一旦執(zhí)行完所有測試用例，就可以確保程序中所有語句都至少被執(zhí)行了一次，而且每個條件都分別取過true值和false值。應(yīng)該注意，某些獨立路徑不能以獨立的方式測試，也就是說，程序的正常流程不能形成獨立執(zhí)行該路徑所需要的數(shù)據(jù)組合。在這種情況下，這些路徑必須作為另一個路徑的一部分來測試。2. 條件測試盡管基本路徑測試技術(shù)簡

56、單而且高效，但是僅有這種技術(shù)還不夠，還需要使用其他控制結(jié)構(gòu)測試技術(shù)，才能進一步提高白盒測試的質(zhì)量。用條件測試技術(shù)設(shè)計出的測試用例，能夠檢查程序模塊中包含的邏輯條件。一個簡單條件是一個布爾變量或一個關(guān)系表達式，在布爾變量或關(guān)系表達式之前還可能有一個NOT算符。關(guān)系表達式的形式如下：E1E2其中，E1和E2是算術(shù)表達式，而是下列算符之一：“”或“”。復(fù)合條件由兩個或多個簡單條件、布爾算符和括弧組成。布爾算符有OR（“|”），AND（“&”）和NOT。不包含關(guān)系表達式的條件稱為布爾表達式。因此，條件成分的類型包括布爾算符、布爾變量、布爾括?。ɡㄗ『唵螚l件或復(fù)合條件）、關(guān)系算符及算術(shù)表達式。如果條件不

57、正確，則至少條件的一個成分不正確。因此，條件錯誤的類型如下：布爾算符錯（布爾算符不正確，遺漏布爾算符或有多余的布爾算符）布爾變量錯布爾括弧錯關(guān)系算符錯算術(shù)表達式錯條件測試方法著重測試程序中的每個條件。本節(jié)下面將講述的條件測試策略有兩個優(yōu)點： 容易度量條件的測試覆蓋率； 程序內(nèi)條件的測試覆蓋率可指導(dǎo)附加測試的設(shè)計。條件測試的目的不僅是檢測程序條件中的錯誤，而且是檢測程序中的其他錯誤。如果程序P的測試集能有效地檢測P中條件的錯誤，則它很可能也可以有效地檢測P中的其他錯誤。此外，如果一個測試策略對檢測條件錯誤是有效的，則很可能該策略對檢測程序的其他錯誤也是有效的。人們已經(jīng)提出了許多條件測試策略。分支

58、測試可能是最簡單的條件測試策略：對于復(fù)合條件C來說，C的真分支和假分支以及C中的每個簡單條件，都應(yīng)該至少執(zhí)行一次。域測試要求對一個關(guān)系表達式執(zhí)行3個或4個測試。對于形式為E1E2的關(guān)系表達式來說，需要3個測試分別使E1的值大于、等于或小于E2的值。如果錯誤而E1和E2正確，則這3個測試能夠發(fā)現(xiàn)關(guān)系算符的錯誤。為了發(fā)現(xiàn)E1和E2中的錯誤，讓E1值大于或小于E2值的測試數(shù)據(jù)應(yīng)該使這兩個值之間的差別盡可能小。包含n個變量的布爾表達式需要2n個（每個變量分別取真或假這兩個可能值的組合數(shù)）測試。這個策略可以發(fā)現(xiàn)布爾算符、變量和括弧的錯誤，但是，該策略僅在n很小時才是實用的。在上述種種條件測試技術(shù)的基礎(chǔ)上

59、，K.C.Tai提出了一種被稱為BRO(branch and relational operator)測試的條件測試策略。如果在條件中所有布爾變量和關(guān)系算符都只出現(xiàn)一次而且沒有公共變量，則BRO測試保證能發(fā)現(xiàn)該條件中的分支錯和關(guān)系算符錯。BRO測試利用條件C的條件約束來設(shè)計測試用例。包含n個簡單條件的條件C的條件約束定義為（D1，D2，Dn），其中Di(0，=和指定表達式的輸出約束。3. 循環(huán)測試循環(huán)是絕大多數(shù)軟件算法的基礎(chǔ)。循環(huán)測試是一種白盒測試技術(shù)，它專注于測試循環(huán)結(jié)構(gòu)的有效性。在結(jié)構(gòu)化的程序中通常只有3種循環(huán)，即簡單循環(huán)、串接循環(huán)和嵌套循環(huán)，如圖7.7所示。圖7.7 3種循環(huán)下面分別討論

60、這3種循環(huán)的測試方法。（1） 簡單循環(huán)。應(yīng)該使用下列測試集來測試簡單循環(huán)，其中n是允許通過循環(huán)的最大次數(shù)。跳過循環(huán)。通過循環(huán)一次、兩次。通過循環(huán)m次，其中mn-1。通過循環(huán)n-1,n,n+1次。（2） 嵌套循環(huán)。如果把簡單循環(huán)的測試方法直接應(yīng)用到嵌套循環(huán)，可能的測試數(shù)就會隨嵌套層數(shù)的增加按幾何級數(shù)增長，這會導(dǎo)致不切實際的測試數(shù)目。一種能減少測試數(shù)的方法：從最內(nèi)層循環(huán)開始測試，把所有其他循環(huán)都設(shè)置為最小值。對最內(nèi)層循環(huán)使用簡單循環(huán)測試方法，而使外層循環(huán)的迭代參數(shù)（例如，循環(huán)計數(shù)器）取最小值，并為越界值或非法值增加一些額外的測試。由內(nèi)向外，對下一個循環(huán)進行測試，但保持所有其他外層循環(huán)為最小值，其他