第5章 結構化的實現(xiàn)

1

軟件工程

SoftwareEngineering

2第5章結構化的實現(xiàn)結構化實現(xiàn)：編碼測試編碼：把軟件設計翻譯成計算機可以理解的形式——用某種程序設計語言書寫的程序。測試：在軟件投入生產性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。結構化實現(xiàn)結構化實現(xiàn)工作的內容和步驟設計階段所設計定義的每一個模塊進行程序過程設計、編碼和單元測試工作。按結構圖將各軟件模塊組裝起來，進行組裝測試、確認測試和系統(tǒng)測試等工作。交付用戶使用并根據(jù)使用情況進行維護。在每個階段都必須按照有關規(guī)范編寫相應的說明書或報告。結構化實現(xiàn)結構化實現(xiàn)工作的內容和步驟結構化實現(xiàn)結構化實現(xiàn)階段的主要任務：按總體設計方案購置和安裝計算機網絡系統(tǒng)。軟件準備。人員培訓。主要是用戶培訓。數(shù)據(jù)準備。沒有一定基礎的數(shù)據(jù)準備，系統(tǒng)調試就不能很好的運行。試運行。6結構化的實現(xiàn)編碼軟件測試基礎軟件測試方法軟件測試步驟單元測試集成測試確認測試軟件調試7編碼程序設計語言的選擇原則編碼風格8程序設計語言的選擇原則在選擇編程語言時，可以考慮以下因素。應用領域：目標系統(tǒng)的應用領域不同，需要采取的系統(tǒng)開發(fā)范型也不同，所以要考慮支持相應范型的編程語言。系統(tǒng)用戶的要求。軟件運行環(huán)境?？傻玫降能浖ぞ?。工程規(guī)模。軟件可移植性。程序員的知識。

9程序設計語言的選擇原則C語言：適合系統(tǒng)底層實現(xiàn)。C語言、匯編語言、Ada：適合實時應用、或很特殊的復雜算法、代碼優(yōu)化要求高的領域。FORTRAN：工程領域，復雜的數(shù)值計算。Java：適合平臺無關的應用、網絡編程應用。Dephi：適合信息系統(tǒng)應用。PROLOG和LISP：人工智能領域。SQLServer、Oracle、Access：數(shù)據(jù)庫操作。程序的復雜性及度量1.代碼行度量法度量程序的復雜性，最簡單的方法就是統(tǒng)計程序的源代碼行數(shù)。常用的軟件成本估量計量單位：源代碼行工作量：一項任務所需的程序員平均工作時間。單位是人月、人年或人日。軟件生產率：開發(fā)全過程中單位勞動量能夠完成的平均軟件數(shù)量。程序的復雜性及度量2.McCabe度量法由ThomasMcCabe提出的一種基于程序控制流的復雜性度量方法。先畫出流圖，然后用該圖的環(huán)路數(shù)作為程序復雜性的度量值。流圖是退化的程序流程圖。把流程圖中的每一個處理符號都退化成一個結點，原來連接不同處理符號的流線變成連接不同結點的有向弧，這樣的有向圖叫做流圖。有向圖G結點數(shù)n=6弧數(shù)m=9環(huán)的個數(shù)V(G)=m-n+2=512環(huán)路復雜度取決于程序控制結構的復雜度。當程序的分支數(shù)目或循環(huán)數(shù)目增加時其復雜度也增加。對于復雜度超過10的程序，應分成幾個小程序，以減少程序中的錯誤。這種度量的缺點：不同種類的控制流的復雜度不能區(qū)分。簡單IF語句與循環(huán)語句的復雜性是一樣的。嵌套IF語句與簡單CASE的復雜性是一樣的。模塊接口當成一個簡單分支一樣處理。一個具有1000行的順序程序與一行語句的復雜性相同。1314編碼風格1.源程序文檔化編寫源程序文檔化的原則為：1）標識符應盡量具有實際意義2)程序應加注釋主要內容有：說明每個模塊的用途、功能。說明模塊的接口形式、參數(shù)描述及從屬模塊的清單。該模塊的數(shù)據(jù)描述：特殊的數(shù)組或變量的說明、約束或其他信息。開發(fā)歷史：指程序的編寫者、審閱者姓名及日期、修改說明及日期。152.數(shù)據(jù)說明變量、常量聲明時說明其用途變量命名時采用一定的規(guī)范說明語句中變量排列有序化使用注釋說明復雜數(shù)據(jù)結構例如：變量命名可采用匈牙利命名法nLength,szUserName常量采用全大寫方式變量說明順序示例： ①常量說明②簡單變量類型說明 ③數(shù)組說明④公用數(shù)據(jù)塊說明⑤所有的文件說明編碼風格163.語句構造不要把多個語句寫在一行避免多層循環(huán)或條件嵌套語句清晰采用縮進統(tǒng)一風格編碼風格17一行中包括了多個語句，掩蓋了程序的循環(huán)結構和條件結構，使其可讀性變得很差FORI:=1TON－1DOBEGINT:=I；FORJ:=I＋1TONDOIFA[J]＜A[T]THENT:=J；IFT≠ITHENBEGINWORK:=A[T]；A[T]:=A[I]；A[I]:=WORK；ENDEND；編碼風格18FORI:=1TON-1DO//改進布局

BEGIN

T:=I；

FORJ:=I＋1TONDO

IFA[J]＜A[T]THENT:=J；

IFT≠ITHEN

BEGIN

WORK:=A[T]；

A[T]:=A[I]；

A[I]:=WORK；

ENDEND；編碼風格19階梯式布局IF（…）

THEN

IF（…）

THEN

……

ELSE

……

ENDIF

……

ELSE

……

ENDIF編碼風格20程序編寫首先應當考慮清晰性例如，有一個用Pascal語句寫出的程序段：A[I]:=A[I]＋A[J]；A[J]:=A[I]－A[J]；A[I]:=A[I]－A[J]； WORK:=A[J]；A[J]:=A[I]；A[I]:=WORK；編碼風格214.輸入/輸出對所有輸入數(shù)據(jù)進行檢查輸入采用簡單、一致的格式輸入提示輸出數(shù)據(jù)統(tǒng)一格式，說明簡潔無二義……編碼風格225.效率效率是靠良好的設計來保證的。程序運行時間減少嵌套循環(huán)，避免多維數(shù)組，減少類型轉換、采用占用內存少的數(shù)據(jù)類型。內存采用優(yōu)化的算法輸入/輸出效率設計簡單的人機接口編碼風格23軟件測試背景軟件是人編的—所以不完美實例:1994-1995,迪斯尼的獅子王系統(tǒng)不支持問題1999年12月3日,美國航天局火星極地登陸飛船失蹤1991年愛國者導彈防御系統(tǒng)系統(tǒng)時鐘錯誤積累造成跟蹤系統(tǒng)失去精確度千年蟲,世界各地解決2000年錯誤超過數(shù)億美元24千年蟲(Y2K)在上個世紀70年代，程序員為了節(jié)約非常寶貴的內存資源和硬盤空間，在存儲日期時，只保留年份的后兩位，如“1980”被存為“80”。當2000年到來的時候，問題就會出現(xiàn)，比如銀行存款程序在計算利息時，應該用現(xiàn)在的日期“2000年1月1日”減去當時存款的日期，比如“1989年1月1日”，結果應該是11年，如果利息是3%，銀行要付給顧客每100元，大約66元利息。如果程序沒有糾正年份只存儲兩位的問題，其存款年數(shù)就變?yōu)?89年，變成顧客反要付銀行巨額利息。就是為了這樣一個簡單的設計缺陷，全世界付出幾十億美元。25軟件測試的背景1963年,美國飛往火星的火箭爆炸,損失$10million。原因:FORTRAN循環(huán)：

