《軟件工程：第07章實現(xiàn)》由會員分享，可在線閱讀，更多相關《軟件工程：第07章實現(xiàn)（164頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、單擊此處編輯母版標題樣式,,單擊此處編輯母版文本樣式,,第二級,,第三級,,第四級,,第五級,,1,第七章 實現(xiàn),（編碼與測試）,,Implementation=Coding + Testing,,實現(xiàn)：編碼與測試,問題定義,可行性研究,需求分析,總體設計,詳細設計,編碼與單元測試,綜合測試,軟件維護,軟件定義時期,軟件開發(fā)時期,軟件維護時期,編碼,,將軟件設計的結果轉(zhuǎn)化成程序設計語言編寫的計算機程序。,,開發(fā)人員對軟件的最小設計單位,-,模塊進行單元測試。,測試,,熟悉軟件測試的步驟：單元測試、集成測試、確認測試。,,掌握軟件測試的方法：白盒測試、黑盒測試、灰盒測試。,,掌握軟件調(diào)試（糾

2、錯）的方法：調(diào)試過程、調(diào)試方法。,,了解軟件可靠性基本概念及估算方法。,第七章,,實現(xiàn),(,編碼與測試,),7.1,編碼,,7.2,軟件測試基礎,,7.3,單元測試,,7.4,集成測試,,7.5,確認測試,,7.6,白盒測試技術,,7.7,黑盒測試技術,,7.8,調(diào)試,,7.9,軟件可靠性,,3,7.1,編碼,編碼就是把軟件設計結果翻譯成用某種程序設計語言書寫的程序。,,,7.1.1,選擇程序設計語言,,7.1.2,編碼風格,,1.,程序內(nèi)部的文檔,,2.,數(shù)據(jù)說明,,3.,語句構造,,4.,輸入輸出,,5.,效率,7.1.1,選擇程序設計語言,為什么,,程序設計語言是人和計算機通信的最基本的

3、工具，它的特點必然會影響人的思維和解題方式，會影響人和計算機通信的方式和質(zhì)量，也會影響其他人閱讀和理解程序的難易程度。因此，編碼之前的一項重要工作就是選擇一種適當?shù)某绦蛟O計語言。,實用選擇標準：,,用戶對編程語言的要求。,,可以使用的編譯程序。,,可以得到的軟件工具。,,工程規(guī)模。,,程序員的編程語言知識。,,軟件可移植性要求。,,軟件的應用領域。,效率：閱讀理解、開發(fā)、測試、運行、維護,……,7.1.2,編碼風格,程序?qū)嶋H上也是一種供人閱讀的文章，應該使程序具有良好的風格?！昂玫摹背绦驊裱囊?guī)則：,,,程序文檔：,,源程序文檔化，易于理解的標識符命名、適當?shù)淖⑨尅⑶逦某绦蛞曈X組織等。,,

4、數(shù)據(jù)說明：,,易于理解，便于查閱。,,語句構造：,,結構化，簡單、直觀，技巧不過份。,,輸入輸出：,,遵循人機界面設計準則。,,效率：,,效率滿足需求；不要為了追求效率而過份使用技巧，犧牲程序的清晰性、可讀性。,,（,1,）程序文檔,程序中的標識符（名字）,,程序中的注釋,,程序的視覺組織,,,★ 符號名的命名,符號名,,即標識符，包括模塊名、變量名、常量名、標號名、子程序名、數(shù)據(jù)區(qū)名以及緩沖區(qū)名等。,,名字的意義,,這些名字應能反映它所代表的實際東西，應有一定實際意義。例如，表示次數(shù)的量用,Times,，表示總量的用,Total,，表示平均值的用,Average,，表示和的量用,Sum,等。

5、,,名字的使用,,名字不是越長越好，應當選擇精煉的意義明確的名字。,,必要時可使用縮寫名字，但這時要注意縮寫規(guī)則要一致。,,要給每一個名字加注釋。,,在一個程序中，一個變量只應用于一種用途。,夾在程序中的注釋是程序員與,日后,的程序讀者之間,通信的重要手段,。,,注釋,決不是可有可無,的。,,一些正規(guī)的程序文本中，注釋行的數(shù)量占到整個源程序的,1/3,到,1/2,，甚至更多。,,注釋分為,序言性注釋,和,功能性注釋,。,★ 程序的注釋,序言性注釋通常置于每個程序模塊的開頭部分，,它應當給出程序的整體說明,，對于理解程序本身具有引導作用。,,序言性注釋包括：,,,程序標題,；,,有關本模塊,功

6、能和目的,的,說明,；,,,主要算法說明：算法概要、大意,；,,,接口說明,：包括調(diào)用形式，參數(shù)描述，子程序清單；,,,有關數(shù)據(jù)描述,：重要的變量及其用途，約束或限制條件，以及其它有關信息；,,,模塊位置,：在哪一個源文件中，或隸屬于哪一個軟件包；,,,開發(fā)簡歷,：模塊設計者，復審者，復審日期，修改日期及有關說明等。,序言性注釋,功能性注釋嵌在源程序體中，用以描述其后的語句或程序段是在做什么工作，或是執(zhí)行了下面的語句會怎么樣，而不要解釋下面怎么做。,,要點,,描述一段程序，而不是每一個語句；,,用縮進和空行，使程序與注釋容易區(qū)別；,,注釋要正確。,,例如：,,,/* ADD AMOUNT TO

7、 TOTAL */ TOTAL = AMOUNT,＋,TOTAL,,上面注視不清楚，如果注明把月銷售額計入年度總額，便使讀者理解了下面語句的意圖：,/* ADD MONTHLY-SALES TO ANNUAL-TOTAL */ TOTAL = AMOUNT,＋,TOTAL,功能性注釋,恰當?shù)乩?空格,，可以,突出運算的優(yōu)先性,，避免發(fā)生運算的錯誤。例如 ，將表達式,(,A,＜－,17),ANDNOT,(,B,＜＝,49),ORC,,寫成,(,A,＜－,17),AND NOT,(,B,＜＝,49),OR C,,自然的程序段之間可用,空行,隔開；,,移行,也叫做,向右縮格

8、,。它是指程序中的各行不必都在左端對齊，都從第一格起排列。這樣做使程序完全分不清層次關系。,,對于,選擇語句,和,循環(huán)語句,，把其中的程序段語句向右做,階梯式移行,。使程序的邏輯結構更加清晰。,例如，兩重選擇結構嵌套寫成下面的移行形式，層次就清楚得多。,,,IF,（,…,）,,THEN IF,（,…,）,,THEN …… ELSE …… ENDIF …… ELSE …… ENDIF,,★ 視覺組織：使用空格、空行和移行,數(shù)據(jù)說明指程序中用到的常量、變量、文件等數(shù)據(jù)對象的定義。,,在