DO5I=1,3誤寫為DO5I=1.326軟件測試的背景在整個軟件開發(fā)中，測試工作量一般占30%～40%，甚至≥50%。在人命關天的軟件(如飛機控制、核反應堆等）中，測試所花費的時間往往是其它軟件工程活動時間之和的三到五倍。27Bug有人說，軟件測試就是在尋找軟件中的Bug。28關于Bug的一個有趣的小故事故事發(fā)生在1945年9月的一天，一個炎熱的下午，機房是一間第一次世界大戰(zhàn)時建造的老建筑，沒有空調，所有窗戶都敞開著。Hopper正領著她的研究小組夜以繼日地工作，研制一臺稱為“MARKII”的計算機，它使用了大量的繼電器（電子機械裝置，那時還沒有使用晶體管），一臺不是純粹的電子計算機。突然，MARKII死機了。研究人員試了很多次還是啟動不來，然后就開始用各種方法找問題，看問題究竟出現(xiàn)在哪里，最后定位到板子F第70號繼電器出錯。Hopper觀察這個出錯的繼電器，驚奇地發(fā)現(xiàn)一只飛蛾躺在中間，已經被繼電器打死。她小心地用攝子將蛾子夾出來，用透明膠布帖到“事件記錄本”中，并注明“第一個發(fā)現(xiàn)蟲子的實例”，然后計算機又恢復了正常。從此以后，人們將計算機錯誤戲稱為臭蟲（Bug），而把找尋錯誤的工作稱為“找臭蟲”（Debug）。GraceHopper的事件記錄本，連同那個飛蛾，現(xiàn)在都陳列在美國歷史博物館中。

29問題在哪里？

沒有足夠測試缺乏測試平臺不正確的測試環(huán)境缺少集成測試缺少性能測試缺少強度測試缺少可靠性測試

……微軟的經驗Windows95有1000萬行代碼Windows2000有5000萬行代碼，3000多個工程師，幾百個小團隊。Exchange2000和Windows2000開發(fā)人員結構Exchange2000Windows2000項目經理25人約250人開發(fā)人員140人約1700人測試人員350人約3200人測試人員/開發(fā)人員2.51.931軟件測試行業(yè)前景軟件測試行業(yè)前景看好，需求量已超過30萬。有數(shù)據(jù)顯示，目前軟件測試行業(yè)人才需求量已超過30萬，并且仍在以每年20%的速度增加。中國軟件協(xié)會秘書長胡昆山表示，現(xiàn)階段，我國軟件測試基礎人才不足，已成為制約我國軟件產業(yè)發(fā)展的瓶頸。軟件測試人才是職場的多面手，需要具備縝密的邏輯思維能力、全面的測試技術能力、較強的責任心和團隊合作精神，以及出色的溝通能力等職業(yè)素質。32軟件測試基礎軟件測試目標軟件測試準則軟件測試方法軟件測試步驟功能測試和性能測試軟件測試工具軟件測試管理流程33軟件測試目標測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤。好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤。成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

34軟件測試目標程序測試能證明錯誤的存在,但不能證明錯誤不存在。測試的目的是發(fā)現(xiàn)程序中的錯誤，是為了證明程序有錯,而不是證明程序無錯。35軟件測試目標如果軟件中的問題沒有人發(fā)現(xiàn)，那么它算不算軟件缺陷？古諺：“一片樹葉飄落在森林中沒有人聽見，誰能說它發(fā)出了聲音？”由于不能報告沒有看見的問題，因此，沒有看見就不能說存在軟件缺陷。只有看到了，才能斷言軟件缺陷。36測試的目的是說明程序正確地執(zhí)行它應有的功能”這種說法正確嗎？例：程序Triangle，輸入三個整數(shù)，表示一個三角形的三個邊長，該程序產生一個結果，指出該三角形是等邊三角形、等腰三角形還是不等邊三角形。為說明其能正確執(zhí)行它的功能，可使用“測試用例”(3,4,5),(5,5,6),(6,6,6),程序都能給出正確結果，是否就可認為程序是正確的？軟件測試目標37對測試的理解編程大師說：“任何一個程序，無論它多么小，總存在著錯誤?！背鯇W者不相信大師的話，他問：“如果一個程序小得只執(zhí)行一個簡單的功能，那會怎樣？”“這樣的一個程序沒有意義，”大師說，“但如果這樣的程序存在的話，操作系統(tǒng)最后將失效，產生一個錯誤?！钡鯇W者不滿足，他問：“如果操作系統(tǒng)不失效，那么會怎樣？”“沒有不失效的操作系統(tǒng)，”大師說，“但如果這樣的操作系統(tǒng)存在的話，硬件最后將失效，產生一個錯誤。”初學者仍不滿足，再問：“如果硬件不失效，那么會怎樣？”大師長嘆一聲道：“沒有不失效的硬件。但如果這樣的硬件存在的話，用戶就會想讓那個程序做一件不同的事，這件事也是一個錯誤?！睕]有錯誤的程序世間難求。[編程之道（郭海等譯），清華大學出版社]38（1）所有的測試都應追溯到用戶需求最嚴重的錯誤(從用戶角度)是那些導致軟件無法滿足需求的錯誤。軟件測試的準則39（2）應該在測試開始之前的相當長時間，就制定出測試計劃。概要設計時應完成測試計劃。軟件測試不等于程序測試，軟件測試應貫穿于軟件定義與開發(fā)的整個期間。軟件測試的準則40軟件測試的準則（3）把Pareto原理應用于軟件測試。Pareto原理告訴我們，測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。

41軟件測試的準則（4）測試應該從“小規(guī)?！遍_始，并逐步進行“大規(guī)模”測試。（5）窮舉測試是不可能的。例Sum(inta,intb,intc) 假定int類型為16位整數(shù)

{ 需要測試216*216*216次

return(a+b+c); 每次1ms,約要1萬年

}42（6）為了達到最佳的測試效果，應該由獨立的第三方來從事測試工作。開發(fā)和測試隊伍分別建立。軟件測試的準則43軟件測試是有風險的行為軟件數(shù)量遺漏軟件缺陷數(shù)目測試費用測試中測試后測試工作量最優(yōu)測量量44軟件測試方法靜態(tài)測試方法動態(tài)測試方法白盒測試方法黑盒測試方法軟件測試方法45靜態(tài)測試靜態(tài)測試技術：不實際運行程序，而是通過檢查和閱讀等手段來發(fā)現(xiàn)錯誤并評估代碼質量的軟件測試技術。靜態(tài)測試約可找出30～70%的邏輯設計錯誤。方法：走查：WalkThrough審查：Inspection評審：ReviewMichaelFaganIBM46靜態(tài)測試-走查走查：開發(fā)組內部進行的，主要是個人通過檢查和閱讀等手段來查找錯誤的活動。經驗：限時避免跑題不要現(xiàn)場修改檢查要點邏輯錯誤代碼標準/規(guī)范/風格47靜態(tài)測試-審查審查：開發(fā)組內部進行的，分配了相關的角色，采用講解、提問并使用Checklist方式進行的查找錯誤的活動。經驗：以會議的形式，制定會議目標、流程和規(guī)則，結束后要編寫報告。參加人員：經驗豐富的開發(fā)人員、和本模塊相關的開發(fā)人員、本項目組的新人。由另外一名開發(fā)者進行講解、其他開發(fā)者主要按照Checklist進行提問并填表、本模塊開發(fā)者回答問題并記錄。不要現(xiàn)場修改。檢查要點設計需求代碼標準/規(guī)范/風格48靜態(tài)測試-評審評審：開發(fā)組、測試組和相關人員(QA、產品經理等)聯(lián)合進行的，采用講解、提問并使用Checklist方式進行的查找錯誤的活動。經驗：以會議的形式，制定會議目標、流程和規(guī)則，結束后要編寫報告。相關資料要在會議前下發(fā)并閱讀。參加人員：經驗豐富的開發(fā)人員、和本模塊相關的開發(fā)人員、測試組和相關人員。由另外一名開發(fā)者進行講解、其他開發(fā)者主要按照Checklist進行提問并填表、本模塊開發(fā)者回答問題并記錄。不要現(xiàn)場修改。檢查要點設計需求代碼標準/規(guī)范/風格文檔的完整性和一致性49動態(tài)測試動態(tài)測試：通過運行軟件來檢驗軟件的動態(tài)行為和運行結果的正確性動態(tài)測試的兩個基本要素：被測試程序測試數(shù)據(jù)（測試用例）50動態(tài)測試白盒測試（結構測試）測試者完全知道程序的內部結構和處理算法黑盒測試（功能測試）測試者完全不知道程序的內部結構和處理算法51白盒測試—基于代碼的測試52黑盒測試—基于需求的測試軟件輸入輸出53CBAD-A:只能用黑盒測試發(fā)現(xiàn)的錯誤-B:只能用白盒測試發(fā)現(xiàn)的錯誤-C:兩種方法都能發(fā)現(xiàn)的錯誤-D:兩種方法都不能發(fā)現(xiàn)的錯誤黑盒測試與白盒測試能發(fā)現(xiàn)的錯誤54窮舉測試例:輸入三角形的三條邊長可采用的測試用例數(shù)(設字長16位)=216X216X216≈3X1014執(zhí)行時間:

設測試一次需1ms，共需一萬年。黑盒測試黑盒測試55窮舉測試例：從A到B的可能路徑51+52+..+519+520≈1014執(zhí)行時間:設測試一次需2ms

窮舉測試需5億年。不論黑盒還是白盒測試都不能進行窮盡測試AB白盒測試56白盒測試技術白盒測試技術將介紹：邏輯覆蓋基本路徑測試循環(huán)測試57白盒測試技術--邏輯覆蓋邏輯覆蓋是設計白盒測試方案的一種技術。設計測試方案是測試階段的關鍵技術問題。測試方案包括具體的測試目的(例如，要測試的具體功能)，應該輸入的測試數(shù)據(jù)和預期的輸出結果。測試數(shù)據(jù)和預期的輸出結果稱為測試用例。58不同的測試數(shù)據(jù)發(fā)現(xiàn)程序錯誤的能力差別很大，為了提高測試效率降低測試成本，應該選用高效的測試數(shù)據(jù)。因為不可能進行窮盡的測試，選用少量“最有效的”測試數(shù)據(jù)，做到盡可能完備的測試就更重要了。有選擇地執(zhí)行程序中某些最有代表性的通路是對窮盡測試的唯一可行的替代辦法。邏輯覆蓋是對一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。59測試數(shù)據(jù)從覆蓋源程序語句的詳盡程度分析，大致有以下一些不同的覆蓋標準。 語句覆蓋判定覆蓋條件覆蓋判定/條件覆蓋條件組合覆蓋路徑覆蓋60測試數(shù)據(jù)：A=2,B=0,X=4語句覆蓋是最弱的邏輯覆蓋1.語句覆蓋語句覆蓋的含義是，選擇足夠多的測試數(shù)據(jù)，使被測程序中每個語句至少執(zhí)行一次。61測試數(shù)據(jù)：A=3,B=0,X=1

覆蓋sacbdA=2,B=1,X=3

覆蓋sabed2.判定覆蓋判定覆蓋又叫分支覆蓋，使每個判定的真假分支都至少執(zhí)行一次判定覆蓋仍是弱的邏輯覆蓋只覆蓋了全部路徑的一半62測試數(shù)據(jù)：A=2,B=0,X=4

滿足A>1,B=0,A=2,X>1條件 覆蓋sacbedA=1,B=1,X=1

滿足A≤1,B≠0,A≠2,X≤1條件 覆蓋sabda點各種情況：A>1,A≤1,B=0,B≠0

b點各種情況：A=2,A≠2,X>1,X≤13.條件覆蓋判定表達式中的每個條件都取到各種可能的結果。條件覆蓋強于判定覆蓋條件覆蓋的每個條件都取到了兩個不同的結果判定覆蓋的每個判定表達式都取到了兩個不同的結果63測試數(shù)據(jù)：A=2,B=0,X=1

滿足A>1,B=0,A=2,X≤1條件 覆蓋sacbedA=1,B=1,X=2

滿足A≤1,B≠0,A≠2,X>1條件 覆蓋sabed條件覆蓋不一定滿足判定覆蓋第二個判定表達式的值為假的情況沒有考慮。64判定覆蓋不一定包含條件覆蓋。條件覆蓋也不一定包含判定覆蓋。一種能同時滿足這兩種覆蓋標準的是： 判定/條件覆蓋。65測試數(shù)據(jù)：A=2,B=0,X=4

覆蓋sacbedA=1,B=1,X=1

覆蓋sabd4.判定/條件覆蓋判定表達式中的每個條件都取到各種可能的值，而且每個判定表達式也都取到各種可能的結果能同時滿足判定、條件兩種覆蓋。判定/條件覆蓋不一定滿足路徑覆蓋。665.條件組合覆蓋

每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次。

測試數(shù)據(jù)：A=2,B=0,X=4 1，5組合，覆蓋sacbedA=2,B=1,X=1 2，6組合，覆蓋sabedA=1,B=0,X=2 3，7組合，覆蓋sabedA=1,B=1,X=1 4，8組合，覆蓋sabd八種組合：

(1)A>1,B=0(2)A>1,B≠0(3)A≤1,B=0(4)A≤1,B≠0

(5)A=2,X>1(6)A=2,X≤1(7)A≠2,X>1(8)A≠2,X≤1676.路徑覆蓋

覆蓋每一個可能的路徑。測試數(shù)據(jù)：A=1,B=1,X=1

覆蓋sabdA=1,B=1,X=2

覆蓋sabedA=3,B=0,X=1

覆蓋sacbdA=2,B=0,X=4

覆蓋sacbed686種覆蓋標準的對比發(fā)現(xiàn)錯誤能力覆蓋標準要求弱強語句覆蓋每條語句至少執(zhí)行一次判定覆蓋每個判定的每個分支至少執(zhí)行一次條件覆蓋每個判定的每個條件應取到各種可能的值判定/條件覆蓋同時滿足判定覆蓋和條件覆蓋條件組合覆蓋每個判定中各條件的每一種組合至少出現(xiàn)一次路徑覆蓋使程序中每一條可能的路徑至少執(zhí)行一次69流圖流圖在設計測試方案時，往往需要仔細分析程序的控制流。為了突出表示程序的控制流，可以使用流圖(也稱為程序圖)。流圖僅僅描繪程序的控制流程，它完全不表現(xiàn)對數(shù)據(jù)的具體操作以及分支或循環(huán)的具體條件。70流圖在流圖中用圓表示節(jié)點，一個圓代表一條或多條語句。程序流程圖中的一個處理框序列和一個菱形判定框，可以映射成流圖中的一個節(jié)點。流圖中的箭頭線稱為邊，它和程序流程圖中的箭頭線類似，代表控制流。在流圖中一條邊必須終止于一個節(jié)點，即使這個節(jié)點并不代表任何語句(實際上相當于一個空語句)。由邊和節(jié)點圍成的面積稱為區(qū)域，當計算區(qū)域數(shù)時應該包括圖外部未被圍起來的那個區(qū)域。71流圖圖把程序流程圖映射成流圖(a)程序流程圖；(b)流圖72流圖PDLprocedure:sort1：dowhilerecordsremain

readrecord;2：ifrecordfield1=03：thenprocessrecord;

storeinbuffer；

incremertcounter;4：elseifrecordfield2=05：thenresetcounter;6：elseprocessrecord;

storeinfile;7a：endif

endif7b：enddo8：end圖