9、設計階段已經(jīng)確定了數(shù)據(jù)結構的組織及其復雜性。在編寫程序時，則,需要注意數(shù)據(jù)說明的風格,。,,為了使程序中數(shù)據(jù)說明更易于理解和維護，必須注意以下幾點,:,,a.,數(shù)據(jù)說明的次序應該標準化,。,有次序易查閱，能加速測試、調(diào)試和維護的過程。,,b.,當,多個變量名,在一個語句中說明時，應該,按字母順序排列,這些變量。,,c.,如果設計時使用了一個,復雜的數(shù)據(jù)結構,，則應該,用注解說明用程序設計語言實現(xiàn),這個,數(shù)據(jù)結構,的方法和特點。,(2),數(shù)據(jù)說明,數(shù)據(jù)說明的次序,數(shù)據(jù)說明,,①,常量說明,,②,簡單變量類型說明,,③,數(shù)組說明,,④,公用數(shù)據(jù)塊說明,,⑤,所有的文件說明,,數(shù)據(jù)類型說明,,① 整

10、型量說明,,② 實型量說明,,③ 字符量說明,,④ 邏輯量說明,,數(shù)據(jù)說明,有次序易查閱，能加速測試、調(diào)試和維護的過程。,變量名按字母順序排列,,b.,,當,多個變量名,在一個語句中說明時，,應該按字母順序排列,這些變量，便于查找。,,,例如，把,,,integer,size,,,length,,,width,,,cost,,,price,,寫成,,,integer,,cost,,,length,,,price,,,size,,,width,,,,（,3,）語句構造,A[I] = A[I],＋,A[T];,,A[T] = A[I],－,A[T];,,A[I] = A[I],－,A[T],；,W

11、ORK = A[T];,,A[T] = A[I];,,A[I] = WORK,；,,構造語句時應該遵循的,原則,是，每個語句都應該,簡單而直接,，不能為了提高效率而使程序變得過分復雜；也,不要刻意追求技巧性，使程序編寫得過于緊湊。,功能：,A[T],與,A[I],交換數(shù)據(jù)值,未使用中間變量,,難懂,使用中間變量,,清晰,例：語句構造,int,i,，,j;,,for (,i,= 1;,i,<=,n,;,i,++ ) for (,j,= 1;,j,<=,n,;,j,++ ),V,[,i,][,j,],＝,(,i,／,j,) * (,j,／,i,),for (,i,＝,1;,i,<=

12、,n,;,i,++ ) for (,j,＝,1;,j,<=,n,;,j,++ ) if (,i == j,),V,[,i,][,j,],＝,1; else,V,[,i,][,j,],＝,0;,,功能：初始化對角單位矩陣,1 0 0 … 0,,0 1 0 … 0,,0 0 1 … 0,,.. .. .. .. .. ..,,0 0 0 … 1,有助于使語句簡單明了的規(guī)則,不要為了節(jié)省空間而把多個語句寫在同一行；,,盡量避免復雜的條件測試；,,盡量減少對“非”條件的測試；,,避免大量使用循環(huán)嵌套和條件嵌套；,,利用括號使邏輯表達式或算術表達式的運算

13、次序清晰直觀。,例：使用,not(!),操作的例子,,將,,if ( !( char,＜,0 || char,＞,9 ) ),,改成,,if ( char >= 0 && char <= 9 ),,,不要讓讀者繞彎子想！,,（,4,）輸入輸出,在設計和編寫程序時應該考慮下述有關輸入輸出風格的規(guī)則：,,對所有輸入數(shù)據(jù)都要進行,檢驗,，識別錯誤輸入，以保證每個數(shù)據(jù)的有效性；,,檢查輸入項的各種重要組合的,合法性,，必要時報告輸入狀態(tài)信息；,,使得輸入的步驟和操作,盡可能簡單,，并保持簡單的輸入格式；,,輸入數(shù)據(jù)時，應允許使用,自由格式輸入,；,,應允許,缺省,值；,,輸入一批數(shù)據(jù)時最好使用,輸入

14、結束標志,，而不要由用戶指定輸入數(shù)據(jù)數(shù)目；,,在交互式輸入輸入時，要在屏幕上使用,提示符,明確提示交互輸入的請求，指明可使用選擇項的種類和取值范圍。同時，在數(shù)據(jù)輸入的過程中和輸入結束時，也要在屏幕上給出狀態(tài)信息；,,當程序設計語言對輸入／輸出格式有嚴格要求時，應保持輸入格式與輸入語句的要求的,一致性,；,,給所有的輸出加,注解,，并設計,輸出報表,格式。,影響輸入輸出風格的其它因素,輸入／輸出風格還受到許多其它因素的影響。如輸入／輸出設備（例如終端的類型，圖形設備，數(shù)字化轉(zhuǎn)換設備等）、用戶的熟練程度、以及通信環(huán)境等。,（,5,）程序效率,程序效率,,程序的效率是指程序的執(zhí)行速度及程序所需占用的

15、內(nèi)存的存儲空間。程序編碼是最后提高運行速度和節(jié)省存儲的機會，因此在此階段不能不考慮程序的效率。,,效率準則,,需求階段：效率是一個性能要求，應當在需求分析階段給出要求。,軟件效率以需求為準,，不應以人力所及為準。,,設計階段：,好的設計可以提高效率,。,,編碼階段：程序的,效率與程序的簡單性相關,，不要犧牲程序的清晰性和可讀性來不必要地提高效率。,,效率問題,,程序運行時間效率,,存儲器效率,,輸入輸出的效率,22,程序運行時間效率,源程序的,效率直接由詳細設計階段確定的算法的效率決定,，但是，寫,程序的風格,也能對程序的執(zhí)行速度和存儲器要求產(chǎn)生影響。,,在把,詳細設計結果翻譯成程序,時，總可

16、以應用下述規(guī)則：,,,√,寫程序之前先簡化算術的和邏輯的表達式；,,,√,仔細研究嵌套的循環(huán)，以確定是否有語句可以從內(nèi)層往外移；,,,√,盡量避免使用多維數(shù)組；,,,√,盡量避免使用指針和復雜的表；,,,√,使用執(zhí)行時間短的算術運算；,,,√,不要混合使用不同的數(shù)據(jù)類型；,,,√,盡量使用整數(shù)運算和布爾表達式。,,在效率是決定性因素的應用領域，盡量使用有良好優(yōu)化特性的編譯程序，以自動生成高效目標代碼。,23,存儲器效率,在大中型計算機系統(tǒng)中，存儲限制不再是主要問題。在這種環(huán)境下，對,內(nèi)存采取基于操作系統(tǒng)的分頁功能的虛擬存儲管理,。,存儲效率與操作系統(tǒng)的分頁功能直接有關,。,,采用結構化程序設計

17、，將程序功能合理分塊，,使每個模塊或一組密切相關模塊的程序體積大小與每頁的容量相匹配,，可減少頁面調(diào)度，減少內(nèi)外存交換，提高存儲效率。,,在微型計算機系統(tǒng)中，存儲器的容量對軟件設計和編碼的制約很大。因此,要選擇可生成較短目標代碼且存儲壓縮性能優(yōu)良的編譯程序,，有時需采用匯編程序。,,提高存儲器效率的關鍵是程序的簡單性。,24,輸入輸出的效率,輸入／輸出可分為,兩種類型,：,,面向,人,(,操作員,),的輸入／輸出,,面向,設備,的輸入／輸出,,高效的輸入／輸出是,,如果操作員能夠十分,方便、簡單,地錄入輸入數(shù)據(jù)，或者能夠十分,直觀、一目了然,地了解輸出信息，則可以說面向人的輸入／輸出是高效的。

18、,,關于提高,設備,輸入,/,輸出效率的指導原則：,,輸入,/,輸出的請求應當最小化；,,對于所有的輸入,/,輸出操作，,安排適當?shù)木彌_區(qū),，以減少頻繁的信息交換。,,對輔助存儲,(,例如磁盤,),，,選擇盡可能簡單的，可接受的存取方法,；對輔助存儲的輸入,/,輸出，應當,成塊傳送,；,,對終端或打印機的輸入,/,輸出，應考慮設備特性,，盡可能改善輸入,/,輸出的質(zhì)量和速度；,,任何不易理解的，對改善輸入,/,輸出效果關系不大的措施都是不可取的；,,任何不易理解的所謂,“,超高效,”,的輸入,/,輸出是毫無價值的。,7.2,軟件測試基礎,7.2.1,軟件測試的目標,,7.2.2,軟件測試準則,

19、,7.2.3,測試方法,,7.2.4,測試步驟,,7.2.5,測試階段的信息流,,7.2.1,軟件測試的目的,引子,,軟件錯誤將造成工作的巨大損失,,例：,1963,年,,,美國,,,飛往火星的火箭爆炸,,,損失,$ 10 million,。原因,: ORTRAN,循環(huán)：,DO 5 I = 1, 3,誤寫為,DO 5 I = 1.3,。,,軟件測試的工作量占整個項目工作量比重極大,,軟件測試的工作量約占整個項目工作量的,40,％左右，對于要求極高的系統(tǒng)測試工作量還要成倍增加。,,例：微軟,Exchange 2000,和,Windows 2000,中的人員結構見下表,,Exchange

20、 2000,Windows 2000,項目經(jīng)理,25人,約 250人,開發(fā)人員,140人,約 1700人,測試人員,350人,約 3200人,測試人員/開發(fā)人員,2: 5,1: 9,軟件測試的目的：問題與觀點,問題,:,,為什么需要這么多人、花這么多代價進行測試？目的何在？,,觀點：,,觀點一：軟件測試的目的是為了 “證明程序正確” 。,,觀點二：軟件測試的目的是為了“找出程序中的錯誤”。,,定義：,,Myers,對軟件測試目的提出以下觀點和定義：,,（,1,）軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程。,,（,2,）一個好的測試用例能夠發(fā)現(xiàn)至今尚未發(fā)現(xiàn)的錯誤。,,（,3,）一個成功的測試是發(fā)現(xiàn)了

21、至今尚未發(fā)現(xiàn)的錯誤的測試。,,,測試只能證明程序中有錯誤，不能證明程序中沒有錯誤,正確！,28,軟件測試的目的,在測試階段測試人員努力設計出一系列測試方案，目的卻是為了“,破壞,”已經(jīng)建造好的軟件系統(tǒng),—,竭力證明程序中有錯誤不能按照預定要求正確工作。,,暴露問題并不是軟件測試的最終目的，發(fā)現(xiàn)問題是為了解決問題，,測試階段的根本目標是,盡可能多地發(fā)現(xiàn)并排除軟件中潛藏的錯誤，最終把一個高質(zhì)量的軟件系統(tǒng)交給用戶使用。,,通常想象的“測試是為了表明程序是正確的”，“成功的測試是沒有發(fā)現(xiàn)錯誤的測試”是不正確的。,,測試的目標決定了測試方案的設計。如果為了表明程序是正確的而進行測試，就會設計一些不易暴露

22、錯誤的測試方案；相反，如果測試是為了發(fā)現(xiàn)程序中的錯誤，就會力求設計出最能暴露錯誤的測試方案。,測試決不能證明軟件是正確的，,也不能證明錯誤的不存在，,它只能力求,證明錯誤的存在。,29,軟件測試的有關問題,軟件缺陷是什么？,,誰執(zhí)行測試？,,開發(fā)者？,,單獨的測試人員？,,兩方面人員？,,測試什么？,,每個部分都測試？,,測試軟件中高風險部分？,,什么時候測試？,,怎樣測試？,,測試應進行到什么程度？,30,軟件缺陷,缺點,(defect),,謬誤,(fault),,,問題,(problem),,錯誤,(error),,異常,(anomaly),,偏差,(variance),,失敗,(fail

23、ure),,缺陷,(bug),這些缺陷都是,描述軟件失敗的術語！,SDE/T,,負責寫測試工具代碼，并利用測試工具對軟件進行測試；或者開發(fā)測試工具為軟件測試工程師服務。,,負責理解產(chǎn)品的功能要求，然后對其進行測試，檢查軟件有沒有錯誤(,Bug,)，,決定軟件是否具有穩(wěn)定性，并寫出相應的測試規(guī)范和測試案例,STE,,測試工具軟件開發(fā)工程師,,(,Software Development Engineer in Test，,簡稱,SDE/T,),軟件測試有關人員,軟件測試工程師,,(,Software Test Engineer ，,簡稱,STE,),32,7.2.2,軟件測試準則,(1),所有

24、測試都應該能追溯到用戶需求。,,(2),應,“,盡早地規(guī)劃和不斷地進行軟件測試,”,。,,(3),將,pareto,原則（,80%:20%,）應用于軟件測試。,,(4),應從,“,小規(guī)模,”,測試開始，,逐步進行,“,大規(guī)模,”,測試。,,(5),窮舉測試是不可能的,。,,(6),應由獨立的第三方從事測試工作。,,(7),測試用例應由,輸入數(shù)據(jù),和,預期的輸出結果,兩部分組成。,,(8),程序修改后要回歸測試。,,(9),應長期保留測試用例，直至系統(tǒng)廢棄。,軟件測試準則,(1),所有測試都應該能追溯到用戶需求,,軟件測試的目標是發(fā)現(xiàn)錯誤。從用戶的角度看，最嚴重的錯誤是導致程序不能滿足用戶需求的

25、那些錯誤。,,軟件中的問題,根源,可能在開發(fā)前期的各階段解決、糾正錯誤也必須追 溯到前期工作。,可追溯性,軟件測試準則（續(xù)）,(2),盡早地規(guī)劃和不斷地進行軟件測試,,把,“,盡早地和不斷地進行軟件測試,”,作為軟件開發(fā)者的座右銘。概要設計時應完成測試計劃，詳細的測試用例定義可在設計模型確定后開始，所有測試可在任何代碼被產(chǎn)生之前進行計劃和設計。,,軟件測試不等于程序測試。,軟件測試應貫穿于軟件定義與開發(fā)的整個期間；,,程序編寫的許多錯誤是,“,先天的,”,。據(jù)統(tǒng)計，查出的軟件錯誤中，屬于,需求分析和軟件設計的錯誤,約占,64%,，屬于,程序編寫的錯誤,僅占,,36%,。,測試與開發(fā)前期工作的關