由PDL翻譯成的流圖73白盒測試技術--基本路徑測試基本路徑測試基本路徑測試是TomMcCabe提出的一種白盒測試技術。通過分析由控制構造的環(huán)路的復雜性，導出基本路徑集合，從而設計測試用例，保證這些路徑至少通過一次。74設計基本路徑測試的步驟（1）以詳細設計或源程序為基礎，導出程序流程圖的拓撲結構——程序圖。（a）程序流程圖（b）程序圖圖：程序流程圖和程序圖75（2）程序圖G的環(huán)路復雜性V(G)的計算例如，圖（b）的V(G)=4，還可以按如下兩種方法計算：V(G)=判定結點數(shù)+1=3+1=4。V(G)=邊的數(shù)量-節(jié)點數(shù)量+2=11-9+2=4。（3）確定只包含獨立路徑的基本路徑集。例如，在圖（b）所示的圖中，一組獨立的路徑是：path1：1—11path2：1—2—3—4—5—10—1—11path3：1—2—3—6—8—9—10—1—11path4：1—2—3—6—7—9—10—1—11（4）設計測試用例，確?；韭窂郊现忻織l路徑的執(zhí)行。76使用基本路徑測試技術設計測試用例的步驟如下：1.根據(jù)過程設計結果畫出相應的流圖2.計算流圖的環(huán)形復雜度3.確定線性獨立路徑的基本集合4.設計可強制執(zhí)行基本集合中每條路徑的測試用例77白盒測試技術--循環(huán)測試循環(huán)測試循環(huán)測試是一種白盒測試技術，它專注于測試循環(huán)結構的有效性。在結構化的程序中通常只有三種循環(huán)：簡單循環(huán)串接循環(huán)嵌套循環(huán)78圖三種循環(huán)79白盒測試技術--循環(huán)測試1.簡單循環(huán)使用下列測試集來測試簡單循環(huán)，其中n是允許通過循環(huán)的最大次數(shù)。跳過循環(huán)。只通過循環(huán)一次。通過循環(huán)兩次。通過循環(huán)m次，其中m＜n-1。通過循環(huán)n-1，n，n+1次。for(i=1;i<=n;i++){ …}80白盒測試技術--循環(huán)測試2.嵌套循環(huán)如果把簡單循環(huán)的測試方法直接應用到嵌套循環(huán)，可能的測試數(shù)就會隨嵌套層數(shù)的增加按幾何級數(shù)增長，這會導致不切實際的測試數(shù)目。B.Beizer提出了一種能減少測試數(shù)的方法。從最內層循環(huán)開始測試，把所有其他循環(huán)都設置為最小值。對最內層循環(huán)使用簡單循環(huán)測試方法，而使外層循環(huán)的迭代參數(shù)(例如，循環(huán)計數(shù)器)取最小值，并為越界值或非法值增加一些額外的測試。由內向外，對下一個循環(huán)進行測試，但保持所有其他外層循環(huán)為最小值，其他嵌套循環(huán)為“典型”值。繼續(xù)進行下去，直到測試完所有循環(huán)。for(i=1;i<=m;i++) for(j=1;j<=n;j++){ …}設i=1，對內層循環(huán)做簡單測試81白盒測試技術--循環(huán)測試

3.串接循環(huán)如果串接循環(huán)的各個循環(huán)都彼此獨立，則可以使用前述的測試簡單循環(huán)的方法來測試串接循環(huán)。如果兩個循環(huán)串接，而且第一個循環(huán)的循環(huán)計數(shù)器值是第二個循環(huán)的初始值，則這兩個循環(huán)并不是獨立的。當循環(huán)不獨立時，建議使用測試嵌套循環(huán)的方法來測試串接循環(huán)。82黑盒測試技術黑盒測試著重測試軟件的功能需求。黑盒測試并不能取代白盒測試技術，它是與白盒測試互補的方法。83黑盒測試技術黑盒測試力圖發(fā)現(xiàn)下述類型的錯誤：①功能不正確或遺漏了功能；②界面錯誤；③數(shù)據(jù)結構錯誤或外部數(shù)據(jù)庫訪問錯誤；④性能錯誤；⑤初始化和終止錯誤。白盒測試在測試過程的早期階段進行，而黑盒測試主要用于測試過程的后期。黑盒測試故意不考慮程序的控制結構，而把注意力集中于信息域。84黑盒測試方法等價類劃分邊界值分析錯誤推測因果圖綜合策略85黑盒測試--等價類劃分等價類是指某個輸入域的子集合。在該子集合中，各個輸入數(shù)據(jù)對于揭露程序中的錯誤都是等效的，并合理地假定：測試某等價類的代表值等價于對這一類其他值的測試。如果某個等價類中的一個數(shù)據(jù)作為測試數(shù)據(jù)進行測試查出了錯誤，那么使用這一等價類中的其他數(shù)據(jù)進行測試也會查出同樣的錯誤；若使用某個等價類中的一個數(shù)據(jù)作為測試數(shù)據(jù)進行測試沒有查出錯誤，則使用這個等價類中的其他數(shù)據(jù)也同樣查不出錯誤。86等價類的劃分有兩種不同的情況:（1）有效等價類：是指對于程序的規(guī)格說明來說，是合理的、有意義的輸入數(shù)據(jù)構成的集合。利用它，可以檢驗程序是否實現(xiàn)了規(guī)格說明預先規(guī)定的功能和性能。（2）無效等價類：是指對于程序的規(guī)格說明來說，是不合理的、無意義的輸入數(shù)據(jù)構成的集合。程序員主要利用這一類測試用例檢查程序中功能和性能的實現(xiàn)是否有不符合規(guī)格說明要求的地方。在設計測試用例時，要同時考慮有效等價類和無效等價類的設計。黑盒測試--等價類劃分87劃分等價類的規(guī)則：(1)如果輸入條件規(guī)定了取值范圍或值的個數(shù)，可定義一個有效等價類和兩個無效等價類。例：輸入值是學生成績，范圍是0～100無效等價類成績>1000100

有效等價類0≤成績≤100

無效等價類成績<0黑盒測試--等價類劃分88黑盒測試--等價類劃分（2）如果規(guī)格說明規(guī)定了數(shù)據(jù)值的集合，或者是規(guī)定了“必須如何”的條件，這時可確定一個有效等價類和一個無效等價類。例如，在C中對變量標識符規(guī)定為“以字母開頭的……串”，那么所有以字母開頭的串構成有效等價類，而不在此集合內（不以字母開頭）的串歸于無效等價類。（3）如果規(guī)格說明中規(guī)定的是一個條件數(shù)據(jù)，則可確定一個有效等價類和一個無效等價類。例如：“……成人（年滿18歲）須……”，則考慮成人為一個有效等價類；未滿18歲者為一個無效等價類。（4）如規(guī)定了輸入數(shù)據(jù)的一組值，且程序對不同輸入值做不同處理，則每個允許的輸入值是一個有效等價類，并有一個無效等價類(所有不允許的輸入值的集合)。例：輸入條件說明學歷可為:?？啤⒈究?、碩士、博士四種之一，則分別取這四個值作為四個有效等價類，另外把四種學歷之外的任何學歷作為無效等價類。（5）如果我們確知，已劃分的等價類中各元素在程序中的處理方式不同，則應將此等價類進一步劃分成更小的等價類。90黑盒測試--等價劃分用等價類劃分法設計測試用例步驟：(1)形成等價類表，每一等價類規(guī)定一個唯一的編號；(2)設計一個新的測試方案以盡可能多地覆蓋尚未被覆蓋的有效等價類，復重這一步驟直到所有有效等價類都被覆蓋為止。(3)設計一個新的測試方案，使它覆蓋一個而且只覆蓋一個尚未被覆蓋的無效等價類，重復這一步驟直到所有無效等價類都被覆蓋為止。91例1:用等價類劃分法設計測試用例例如，有一報表處理系統(tǒng)，要求用戶輸入處理報表的日期。假設日期限制在1990年1月至1999年12月，即系統(tǒng)只能對該段時期內的報表進行處理。如果用戶輸入的日期不在此范圍內，則顯示輸入錯誤信息。該系統(tǒng)規(guī)定日期由年、月的6位數(shù)字字符組成，前4位代表年，后兩位代表月。現(xiàn)用等價類劃分法設計測試用例，來測試程序的“日期檢查功能”。