26、系,,決定軟件與系統(tǒng)的配合關系,,需求分析,,概要設計,,詳細設計,,編 碼,,單元測試,,集成測試,,確認測試,,系統(tǒng)測試,,,,,,計劃,需求,,分析,設,,計,編,,碼,測,,試,錯誤,A,錯誤擴展模型,早期錯誤,中期錯誤,后期錯誤,錯誤,B,錯誤,B,36,軟件測試準則（續(xù)）,(3),在,軟件測試中應用,pareto原則,,,pareto,原則指出：,測試發(fā)現(xiàn)的錯誤中的,80%,很可能是由程序中,20%,的模塊造成的。當然，問題是怎樣找出這些可疑的模塊并徹底地測試它們。,,（,4,）從“小規(guī)?！钡健按笠?guī)模”測試,,應該從,“,小規(guī)模,”,測試開始，并,逐步進行,“,大規(guī)模,”,測試。

27、,,通常，首先重點測試單個程序模塊，然后把測試重點轉(zhuǎn)向在集成的模塊簇中尋找錯誤，最后在整個系統(tǒng)中尋找錯誤。,軟件測試準則（續(xù)）,（,5,）注意測試用例的組成,,測試用例應由,輸入數(shù)據(jù),和,預期的輸出結果,兩部分組成，并兼顧,合理,的輸入和,不合理,的輸入數(shù)據(jù),,（,6,）窮舉測試是不可能的,,所謂窮舉測試就是把程序所有可能的執(zhí)行路徑都檢查一遍的測試。由于程序的執(zhí)行路徑龐大（路徑組合爆炸），受時間、人力及其他資源的限制，窮舉法難以實施。,,經(jīng)精心設計，,可用窮舉法覆蓋所有的程序邏輯,——,遍歷程序流圖的所有的邊（即每個語句都被執(zhí)行一次?。?，達到所要求的一定的測試可靠性。,窮舉測試例,例,2,：

28、如圖，設程序含,4,個分支,,,循環(huán)次數(shù)≤,20,,從,A,到,B,的可能路徑有：,,5,1,+5,2,+,…,+5,20,≈,10,14,（條）,,執(zhí)行時間,:,,設測試一次需,2ms,，則窮舉測試需,5,億年。,,,,,,,,,,,,,,A,B,例,1:,,輸入三角形的三條邊長，可采用的測試用例數(shù),(,設字長,16,位,),為（次）,,2,16,X2,16,,X2,16,≈3X10,10,（次）,,執(zhí)行時間,:,,設測試一次需,1ms,，約需一萬年。,a,b,c,軟件測試準則（續(xù)）,（,7,）為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。,,所謂,“,最佳效果,”,是指有最大可

29、能性發(fā)現(xiàn)錯誤的測試。由于心理上的原因，開發(fā)軟件的軟件工程師并不是完成全部測試工作的最佳人選，通常他們主要承擔模塊測試工作。而其他測試應由第三方承擔。,,（,8,）程序修改后要回歸測試,,程序正常修改或糾錯修改之后，可能引入新的錯誤，因此必須進行回歸測試。,,（,9,）應長期保留測試用例，直至系統(tǒng)廢棄。,,保留測試用例，可用于回歸測試、新版本測試。也可在程序出現(xiàn)錯誤之后，進行分析，尋找出錯原因、漏測原因。,軟件測試的,,策略和方法,靜態(tài)測試方法,動態(tài)測試方法,,人工測試方法,計算機輔助靜,,態(tài)分析方法,白盒測試方法,黑盒測試方法,,,,7.2.3,測試方法,靜態(tài)測試,靜態(tài)測試：,,基本特征是在對

30、軟件需求規(guī)格說明書、軟件設計說明書、源程序進行,分析、檢查和審閱,，不實際運行被測試的軟件。,,分析、檢查和審閱內(nèi)容：,,是否符合相關的標準和規(guī)范；,,通過結構分析、流圖分析、符號執(zhí)行等，指出軟件缺陷。,,效果,,靜態(tài)測試約可找出,30,～,70%,的邏輯設計錯誤,.,動態(tài)測試：,,,通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性。,,,動態(tài)測試的兩個基本要素：,,被測試程序,,測試數(shù)據(jù)（測試用例）,,,動態(tài)測試方法：,,(1),選取定義域有效值,,,或定義域外無效值；,,(2),對已選取值決定,預期的結果；,,(3),用選取值執(zhí)行程序；,,(4),執(zhí)行結果,與,預期的結果,相比,,,不吻

31、和則程序有錯,。,,測試用例,ID,,目的,,前提,,輸入,,預期輸出,,后果,,執(zhí)行歷史,,日期 結果 版本 執(zhí)行人,動態(tài)測試,動態(tài)測試技術,白盒測試法,(White Box Testing),,把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結構和處理算法，用于檢測程序中的主要執(zhí)行通路是否都能按預定要求正確工作。,,如果知道軟件的內(nèi)部工作過程，可以通過測試來檢驗產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行。,,白盒測試又稱為結構測試。,,黑盒測試法,(Black Box Testing),,把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結構和處理過程。只檢查程序功能是

32、否按照規(guī)格說明書的規(guī)定正常使用。,,如果已經(jīng)知道了軟件應該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用。,,黑盒測試又稱為功能測試。,白盒測試也叫,玻璃盒測試,(,Glass Box Testing),,對軟件的過程性細節(jié)做細致的檢查。,,這一方法是把測試對象看作一個打開的盒子，它允許測試人員利用程序內(nèi)部的邏輯結構及有關信息，來設計或選擇,測試用例，,對程序所有,邏輯路徑,進行測試。,白盒測試,,的內(nèi)容,對程序模塊的所有,獨立,,執(zhí)行路徑,至少測試一次,對所有的,邏輯判定,，取,,“,真,”,與取,“,假,”,的兩種情況,,都能至少測試一次。,在循環(huán)的邊界和運行邊,,界限內(nèi)執(zhí)行循環(huán)體

33、,測試內(nèi)部數(shù)據(jù)結構的有,,效性。,白盒測試,(White Box Testing),已知產(chǎn)品的功能設計規(guī)格，可以進行測試證明每個實現(xiàn)了的功能是否符合要求。,,黑盒測試,,的內(nèi)容,,Alpha/Beta Testing,菜單/幫助測試,發(fā)行測試,回歸測試,,軟件,,黑盒測試,(Black Box Testing),7.2.4,測試步驟,1.,模塊測試,---,程序的單元,,把每個模塊作為一個單獨的實體來測試。模塊測試通常又稱為單元測試。在測試中所發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。,,2.,子系統(tǒng)測試,---,程序的局部,,把經(jīng)過單元測試的模塊放在一起形成一個子系統(tǒng)來測試。模塊相互間的協(xié)調(diào)和通信是

34、這個測試過程中的主要問題，著重測試模塊的接口。,,3.,系統(tǒng)測試,---,子系統(tǒng)的集成,,把經(jīng)過測試的子系統(tǒng)裝配成一個完整的系統(tǒng)來測試。驗證系統(tǒng)能否提供需求說明書中指定的功能，動態(tài)特性是否符合預定要求。其中發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能是需求說明中的錯誤。子系統(tǒng)測試和系統(tǒng)測試，都兼有檢測和組裝兩重含義，通常稱為集成測試。,,4.,驗收測試,---,用戶參與系統(tǒng)整體測試,,把軟件系統(tǒng)作為單一的實體進行測試，測試內(nèi)容與系統(tǒng)測試基本類似，但它是在用戶積極參與下進行的，而且主要使用實際數(shù)據(jù)進行測試。目的是驗證系統(tǒng)確實能夠滿足用戶的需要，其中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。驗收測試也稱為確認測

35、試。,,5.,平行運行,---,新舊系統(tǒng)共存,,平行運行：就是同時運行新開發(fā)出來的系統(tǒng)和將被它取代的舊系統(tǒng)，以便比較新舊兩個系統(tǒng)的處理結果。,,這樣做的具體目的有如下幾點：,,(1),可以在準生產(chǎn)環(huán)境中運行新系統(tǒng)而又不冒風險；,,(2),用戶能有一段熟悉新系統(tǒng)的時間；,,(3),可以驗證用戶指南和使用手冊之類的文檔；,?(4),能夠以準生產(chǎn)模式對新系統(tǒng)進行全負荷測試，進一步驗證性能指標。,7.2.5,測試階段的信息流,測試階段的的輸入信息有兩類：,,(1),軟件配置，包括需求說明書、設計說明書和源程序清單等；,,(2),測試配置，包括測試計劃和測試方案。,,測試方案包括：測試用例：測試時使用的

36、輸入數(shù)據(jù)； 每組輸入數(shù)據(jù)預定要檢驗的功能，以及每組輸入數(shù)據(jù)預期應該得到的正確輸出。,,測試結果和預期結果不一致時，程序中有錯誤，進入調(diào)試階段。由程序的編寫者負責調(diào)試。,,如果經(jīng)常出現(xiàn)要求修改設計的嚴重錯誤，那么軟件的質(zhì)量和可靠性是值得懷疑的。,,如果軟件功能完成得很正常，遇到的錯誤也很容易改正，仍然應該考慮兩種可能：,,(1),軟件的可靠性是可以接受的；,,(2),所進行的測試尚不足以發(fā)現(xiàn)嚴重的錯誤。,,如果經(jīng)過測試，一個錯誤也沒有被發(fā)現(xiàn)，則很可能是對測試配置思考不充分，以致不能暴露軟件中潛藏的錯誤。,測試階段的信息流,測試,軟件配置,結果,,分析,,評價,測試結果,調(diào)試,,排錯,改正的,,軟

37、件,預期結果,可靠性,,模型及,,分析,預測的,,可靠性,錯誤,出錯率,,數(shù)據(jù),測試配置,測試工具,,,需求規(guī)格說明書,,軟件設計說明書,,被測源程序,,測試計劃,,測試用例,,(,測試數(shù)據(jù),),,測試驅(qū)動程序,測試數(shù)據(jù)自動生成程序、靜態(tài)分析程序、動態(tài)分析程序、測試結果分析程序、以及驅(qū)動測試的測試數(shù)據(jù)庫等。,,圖,7.1,測試階段的信息流,49,軟件測試的對象,軟件測試并不等于程序測試。,軟件測試應貫穿于軟件定義與開發(fā)的整個期間。,因此，需求分析、概要設計、詳細設計以及程序編碼等所得到的,文檔資料,，包括需求規(guī)格說明、概要設計說明、詳細設計規(guī)格說明以及源程序，都應成為軟件測試的對象。,,,軟件

38、,=,程序,+,文檔！,7.3,單元測試,7.3.1,測試重點,,7.3.2,（人工）代碼審查,,7.3.3,計算機測試,,7.3.1,測試重點,1.,模塊接口,,對通過模塊接口的數(shù)據(jù)流進行測試，如果數(shù)據(jù)不能正確地進出，所有其他測試都是不切實際的。主要檢查下述幾個方面：參數(shù)的數(shù)目、次序、屬性或單位系統(tǒng)與變元是否一致；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。,,2.,局部數(shù)據(jù)結構,,對模塊來說，局部數(shù)據(jù)結構是常見的錯誤來源。主要檢查內(nèi)容包括局部數(shù)據(jù)說明、初始化、默認值等方面的錯誤。,,3.,重要的執(zhí)行通路,,由于不可能進行窮盡測試，在單元測試期間選擇最有代表性、最可

39、能發(fā)現(xiàn)錯誤的執(zhí)行通路進行測試就是十分關鍵的。應該設計測試方案用來發(fā)現(xiàn)由于錯誤的計算、不正確的比較或不適當?shù)目刂屏鞫斐傻腻e誤。,,4.,出錯處理通路,,好的設計應該能預見出現(xiàn)錯誤的條件，并且設置適當?shù)奶幚礤e誤的通路。應該著重測試下述一些可能發(fā)生的錯誤：,,(1),對錯誤的描述是難以理解的；,,(2),記下的錯誤與實際遇到的錯誤不同；,,(3),在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)干預；,,(4),對錯誤的處理不正確；,,(5),描述錯誤的信息不足以幫助確定造成錯誤的位置。,,5.,邊界條件,,邊界測試在單元測試中非常重要。軟件常常在它的邊界上失效。 應使用剛好小于、剛好等于和剛好大于最大

40、值或最小值的測試方案，非?？赡馨l(fā)現(xiàn)軟件中的錯誤。,7.3.2,代碼審查,代碼審查,,,由審查小組人工測試源程序稱為代碼審查。是一種非常有效的程序驗證技術，對于典型的程序來說，可以查出,30%,～,70%,的邏輯設計錯誤和編碼錯誤。,,審查小組組成：,,(1),組長，應該是一個很有能力的程序員，而且沒有直接參與這項工程；,,(2),程序的設計者；,,(3),程序的編寫者；,,(4),程序的測試者。,審查的步驟：,,小組成員先研究設計說明書，力求理解這個設計。,,由設計者扼要地介紹他的設計。,,審查會上程序的編寫者逐個語句地解釋是怎樣用程序代碼實現(xiàn)這個設計的。,,審查會上對照程序設計常見錯誤，分析