如何用等價類劃分法設計測試用例，來測試程序的日期檢查功能？

92（1）劃分等價類并編號劃分成3個有效等價類，7個無效等價類，如表所示。

表：“報表日期”的輸入條件的等價類表輸入等價類合理等價類不合理等價類報表日期的類型及長度(1)6位數(shù)字字符(2)有非數(shù)字字符(3)少于6個數(shù)字字符(4)多于6個數(shù)字字符年份范圍(5)在1990~1999之間(6)小于1990(7)大于1999月份范圍(8)在1~12之間(9)等于0(10)大于1293（2）為合理等價類設計測試用例對于表中編號為1，5，8對應的3個合理等價類，用一個測試用例覆蓋。

測試數(shù)據(jù) 期望結果 覆蓋范圍

199905 輸入有效 1，5，8(1)6位數(shù)字字符(2)年在1990～1999之間(3)月在01～12之間94（3）為每一個不合理等價類至少設計一個測試用例

測試數(shù)據(jù) 期望結果 覆蓋范圍

99MAY

輸入無效 219995

輸入無效 31999005

輸入無效 4

198912 輸入無效 6

200001 輸入無效 7199900

輸入無效 9199913

輸入無效 10不能出現(xiàn)相同的測試用例本例的10個等價類至少需要8個測試用例95例2:用等價類劃分法設計測試用例用等價劃分法設計一個簡單程序的測試方案。假設有一個把數(shù)字串轉變成整數(shù)的函數(shù)。運行程序的計算機字長16位，用二進制補碼表示整數(shù)。這個函數(shù)是用C語言編寫的，它的說明如下：intstrtoint(chararray[7])96被處理的數(shù)字串是右對齊的，也就是說，如果數(shù)字串比六個字符短，則在它的左邊補空格。如果數(shù)字串是負的，則負號和最高位數(shù)字緊相鄰(負號在最高位數(shù)字左邊一位)?？紤]到C編譯程序固有的檢錯功能，測試時不需要使用長度不等于6的數(shù)組做實在參數(shù)，更不需要使用任何非字符數(shù)組類型的實在參數(shù)。97輸入等價類合理等價類不合理等價類數(shù)字字符串的類型及長度1～6個數(shù)字字符組成(最高位數(shù)字不是零)最高位數(shù)字是零最高位數(shù)字左鄰是負號的數(shù)字串(4)空字符串(全是空格)(5)左部填充的字符既不是零也不是空格(6)最高位數(shù)字右面由數(shù)字和空格混合組成；(7)最高位數(shù)字右面由數(shù)字和其他字符混合組成；(8)負號與最高位數(shù)字之間有空格。（1）劃分等價類并編號98輸出等價類合理等價類不合理等價類數(shù)字字符串的類型及長度(9)在計算機能表示的最小負整數(shù)和零之間的負整數(shù)(10)零(11)在零和計算機能表示的最大正整數(shù)之間的正整數(shù)。(12)比計算機能表示的最小負整數(shù)還小的負整數(shù)(13)比計算機能表示的最大正整數(shù)還大的正整數(shù)。若計算機字長16位，用二進制補碼表示整數(shù)，所以能表示的最小負整數(shù)是-32768，能表示的最大正整數(shù)是32767。99（2）為合理等價類設計測試用例對于表中編號為1，5，8對應的3個合理等價類，用一個測試用例覆蓋。

測試數(shù)據(jù) 期望結果 覆蓋范圍

1 1 1 000001 1 2,11 -00001 -1 3,9 000000 0 2,10

100（3）為每一個不合理等價類至少設計一個測試用例

測試數(shù)據(jù)期望結果 覆蓋范圍‘’ 錯誤——沒有數(shù)字 4‘ab1’ 錯誤——填充錯 5‘1

2’ 錯誤——無效輸入 6‘1ab2’ 錯誤——無效輸入 7‘-12’ 錯誤——負號位置錯 8-47561

錯誤——無效輸入 12132767

錯誤——無效輸入 13本例的13個等價類至少需要11個測試用例例3參看書P201/等價類劃分測試實例102黑盒測試--邊界值分析邊界值分析邊界值是指輸入等價類或輸出等價類邊界上的值。實踐經驗表明，程序往往在處理邊界情況時發(fā)生錯誤。在測試過程中，邊界值分析法是對等價類分析法的補充，專注于每個等價類的邊界值。檢查邊界情況的測試用例是比較高效的，可以查出更多的錯誤。103邊界值－基本思想最小值：Min略高于最小值：Min+正常值：Normal略低于最大值：Max－最大值：Maxa<=X1<=b||c<=X2<=d黑盒測試--邊界值分析104

邊界值分析－健壯性測試略低于最小值：Min－最小值：Min略高于最小值：Min+正常值：Normal略低于最大值：Max－最大值：Max略高于最大值：Max+a<=X1<=b||c<=X2<=d黑盒測試--邊界值分析105邊界值分析法與等價類劃分法區(qū)別：(1)邊界值分析不是從某等價類中隨便挑一個作為代表，而是等價類的每個邊界都要作為測試條件。(2)邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況被測試子域測試內點測試外點

如果在懸崖峭壁邊可以自信地安全行走，平地就不在話下。如果軟件在能力達到極限時能夠運行，那么在正常情況下就不會出什么問題。邊界與懸崖很類似黑盒測試--邊界值分析黑盒測試邊界值分析法的測試用例是由等價類的邊界值產生的，根據(jù)輸入/輸出等價類，選取稍高于邊界值或稍低于邊界值等特定情況作為測試用例。107前例中劃分等價類劃分成3個有效等價類，7個無效等價類，如表所示。

表：“報表日期”的輸入條件的等價類表輸入等價類合理等價類不合理等價類報表日期的類型及長度(1)6位數(shù)字字符(2)有非數(shù)字字符(3)少于6個數(shù)字字符(4)多于6個數(shù)字字符年份范圍(5)在1990~1999之間(6)小于1990(7)大于1999月份范圍(8)在1~12之間(9)等于0(10)大于12108表：“報表日期”邊界值分析法測試用例

輸入等價類測試用例說明測試數(shù)據(jù)期望結果選取理由報表日期的類型及長度1個數(shù)字字符5個數(shù)字字符7個數(shù)字字符有1個非數(shù)字字符全部是非數(shù)字字符6個數(shù)字字符51999519990051999.5May---199905顯示出錯顯示出錯顯示出錯顯示出錯顯示出錯顯示有效僅有一個合法字符比有效長度少1比有效長度多1只有一個非法字符6個非法字符類型及長度均有效年份范圍年份為1990年份為1999年份為1989年份為2000199001199912198912200001輸入有效輸入有效顯示出錯顯示出錯最小日期最大日期剛好小于最小日期剛好大于最大日期月份范圍月份為1月月份為12月月份＜1月份＞12199801199812199800199813輸入有效輸入有效顯示出錯顯示出錯最小月份最大月份剛好小于最小月份剛好大于最大月份黑盒測試--邊界值分析應用邊界值分析方法設計測試用例的實例

假如一個為學生標準化考試批閱試卷、產生成績報告的程序，程序的輸入文件由一些有80個字符的記錄（卡片）組成。輸入數(shù)據(jù)記錄格式如右圖所示。