41、審查這個程序。,,當發(fā)現(xiàn)時，記錄錯誤，繼續(xù)審查。,代碼審查的方法,討論：,,是由一些有經(jīng)驗的測試人員閱讀程序文本及有關文檔，對程序的結構與功能、數(shù)據(jù)的結構、接口、控制流以及語法進行討論和分析，從而揭示程序中的錯誤。,,走查：,,是由測試人員用一些測試用例沿程序邏輯運行，并隨時記錄程序的蹤跡；然后進行分析，發(fā)現(xiàn)程序中的錯誤。（人工模仿計算機執(zhí)行程序）,7.3.3,計算機測試,模塊的“計算機測試”,,在這里是指使用計算機系統(tǒng)對“模塊”作為獨立測試對象進行測試。,,由于模塊并不是一個獨立的程序，要運行它就必須為其開發(fā),驅(qū)動軟件,和,(,或,),存根（樁）軟件,。,,模塊測試的“驅(qū)動程序”,,“驅(qū)動程

42、序”也就是一個“主程序”，它接收測試數(shù)據(jù)，把這些數(shù)據(jù)傳送給被測試的模塊，并且印出有關的結果。,,模塊測試的“存根程序”,,存根程序（或稱為“樁程序”）代替被測試的模塊所調(diào)用的模塊，也稱為“虛擬子程序”。它使用被它代替的模塊的接口，可能做最少量的數(shù)據(jù)操作，印出對入口的檢驗或操作結果，并且把控制歸還給調(diào)用它的模塊。,被測模塊,驅(qū)動程序,樁程序,1,樁程序,2,……,測試用例,測試用例,測試用例,測試內(nèi)容：,,I/O,接口,,局部數(shù)據(jù)結構,,邊界條件,,程序路徑,,錯誤處理路徑,結果,單元測試的環(huán)境,例：對正文加工系統(tǒng)的“編輯”模塊測試,測試任務,:,,假定要測試正文加工系統(tǒng)中編號為,3.0,的“編

43、輯”模塊。,,驅(qū)動程序,:TEST DRIVER,,說明必要的變量,,接收測試數(shù)據(jù),(,字符串,),,調(diào)用被測模塊“編輯”功能,,并且設置正文編輯模塊的編輯功能,(,如“修改”、“添加”等,),。,,存根程序,:TEST STUB,,簡化地模擬下層模塊，完成具體的編輯功能,(,如“修改”,CHANGE,、“添加”,APPEND,等,),。,,CHANGE,和,APPEND,可以做成二個存根程序，也可只用一個存根程序模擬正文編輯模塊的所有下層模塊。,圖,7.2,正文加工系統(tǒng)的層次圖,計算機測試：評述,代碼審查是人工測試，一次審查會上可以發(fā)現(xiàn)許多錯誤，但難以發(fā)現(xiàn)編碼中的出錯細節(jié)，一般用于模塊的初步

44、測試。,,用計算機測試的方法發(fā)現(xiàn)錯誤之后，通常需要先改正這個錯誤才能繼續(xù)測試，因此錯誤是一個一個地發(fā)現(xiàn)并改正的。,,計算機測試需要開發(fā)驅(qū)動程序和存根程序，增加了一些系統(tǒng)開發(fā)工作量?？稍诩蓽y試中采用增量測試法來同時完成模塊測試。,,人工測試和計算機測試互相補充，相輔相成，缺少其中任何一種方法都會使查找錯誤的效率降低。,7.4,集成測試,7.4.1,自頂向下集成,,7.4.2,自底向上集成,,7.4.3,不同集成測試策略的比較,,7.4.4,回歸測試,,,集成測試概念及目標,集成測試,,把模塊按照設計要求組裝起來的同時進行測試，目的是發(fā)現(xiàn)模塊接口的錯誤。集成測試是測試和組裝軟件的系統(tǒng)化技術。,,

45、集成測試的其主要目標是,發(fā)現(xiàn)與接口有關的問題，如：,,數(shù)據(jù)穿過接口時可能丟失；,,一個模塊對另一個模塊可能由于疏忽而造成有害影響；,,把子功能組合起來可能不產(chǎn)生預期的主功能；,,個別看來是可以接受的誤差可能積累到不能接受的程度；,,全程數(shù)據(jù)結構可能有問題等等。,模塊組裝成系統(tǒng)的方法,1.,非漸增式測試方法,,非漸增式測試（整體拼裝）先分別測試每個模塊，再把所有模塊按設計要求放在一起結合成所要的程序進行測試，最終得到要求的軟件系統(tǒng)。,,,2.,漸增式測試,,把下一個要測試的模塊同已經(jīng)測試好的模塊結合起來進行測試，測試完以后再把下一個應該測試的模塊結合進來測試。,,在組裝過程中邊連接邊測試，以發(fā)現(xiàn)

46、連接過程中產(chǎn)生的問題。,,通過增殖逐步組裝成為要求的軟件系統(tǒng)。這種每次增加一個模塊的方法實際上同時完成單元測試和集成測試,.,,,在進行集成測試時普遍采用漸增式測試方法。,非漸增式測試,(a),軟件結構,(b),測試所有單個模塊,(c),測試整個系統(tǒng),驅(qū)動,樁,漸增方式集成測試的策略,漸增方式把模塊結合到程序中去時，有兩種集成策略：,,自頂向下集成,,自底向上集成,,,在實踐中常采用混合的策略。,7.4.1,自頂向下集成,這種測試從“主控模塊”開始，沿著程序結構的控制層次向下移動，逐漸將各個模塊結合（組裝）進來，指導所有底層模塊。,,模塊組裝進來的順序可有二種策略：“深度有限”和“寬度（或稱廣

47、度）優(yōu)先”。,,自頂向下測試需要開發(fā)“存根程序”。,深度（寬度）優(yōu)先組裝，需要存根程序,圖,7.3,自頂向下結合,7.4.2,自底向上集成,這種測試從“底層模塊”（即葉子模塊）開始，向上移動，逐步將其上層模塊組裝進來，直到主控模塊。,,同樣，模塊組裝進來的順序可有二種策略：“深度有限”和“寬度優(yōu)先”。,,自底向上測試需要開發(fā)“啟動模塊”,,自底向上組裝，需要驅(qū)動程序,圖,7.4,自底向上結合,64,7.4.3,回歸測試,任何成功的測試都會發(fā)現(xiàn)錯誤，而且錯誤必須被改正。每當,改正軟件錯誤,的時候，,軟件配置的某些成分（程序、文檔或數(shù)據(jù)）也被修改了,。,回歸測試就是用于保證由于調(diào)試或其他原因引起的

48、變化，不會導致非預期的軟件行為或額外錯誤的測試活動。,,即：,回歸測試是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證修改變化沒有帶來非預期的副作用。,,回歸測試集（已執(zhí)行過的測試用例的子集）包括下述,3,類不同的測試用例：,,（,1,） 檢測軟件全部功能的代表性測試用例；,,（,2,） 專門針對可能受修改影響的軟件功能的附加測試；,,（,3,） 針對被修改過的軟件成分的測試。,7.5,確認測試,7.5.1,確認測試的范圍,,7.5.2,軟件配置復查,,7.5.3Alpha,和,Beta,測試,,66,7.5,確認測試,確認,測試,,也稱為驗收測試，它的目標是,驗證,軟件的,有效性,。,,確認（,