把以上所有記錄分為3組:（1）標題。這一組只有一個記錄，其內容是成績報告的名字。（2）各題的標準答案。每個記錄均在第80個字符處標以數(shù)字“2”。該組的第1個記錄的第1～3個字符為試題數(shù)（取值為1～999）。第10～59個字符給出第1～50題的標準答案（每個合法字符表示一個答案）。該組的第2、第3……個記錄相應為第51～100題、第101～150題……題的標準答案。（3）學生的答卷。每個記錄均在第80個字符處標以數(shù)字“3”，每個學生的答卷在若干個記錄中給出。例如，某甲的首記錄第1～9個字符給出學生的學號，第10～59個字符列出的是某甲所作的第1～50題的解答。若試題數(shù)超過50，則其第2、第3……個記錄分別給出的第51～100題、第101～150……題的解答。然后是某乙的答卷記錄。學生人數(shù)不超過200人，試題個數(shù)不超過999。程序的輸出有4個報告。黑盒測試--邊界值分析①按學號排列的成績單，列出每個學生的成績（百分制）、名次。②按學生成績排序的成績單。③平均分數(shù)及標準偏差的報告。④試題分析報告。按試題號排列，列出各題學生答對的百分比。下面分別考慮輸入數(shù)據(jù)和輸出數(shù)據(jù)，以及邊界條件，選擇測試用例。

黑盒測試--邊界值分析黑盒測試--邊界值分析113黑盒測試--錯誤推測錯誤推測法在很大程度上靠直覺和經驗進行。它的基本想法是列舉出程序中可能有的錯誤和容易發(fā)生錯誤的特殊情況，并且根據(jù)它們選擇測試方案。例如，對于一個排序程序，列出以下幾項需特別測試的情況：（1）輸入表為空。（2）輸入表只含一個元素。（3）輸入表中所有元素均相同。（4）輸入表中已排好序。測試人員要站在用戶的角度，考慮他們要輸入的信息，而不管這些信息看起來是合法的輸入還是非法的輸入。114黑盒測試--因果圖等價類劃分和邊界值分析方法都只是孤立地考慮各個輸入數(shù)據(jù)的測試功能，而沒有考慮多個輸入數(shù)據(jù)的組合引起的錯誤。因果圖能有效地檢測輸入條件的各種組合可能會引起的錯誤。因果圖因果圖導出測試用例的步驟：分析軟件規(guī)格說明描述中哪些是原因（即輸入條件或輸入條件等價類），哪些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。在因果圖上用一些記號表明約束或限制條件。把因果圖轉換成判定表。將判定表的每一列作為依據(jù)，設計測試用例。116黑盒測試--因果圖因果圖基本符號黑盒測試--因果圖117約束符號圖118因果圖方法實例某電力公司有A、B、C、D四類收費標準,并規(guī)定：居民用電<100度/月 按A類收費≥100度/月 按B類收費動力用電<10000度/月,非高峰,B類收費≥10000度/月,非高峰,C類收費

<10000度/月,高峰,C類收費≥10000度/月,高峰,D類收費黑盒測試--因果圖119居民用電動力用電<100度/月<10000度/月高峰12345黑盒測試--因果圖

用因果圖表明輸入和輸出間的邏輯關系1I12ABC435DI4I3I2因果居民用電動力用電<100度/月<10000度/月高峰取反

用因果圖表明輸入和輸出間的邏輯關系1I12AB∨∧C435∧DI4I3I2∨∧∧∧∧因果居民用電動力用電<100度/月<10000度/月高峰把因果圖轉換為判定表組合條件條件(原因)

動作(結果)ABC123123456101100011000110000100001104101050011D000110010000測試用例123為判定表每一列設計一個測試用例:1列居民電,90度/月 A2列居民電,110度/月 B3列動力電,8000度/月, 非高峰 B4列動力電,1.2萬度/月, 非高峰 C5列動力電,0.9萬度/月, 高峰 C6列動力電,1.1萬度/月, 高峰 D

條件測試用例預期結果組合(輸入數(shù)據(jù))(輸出動作)黑盒測試--因果圖因果圖法測試實例一個處理單價為5角錢的飲料的自動售貨機測試用例的設計。其規(guī)格說明如下：若投入5角錢或1元錢的硬幣，按下“橙汁”或“啤酒”按鈕，則相應的飲料就送出來。若售貨機沒有零錢找，則一個顯示“零錢找完”的紅燈亮，這時在投入1元硬幣并按下按鈕后，飲料不送出來而且1元硬幣也退出來；若有零錢找，則顯示“零錢找完”的紅燈滅，在送出飲料的同時退還5角硬幣。因果圖法測試實例因：1.售貨機有零錢2.投入1元硬幣3.投入5角硬幣4.按下啤酒按鈕5.按下橙汁按鈕果：售貨機“零錢找完”紅燈亮退還1元硬幣退還5角硬幣送出啤酒飲料送出橙汁飲料因果圖法測試實例1.畫因果圖的條件和結果1262.因果圖—選商品、錢付清1272.因果圖—應找零錢1282.因果圖—能夠找零錢1292.因果圖—找零錢1302.因果圖—5角錢付清1312.因果圖—退1元錢1323.判定表1333.判定表—去除無效用例1343.判定表—合并判定表136黑盒測試策略的綜合運用針對具體某個頁面或模塊，應用等價類的思想劃分輸入范圍（重點測試邊界值）；可以使用錯誤推測法追加一些測試用例，這需要依靠測試工程師的智慧和經驗。如果涉及多個輸入條件的組合情況，再用因果圖法考慮所有情況的排列組合。黑盒測試因果圖法等價類法邊界值法錯誤推測法137黑盒測試策略的綜合運用案例：計算三角形面積程序。輸入三個整數(shù)A、B、C，輸出以A、B、C為三邊的三角形面積（1<=A、B、C<100），結果保留2位小數(shù)。請運用等價類劃分方法，編寫測試用例。邊長數(shù)值非數(shù)值整數(shù)小數(shù)(7)字母(8)能構成三角形(1)空格(10)空白(11)1-99<1(5)>99(6)不能構成三角形a+b<c(2)b+c<a(3)a+c<b(4)特殊字符(9)

劃分等價類用例編號所屬等價類輸入數(shù)據(jù)預期結果11(有效等價類)A=1,B=1,C=10.4321(有效等價類)A=99,B=99,C=994243.9632(無效等價類)A=1,B=2,C=4提示“3邊不能構成三角形”43(無效等價類)A=4,B=1,C=2提示“3邊不能構成三角形”54(無效等價類)A=1,B=4,C=2提示“3邊不能構成三角形”65(無效等價類)A=0,B=0,C=0提示“請輸入1-99之間的整數(shù)”76(無效等價類)A=100,B=100,C=100提示“請輸入1-99之間的整數(shù)”87(無效等價類)A=4.1,B=5.6,C=4.8提示“請輸入整數(shù)”98(無效等價類)A=ABCD,B=ABCD,C=ABCD提示“請輸入1-99之間的整數(shù)”109(無效等價類)A=!#$$,B=!#$$,C=!#$$提示“請輸入1-99之間的整數(shù)”1110(無效等價類)A=空格,B=空格,C=空格提示“請輸入1-99之間的整數(shù)”1211(無效等價類)A=空白,B=空白,C=空白提示“請輸入1-99之間的整數(shù)”140實用測試策略（1）例：程序Triangle讀入三個整數(shù)值，這三個整數(shù)代表同一個三角形三條邊的長度，程序根據(jù)這三個值判斷三角形屬于不等邊、等腰或等邊三角形中的那一種。abcTrianglea,b,c三角形的類型？黑盒測試（等價劃分）

正常的三角形（a,b,c)不等邊三角形(8,10,12);(10,8,12);(10,12,8)等邊三角形(10,10,10)等腰三角形(10,10,17);(10,17,10);(17,10,10)

不能構成三角形的非法數(shù)據(jù)(a,b,c)a+b<c(10,10,21)b+c<a(21,10,10)c+a<b(10,21,10)

退化的三角形（a,b,c)不等邊三角形(10,6,4)等邊三角形(0,0,0)等腰三角形(10,5,5);(5,10,5);(10,5,5)黑盒測試（邊界值分析）

一條邊長度為零的情況（0，10，12）;（10，0，12）;（10，12，0）兩條邊的長度為零的情況（0，0，17）；（0，17，0）；（17，0，0）三條邊的長度為零的情況（0，0，0）輸入數(shù)據(jù)中包含負整數(shù)（-10，-10，-10)……輸入數(shù)據(jù)不全（不足三個正整數(shù)）（10，-，-）……輸入數(shù)據(jù)中包含非整數(shù)型的數(shù)據(jù)(a,b,c)(1.2,6e-4,7.8)……黑盒測試（錯誤推測）141單元測試被測模塊集成測試設計信息單元測試被測模塊單元測試被測模塊已經測試過的模塊確認測試系統(tǒng)測試軟件需求其它系統(tǒng)元素已集成的軟件已確認的軟件可交付的軟件軟件測試步驟142軟件測試步驟(1)單元測試(2)集成測試(3)確認測試(4)系統(tǒng)測試1431.什么是單元測試對軟件中的最小可測試單元進行檢查和驗證。單元？1個函數(shù)1個類1個窗口、1個菜單…單元測試1442.什么時候進行單元測試程序員編碼之后，代碼已經通過編譯后進行單元測試。前期做一些準備工作：撰寫單元測試計劃編寫單元測試用例單元測試145單元測試3.誰來進行單元測試白盒測試工程師或開發(fā)人員。如果有開發(fā)人員來測試，做到交叉測試，避免一個人只測試自己的程序。146單元測試4.單元測試的依據(jù)是什么源程序本身：代碼和注釋《詳細計劃》文檔147單元測試5.單元測試通過標準是什么（參考）程序通過所有單元測試的用例語句的覆蓋率達到100%分支的覆蓋率達到85%148單元測試6.國內單元測試的現(xiàn)狀很不正規(guī)。只是開發(fā)人員簡單的編譯和調試一下自己的程序，沒有相應的單元測試計劃、單元測試用例和代碼覆蓋率的統(tǒng)計。149單元測試7.如何進行單元測試單元測試主要是白盒測試方法。先靜態(tài)地檢查代碼是否符合規(guī)范再動態(tài)運行代碼，檢查實際運行結果。150單元測試的案例該程序實現(xiàn)的功能如下：#include<stdio.h>voidiszero(intm){ if(m!=0) printf(“%d”,m); else printf(“%d”,1);}voidmain(){inta[5],i=0;printf(“請輸入5個整數(shù)\n”);for(i=0;i<=4;i++){ scanf(“%d”,&a[i]); iszero(a[i]);}}151單元測試的案例（1）編譯運行程序首先編譯程序，沒有語法上的錯誤，編譯通過。然后運行程序，輸入12340，按回車。輸出12341，符合預期結果。（2）靜態(tài)檢查檢查程序中不符合編碼規(guī)范的地方，發(fā)現(xiàn)程序沒有任何注釋，應該注明程序的基本信息和各函數(shù)的主要功能。152單元測試的案例（3）動態(tài)測試邊界值問題輸入1234567，按回車，運行結果仍然為12345，與預期相符。雖結果正確，但最好能夠在程序中加以提示。非法數(shù)據(jù)的容錯性輸入5個小數(shù)。輸入數(shù)據(jù)時中間不加空格，有可能是逗號。153單元測試的內容：主要對模塊的五個基本特性進行評價。單元測試154（1）模塊接口測試在單元測試的開始，應對通過被測模塊的數(shù)據(jù)流進行測試。測試項目包括：調用本模塊的輸入參數(shù)是否正確；本模塊調用子模塊時輸入給子模塊的參數(shù)是否正確全局量的定義在各模塊中是否一致（2）局部數(shù)據(jù)結構測試不正確或不一致的數(shù)據(jù)類型說明使用尚未賦值或尚未初始化的變量錯誤的初始值或錯誤的缺省值變量名拼寫錯或書寫錯不一致的數(shù)據(jù)類型全局數(shù)據(jù)對模塊的影響單元測試155（3）路徑測試選擇適當?shù)臏y試用例，對模塊中重要的執(zhí)行路徑進行測試。應當設計測試用例查找由于錯誤的計算、不正確的比較或不正常的控制流而導致的錯誤.對基本執(zhí)行路徑和循環(huán)進行測試可以發(fā)現(xiàn)大量的路徑錯誤。（4）錯誤處理測試出錯的描述是否難以理解出錯的描述是否能夠對錯誤定位顯示的錯誤與實際的錯誤是否相符對錯誤條件的處理正確與否在對錯誤進行處理之前，錯誤條件是否已經引起系統(tǒng)的干預等。單元測試156（5）邊界條件測試注意數(shù)據(jù)流、控制流中剛好等于、大于或小于確定的比較值時出錯的可能性。對這些地方要仔細地選擇測試用例，認真加以測試。如果對模塊運行時間有要求的話，還要專門進行關鍵路徑測試，以確定最壞情況下和平均意義下影響模塊運行時間的因素。單元測試157單元測試單元測試方法：人工測試計算機測試158單元測試1.單元測試—人工測試由編寫者本人非正式地進行。由審查小組正式進行稱為代碼審查，它是一種非常有效的程序驗證技術，對于典型的程序來說，可以查出30%～70%的邏輯設計錯誤和編碼錯誤。審查小組最好由下述四人組成：組長，他應該是一個很有能力的程序員，而且沒有直接參與這項工程；程序的設計者；程序的編寫者；程序的測試者。1592.單元測試—計算機測試

模塊不是獨立的程序,自己不能運行,要靠其它部分來調用和驅動,要為每個單元測試開發(fā)兩個軟件:(1)驅動模塊(驅動程序)相當于主模塊(2)樁模塊(測試存根、連接程序)代替所測模塊調用的子模塊單元測試160BACDE待測試模塊單元測試161被測模塊B

驅動模塊(模擬模塊A)樁模塊(測試存根)(模擬模塊E)測試用例測試結果單元測試162單元測試的測試環(huán)境

（a）軟件結構（b）模塊B的測試環(huán)境圖:單元測試的測試環(huán)境163集成測試單元測試單元測試單元測試單元測試單元測試164集成測試1.什么是集成測試在單元測試的基礎上，需要將所有模塊按照設計要求組裝成為系統(tǒng)，發(fā)現(xiàn)并排除在模塊連接中可能出現(xiàn)的問題，最終構成要求的軟件系統(tǒng)。在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失；

一個模塊的功能是否會對另一個模塊的功能產生不利的影響；各個子功能組合起來，能否達到預期要求的父功能；全局數(shù)據(jù)結構是否有問題；單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。165集成測試2.什么時候進行集成測試單元和集成測試同步進行。在單元測試中先測試幾個函數(shù)的自身功能，然后再集成測試一下這幾個函數(shù)的接口（即參數(shù)傳遞）。3.由誰來進行集成測試白盒測試工程師或是開發(fā)人員4.集成測試的依據(jù)是什么單元測試模塊以及《概要設計》文檔166集成測試方案：自頂向下集成測試自底向上集成測試核心系統(tǒng)先行集成測試高頻集成測試深度優(yōu)先廣度優(yōu)先集成測試167自頂向下集成測試（需要樁模塊）從主控模塊（主程序）開始沿控制層向下移動，把模塊一一組合起來。分兩種方法：先深度：按照結構，用一條主控制路徑將所有模塊組合起來；先寬度：逐層組合所有下屬模塊，在每一層水平地集成測試

沿著移動。

集成測試模塊測試結合順序深度優(yōu)先:A、B、E、C、D、F廣度優(yōu)先:A、B、C、D、E、F168自頂向下測試的組裝模塊的方法1）自頂向下結合有兩種組合策略：（1）深度優(yōu)先策略：

圖：一個軟件結構圖

圖：采用深度優(yōu)先策略自頂向下結合模塊的過程