49、validation,）,：,,指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動。,,驗證（,verification,）：,,指的是保證軟件正確地實現(xiàn)了某個特定要求的一系列活動。,,有效性,：,,如果軟件的功能和性能如同用戶所合理期待的那樣，軟件就是有效的。,,,需求分析階段產(chǎn)生的,軟件需求規(guī)格說明書，,準確地描述了用戶對軟件的合理期望，因此,是軟件有效性的標準，也是進行確認測試的基礎。,67,7.5.1,確認測試的范圍,確認測試必須有用戶積極參與，或者以用戶為主進行。,用戶應該參與設計測試方案，使用用戶界面輸入測試數(shù)據(jù)并且分析評價測試的輸出結果。,,確認測試通常使用黑盒測試法。,應該

50、仔細設計測試計劃和測試過程，測試計劃包括要進行的測試的種類及進度安排，測試過程規(guī)定了用來檢測軟件是否與需求一致的測試方案。,,通過測試和調(diào)試要保證軟件能,滿足,所有,功能要求,，能達到每個,性能要求,，,文檔資料是準確而完整,的，此外，還應該保證軟件能滿足其他,預定的要求,（例如，安全性、可移植性、兼容性和可維護性等）。,68,7.5.2,軟件配置復查,確認測試的一個重要內(nèi)容是復查軟件配置。,軟件配置,指軟件需求規(guī)格說明、軟件設計規(guī)格說明、源代碼等。,,復查的目的,是保證軟件配置的所有成分都齊全，質(zhì)量符合要求，文檔與程序完全一致，具有完成軟件維護所必須的細節(jié)，而且已經(jīng)編好目錄。,,除了按合同規(guī)

51、定的內(nèi)容和要求，由人工審查軟件配置之外，在,確認測試過程中還應該嚴格遵循用戶指南及其他操作程序，,以便檢驗這些使用手冊的完整性和正確性。必須仔細記錄發(fā)現(xiàn)的遺漏或錯誤，并且適當?shù)匮a充和改正。,69,7.5.3 Alpha,和,Beta,測試,Alpha,測試,,由用戶在開發(fā)者的場所進行,，,并且在開發(fā)者對用戶的,“,指導,”,下進行測試。開發(fā)者負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題。該測試是在受控的環(huán)境中進行的。,,Beta,測試,,由軟件的最終用戶們在一個或多個客戶場所進行,。,Beta,測試是軟件在開發(fā)者不能控制的環(huán)境中的,“,真實,”,應用。用戶記錄在,Beta,測試過程中遇到的一切問

52、題（真實的或想像的），并且定期把這些問題報告給開發(fā)者。接收到在,Beta,測試期間報告的問題之后，開發(fā)者對軟件產(chǎn)品進行必要的修改，并準備向全體客戶發(fā)布最終的軟件產(chǎn)品。,70,如何實施測試？,關鍵技術,,----,設計測試方案。,,測試方案,,----,包括：具體的測試目的，應該輸入的測試數(shù)據(jù)和預期的結果。,,通常又把測試數(shù)據(jù)和預期的輸出結果稱為,測試用例,。其中,最困難的問題是設計測試用例的輸入數(shù)據(jù),。,,不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大，為了提高測試效率降低測試成本，應該選用高效的測試數(shù)據(jù)。因為不可能進行窮盡的測試，,選用少量,“,最有效的,”,測試數(shù)據(jù)，做到盡可能完備的測試就更重要

53、了。,71,測試方案哪一種好呢？,設計測試方案的基本目標是，確定一組最可能發(fā)現(xiàn)某個錯誤或某類錯誤的測試數(shù)據(jù)。,,現(xiàn)已經(jīng)研究出許多設計測試數(shù)據(jù)的技術，這些技術,各有優(yōu)缺點，沒有哪一種是最好的,，更沒有哪一種可以代替其余所有技術；同一種技術在不同的應用場合效果可能相差很大，因此，,通常需要聯(lián)合使用多種設計測試數(shù)據(jù)的技術。,7.6,白盒測試技術,7.6.1,邏輯覆蓋,,1.,語句覆蓋,,2.,判定覆蓋,,3.,條件覆蓋,,4.,判定,/,條件覆蓋,,5.,條件組合覆蓋,,6.,點覆蓋,,7.,邊覆蓋,,8.,路徑覆蓋,,7.6.2,控制結構測試,,1.,基本路徑測試,,2.,條件測試,,3.,循環(huán)測

54、試,73,7.6.1,邏輯覆蓋,邏輯覆蓋,----,是以,程序內(nèi)部的邏輯結構為基礎,的設計測試用例的技術。,,,(1),語句覆蓋,(2),判定覆蓋,,(3),條件覆蓋,(4),判定,/,條件覆蓋,,(5),條件組合覆蓋,(6),點覆蓋,,(7),邊覆蓋,(8),路徑覆蓋,74,發(fā)現(xiàn)錯誤,,的能力,標 準,含 義,1,語句覆蓋,每條,語,句,至少執(zhí)行一次,2,判定覆蓋,每一判定的每個,分支,至少執(zhí)行一次,3,條件覆蓋,每一判定中的每個,條件,，分別按,“,真,”,、,,“,假,”,至少各執(zhí)行一次,4,判定/條件覆蓋,同時滿足,判定覆蓋,和,條件覆蓋,的要求,5,條件組合覆蓋,求出判定

55、中,所有條件的各種可能組合,,值，每一可能的條件組合至少執(zhí)行一次,邏輯覆蓋測試的,5,種標準,弱,,,,,,,,,,,強,75,1.,語句覆蓋,使程序中每個語句至少執(zhí)行一次。,開始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,只需設計一個測試用例,:,,,輸入數(shù)據(jù)：,A=2,，,,,B=0,，,,,X=4,,,即達到了語句覆蓋。,語句覆蓋是,最弱,的邏輯覆蓋,,（如：,AND,寫成,OR,，,X>1,,寫成,,X <1,,查不出來,）,76,,2,、 判定覆蓋,(,分支覆蓋,),使每個判定的真假分支都至少執(zhí)行一

56、次。,開始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,可設計兩組測試用例,:,,A=3,，,B=0,，,X=3,,可覆蓋,c,、,d,分支,,,A=2,，,B=1,，,X=1,,可覆蓋,b,、,e,分支,,,兩組測試用例可覆蓋所有判定的真假分支,,判定覆蓋仍是,弱,的邏輯覆蓋，只覆蓋了全部路徑的一半。,77,3,、條件覆蓋,使每個判定的每個條件的可能取值至少執(zhí)行一次。,開始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,滿足條件

57、,:,T1,T1,,,T2,T2,,T3,T3,,T4,T4,第一判定表達式,:,,設條件,A>1,取真 記為,T1,,,,假,,T1,,,條件,B=0,取真 記為,T2,,,,假,,T2,,第二判定表達式,:,,設條件,A=2,取真 記為,T3,,,,假,,T3,,,條件,X>1,取真 記為,T4,,,,假,,T4,78,測試用例 通過 滿足的 覆蓋,,A B X,路徑 條件 分支,,1 0 3,abe,T1,T2,T3,T4,b,e,,2 1 1,abe,T1,T2,T3,T4,b,e,,,,,兩個測試用例

58、覆蓋了四個條件八種可能取值。,,未覆蓋,c,、,d,分支，不滿足判定覆蓋的要求,.,,,條件覆蓋不一定包含判定覆蓋,,判定覆蓋也不一定包含條件覆蓋,,(A>1) AND (B=0),(A=2) OR (X>1),X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,79,4.,判定,/,條件覆蓋,選取足夠多的測試用例，使判斷中的每個條件的所有可能取值至少執(zhí)行一次，同時每個判斷本身的所有可能判斷結果至少執(zhí)行一次,.,,開始,(A>1) AND (B=0),(A=2) OR (X>1),返回,X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,滿足條件,:,T1,T1,,,T2,T2

59、,,T3,T3,,T4,T4,80,測試用例 通過 滿足的條件 覆蓋,,A B X,路徑 分支,,2 0 4 ace T1,T2,T3,T4,c,e,,1 1 1,abd,T1,T2,T3,T4,b,d,,能同時滿足判定、條件兩種覆蓋標準的取值,5,、條件組合覆蓋,,所有可能的條件取值組合至少執(zhí)行一次,,,A>1, B=0,,A>1, B≠0,,A≯1, B=0,,A≯1, B≠0,,A=2, X>1,,A=2, X≯1,,A≠2, X>1,,A≠2, X≯1,測試用例

60、通過 滿足的 覆蓋,,A B X,路徑 條件 分支,,2 0 4 ace T1,T2,T3,T4,c,e,,2 1 1,abe,T1,T2,T3,T4,b,e,,1 0 2,abd,T1,T2,T3,T4,b,d,,1 1 1,abd,T1,T2,T3,T4,b,d,,(A>1) AND (B=0),(A=2) OR (X>1),X=X/A,X=X+1,F,F,T,T,a,b,d,c,e,82,以上根據(jù)測試數(shù)據(jù)對源程序,語句檢測,的詳盡程度，簡單討論了幾種邏輯覆蓋標準。在上面的分析過程中常常談到測試數(shù)據(jù)執(zhí)行的程序路

61、徑，顯然，測試數(shù)據(jù)可以檢測的程序路徑的多少，也反映了對程序測試的詳盡程度。從對,程序路徑的覆蓋程度,分析，能夠提出下述一些主要的邏輯覆蓋標準。,語句覆蓋法評述,83,6.,點覆蓋,,圖論中點覆蓋的概念定義如下：,,如果連通圖,G,的子圖,G′,是連通的，而且包含,G,的所有結點，則稱,G′,是,G,的點覆蓋。,,在第,5,章中已經(jīng)講述了從程序流程圖導出流圖的方法。在正常情況下流圖是連通的有向圖。滿足點覆蓋標準要求選取足夠多的測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖的每個結點一次，由于流圖的每個結點與一條或多條語句相對應，顯然，,點覆蓋標準和語句覆蓋標準是相同的,。,84,7.,邊覆蓋,,圖論中邊

62、覆蓋的定義是：,,如果連通圖,G,的子圖,G″,是連通的，而且包含,G,的所有邊，則稱,G″,是,G,的邊覆蓋。,,為了滿足邊覆蓋的測試標準，要求選取足夠多測試數(shù)據(jù)，使得程序執(zhí)行路徑至少經(jīng)過流圖中每條邊一次。通常邊覆蓋和判定覆蓋是一致的。,,8.,路徑覆蓋,,路徑覆蓋的含義是，選取足夠多測試數(shù)據(jù)，使程序的每條可能路徑都至少執(zhí)行一次,(,如果程序圖中有環(huán)，則要求每個環(huán)至少經(jīng)過一次,),。,85,7.6.2,控制結構測試,1.,基本路徑測試,,2.,條件測試,,3.,循環(huán)測試,1.,基本路徑測試,方法概要,,“基本路徑測試”是,McCabe,提出的基于“程序環(huán)形復雜度”來確定程序中路徑進行測試的一

63、種控制結構測試方法，屬于白盒測試技術。,,設計測試用例時，先計算程序的環(huán)形復雜度，以環(huán)形復雜度為指南，定義執(zhí)行路徑的基本集合，然后從該基本集合導出測試用例。,,覆蓋能力,,所設計出的測試用例可保證程序中的每一條語句至少執(zhí)行一次（語句覆蓋），且每個條件語句在執(zhí)行時分別取真、假值至少一次（判定覆蓋、或條件覆蓋（如果拆成元條件））。,87,基本路徑測試步驟,,根據(jù)過程設計結果轉(zhuǎn)化成程序相應的流圖,,按照教材,6.4,節(jié)中的方法。,,計算程序流圖的環(huán)路復雜度,,由于程序流圖的“環(huán)路復雜度”,>=,程序“獨立路徑基本集”中的獨立路徑條數(shù)，這可確保程序中每個邊至少經(jīng)過一次測試所必需的測試用例數(shù)目的上界。,

64、,確定線性獨立路徑的基本集合,,按照圖論，一條獨立路徑至少包含有一條在其他獨立路徑中從未有過的邊。,,在程序流圖中，一條獨立路徑至少包含有一條在其他獨立路徑中從未出現(xiàn)過的新語句或新條件。,,設計可強制執(zhí)行基本基本集合中每條路徑的測試用例,,根據(jù)判斷結點給出的條件，選擇適當?shù)臄?shù)據(jù)以保證每一條路徑可以被測試到,—,用邏輯覆蓋（語句覆蓋、判定覆蓋、條件覆蓋、等,……,）的方法。,例,:,求平均值過程,——,第一步,:,畫流圖,PROCEDURE average,,/*,該過程計算不超過,100,個在規(guī)定值域內(nèi)的有效數(shù)字的平均值；,,同時計算有效數(shù)字的總和和個數(shù),;*/,,INTERFACE RETU

65、RES average,,total.input,,,total.valid,;,,INTERFACE ACCEPTS value, minimum, maximum;,,,,TYPE value[1…100] IS SCALAR ARRAY;,,TYPE average,,total.input,,,total.valid,;,,minimum, maximum, sum IS SCALAR;,,TYPE i IS INTERGE;,,,1 i=1;,,,total.input,=,total.valid,=0;,,sum=0;,,2,3 DO WHILE,value[i,]-99

66、9 AND,total.input,<100,,4 increment,total.input,by 1;,,5,6 IF,value[i,]>minimum AND,value[i,0,,11 THEN average=sum/,total.valid,;,,12 ELSE average=-999;,,13 ENDIF,,END average,圖,7.6,求平均值過程的流圖,求平均值過程的,PDL,例,:,求平均值過程,——,第二步,:,求環(huán)形復雜度,環(huán)形復雜度,,,=,邊數(shù),-,節(jié)點數(shù),+2,,= 17-13+2,,= 6,例,:,求平均值過程,——,第三步,:,求獨立路徑集,由于環(huán)形復雜度為,6,，因此最多有,6,條獨立路徑：,,路