（2）寬度優(yōu)先策略：逐層結合直接下屬的所有模塊。結合順序為M，A，B，C，D，E。169自頂向下集成測試組裝過程分以下五個步驟：步驟一：用主控模塊作為測試驅動程序，其直接下屬模塊用樁模塊來代替；步驟二：根據(jù)所選擇的集成測試法（先深度或先寬度），每次用實際模塊代替下屬的樁模塊步驟三：在組合每個實際模塊時都要進行測試；步驟四：完成一組測試后再用一個實際模塊代替另一個樁模塊；步驟五：可以進行回歸測試（即重新再做所有的或者部分已做過的測試），以保證不引入新的錯誤。

集成測試170集成測試自底向上集成（需要驅動程序）自底向上的集成是最常使用的方法。其他集成方法都或多或少地繼承、吸收了這種集成方式的思想。自底向上集成方式從程序模塊結構中最底層的模塊開始組裝和測試。模塊是自底向上進行組裝的，對于一個給定層次的模塊，它的子模塊（包括子模塊的所有下屬模塊）事前已經完成組裝并經過測試，所以不再需要編制樁模塊。171自底向上測試的組裝模塊的方法自底向上測試測試步驟為：（1）把低層模塊組合成實現(xiàn)一個個特定功能的族。如圖所示。

圖一個軟件結構圖（2）為每一個族編寫一個驅動模塊，以協(xié)調測試用例的輸入和測試結果的輸出。如圖所示，其中di模塊為驅動模塊。

圖為每個族分別進行測試172自底向上測試的組裝模塊的方法（3）對模塊族進行測試。（4）按軟件控制結構圖依次向上擴展，用實際模塊替換驅動模塊，形成一個個更大的族。如圖所示。

圖形成3個更大的族進一步測試（5）重復（2）~（4）步，直至軟件系統(tǒng)全部測試完畢。核心系統(tǒng)先行集成測試先對核心軟件部件進行集成測試，在測試通過的基礎上再按各外圍軟件部件的重要程度逐個集成到核心系統(tǒng)中。每次加入一個外圍軟件部件都產生一個產品基線，直至最后形成穩(wěn)定的軟件產品。方案點評：該集成測試方法對于快速軟件開發(fā)很有效果，適合較復雜系統(tǒng)的集成測試，能保證一些重要的功能和服務的實現(xiàn)。缺點是采用此法的系統(tǒng)一般應能明確區(qū)分核心軟件部件和外圍軟件部件，核心軟件部件應具有較高的耦合度，外圍軟件部件內部也應具有較高的耦合度，但各外圍軟件部件之間應具有較低的耦合度。核心系統(tǒng)先行集成測試步驟如下：步驟一：對核心系統(tǒng)中的每個模塊進行單獨的、充分的測試，必要時使用驅動模塊和樁模塊；步驟二：對于核心系統(tǒng)中的所有模塊一次性集合到被測系統(tǒng)中，解決集成中出現(xiàn)的各類問題。在核心系統(tǒng)規(guī)模相對較大的情況下，也可以按照自底向上的步驟，集成核心系統(tǒng)的各組成模塊。步驟三：按照各外圍軟件部件的重要程度以及模塊間的相互制約關系，擬定外圍軟件部件集成到核心系統(tǒng)中的順序方案。方案經評審以后，即可進行外圍軟件部件的集成。步驟四：在外圍軟件部件添加到核心系統(tǒng)以前，外圍軟件部件應先完成內部的模塊級集成測試。步驟五：按順序不斷加入外圍軟件部件，排除外圍軟件部件集成中出現(xiàn)的問題，形成最終的用戶系統(tǒng)。

高頻集成測試高頻集成測試是指同步于軟件開發(fā)過程，每隔一段時間對開發(fā)團隊的現(xiàn)有代碼進行一次集成測試。如某些自動化集成測試工具能實現(xiàn)每日深夜對開發(fā)團隊的現(xiàn)有代碼進行一次集成測試，然后將測試結果發(fā)到各開發(fā)人員的電子郵箱中。該集成測試方法頻繁地將新代碼加入到一個已經穩(wěn)定的基線中，以免集成故障難以發(fā)現(xiàn)，同時控制可能出現(xiàn)的基線偏差。使用高頻集成測試需要具備一定的條件：可以持續(xù)獲得一個穩(wěn)定的增量，并且該增量內部已被驗證沒有問題；大部分有意義的功能增加可以在一個相對穩(wěn)定的時間間隔（如每個工作日）內獲得；測試包和代碼的開發(fā)工作必須是并行進行的，并且需要版本控制工具來保證始終維護的是測試腳本和代碼的最新版本；必須借助于使用自動化工具來完成。高頻集成一個顯著的特點就是集成次數(shù)頻繁，顯然，人工的方法是不勝任的。高頻集成測試一般采用如下步驟來完成：

步驟一：選擇集成測試自動化工具。如很多Java項目采用Junit+Ant方案來實現(xiàn)集成測試的自動化，也有一些商業(yè)集成測試工具可供選擇。步驟二：設置版本控制工具，以確保集成測試自動化工具所獲得的版本是最新版本。如使用CVS進行版本控制。步驟三：測試人員和開發(fā)人員負責編寫對應程序代碼的測試腳本。步驟四：設置自動化集成測試工具，每隔一段時間對配置管理庫的新添加的代碼進行自動化的集成測試，并將測試報告匯報給開發(fā)人員和測試人員。步驟五：測試人員監(jiān)督代碼開發(fā)人員及時關閉不合格項。按照步驟三至步驟五不斷循環(huán)，直至形成最終軟件產品。高頻集成測試方案點評：該測試方案能在開發(fā)過程中及時發(fā)現(xiàn)代碼錯誤，能直觀地看到開發(fā)團隊的有效工程進度。在此方案中，開發(fā)維護源代碼與開發(fā)維護軟件測試包被賦予了同等的重要性，這對有效防止錯誤、及時糾正錯誤都很有幫助。該方案的缺點在于測試包有時候可能不能暴露深層次的編碼錯誤和圖形界面錯誤。集成測試方案的選擇在現(xiàn)代復雜軟件項目集成測試過程中，通常采用核心系統(tǒng)先行集成測試和高頻集成測試相結合的方式進行。自底向上的集成測試方案在采用傳統(tǒng)瀑布式開發(fā)模式的軟件項目集成過程中較為常見。應結合項目的實際工程環(huán)境及各測試方案適用的范圍進行合理的選型。確認測試（validationtesting）又稱有效性測試。它的任務是驗證軟件的有效性，即驗證軟件的功能和性能及其他特性是否與用戶的要求一致。在確認測試階段需要做的工作如下圖所示。

確認測試

從上圖中可看出，首先要進行有效性測試以及軟件配置復審，然后進行驗收測試和安裝測試，在通過了專家鑒定之后，才能成為可交付的軟件。1．進行有效性測試（黑盒測試）有效性測試是在模擬的環(huán)境（可能就是開發(fā)的環(huán)境）下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。確認測試

2．軟件配置復查軟件配置復查的目的是保證軟件配置的所有成分都齊全，各方面的質量都符合要求，具有維護階段所必須的細節(jié)，而且已經編排好分類的目錄。除了按合同規(guī)定的內容和要求，由人工審查軟件配置之外，在確認測試的過程中，應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。必須仔細記錄發(fā)現(xiàn)的遺漏和錯誤，并且適當?shù)匮a充和改正。

確認測試

3．測試和測試在軟件交付使用之后，用戶將如何實際使用程序，對于開發(fā)者來說是無法預測的。

很多軟件產品生產者采用一種稱之為測試和測試的測試方法，以發(fā)現(xiàn)可能只有最終用戶才能發(fā)現(xiàn)的錯誤。確認測試

測試是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是公司內部的用戶在模擬實際操作環(huán)境下進行的測試。

軟件在一個自然設置狀態(tài)下使用，開發(fā)者坐在用戶旁邊，隨時記下錯誤情況和使用中的問題。

測試的目的是評價軟件產品的FLURPS（即功能、局域化、可使