軟件工程概論-10-軟件實現(xiàn)

軟件工程概論

SoftwareEngineering賈恒彬E-mail:jiahengbin@李恒E-mail:liheng@第5章軟件實現(xiàn)通常把編碼和測試統(tǒng)稱為實現(xiàn)。程序的質(zhì)量主要取決于軟件設計的質(zhì)量,但是，所選用的程序設計語言的特點及編碼風格也將對程序的可靠性、可讀性、可測試性和可維護性產(chǎn)生深遠的影響。測試的目的就是在軟件投入生產(chǎn)性運行之前，盡可能多地發(fā)現(xiàn)軟件中的錯誤。目前軟件測試仍然是保證軟件質(zhì)量的關(guān)鍵步驟，它是對軟件規(guī)格說明、設計和編碼的最后復審。第5章軟件實現(xiàn)軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對它做必要的測試(稱為單元測試)，模塊的編寫者和測試者是同一個人，編碼和單元測試屬于軟件生命周期的同一個階段。在這個階段結(jié)束之后，對軟件系統(tǒng)還應該進行各種綜合測試，這是軟件生命周期中的另一個獨立的階段，通常由專門的測試人員承擔這項工作。第5章軟件實現(xiàn)大量統(tǒng)計資料表明，軟件測試的工作量往往占軟件開發(fā)總工作量的40%以上.在極端情況，測試那種關(guān)系人的生命安全的軟件所花費的成本，可能相當于軟件工程其他開發(fā)步驟總成本的3倍到5倍。通過測試發(fā)現(xiàn)錯誤之后還必須診斷并改正錯誤，這就是調(diào)試的目的。調(diào)試是測試階段最困難的工作。第5章軟件實現(xiàn)5.1編碼5.2軟件測試基礎5.3軟件測試5.4軟件測試方法5.5調(diào)試5.1

編碼編碼又稱程序設計，是軟件生命周期中繼詳細設計之后的階段，這個階段的任務是使用選定的程序設計語言，把經(jīng)過詳細設計所得到的以程序設計說明書體現(xiàn)的信息處理過程描述后，轉(zhuǎn)換成能在計算機系統(tǒng)上運行的程序源代碼。編碼的質(zhì)量和詳細設計的質(zhì)量、程序設計語言的性能以及編程風格密切相關(guān)。根據(jù)不同的程序設計語言的不同特點及其適用范圍，選擇恰當?shù)某绦蛟O計語言進行編碼，將有利于提高代碼的可讀性、可測試性、可維護性和可靠性。5.1.1程序設計語言程序設計語言的分類第一代語言——從屬于機器的語言第二代語言——匯編語言第三代語言——高級程序設計語言傳統(tǒng)的高級程序設計語言

FORTRAN、COBOL、ALGOL、BASIC通用的結(jié)構(gòu)化程序設計語言

PASCAL，C和Ada

專用語言

APL、Lisp、PROLOG、Smalltalk、C++、Java

第四代語言（4GL）5.1.1程序設計語言程序設計語言選擇的主要標準(1)系統(tǒng)用戶的要求。如果所開發(fā)的系統(tǒng)由用戶負責維護，用戶通常要求用他們熟悉的語言書寫程序。(2)可以使用的編譯程序。運行目標系統(tǒng)的環(huán)境中可以提供的編譯程序往往限制了可以選用的語言的范圍。(3)可以得到的軟件工具。如果某種語言有支持程序開發(fā)的軟件工具可以利用，則目標系統(tǒng)的實現(xiàn)和驗證都變得比較容易。(4)工程規(guī)模。如果工程規(guī)模很龐大，現(xiàn)有的語言又不完全適用，那么設計并實現(xiàn)一種供這個工程項目專用的程序設計語言，可能是一個正確的選擇。

5.1.1程序設計語言程序設計語言選擇的主要標準(5)程序員的知識。雖然對于有經(jīng)驗的程序員來說，學習一種新語言并不困難，但是要完全掌握一種新語言卻需要實踐。如果和其他標準不矛盾，那么應該選擇一種已經(jīng)為程序員所熟悉的語言。(6)軟件可移植性要求。如果目標系統(tǒng)將在幾臺不同的計算機上運行，或者預期的使用壽命很長，那么選擇一種標準化程度高、程序可移植性好的語言就是很重要的。(7)軟件的應用領域。所謂的通用程序設計語言實際上并不是對所有應用領域都同樣適用。因此，選擇語言時應該充分考慮目標系統(tǒng)的應用范圍。

5.1.2編碼風格

編程風格即程序代碼書寫的風格，良好的編程風格的特點是邏輯簡明清晰、易讀易懂。程序的閱讀者不僅僅有程序的開發(fā)者，還有程序的測試人員、維護人員。 具有良好的編程風格的程序有利于程序員在編程的過程中發(fā)現(xiàn)錯誤，有利于測試和維護人員對程序進行測試、調(diào)試、維護工作。良好的編程風格對于提高程序的可讀性、可測試性、可維護性以及可靠性具有深遠的意義。 為了使程序代碼具有良好的風格，易讀易懂，應該從以下幾個方面遵循基本的原則：程序內(nèi)部的文檔數(shù)據(jù)說明語句構(gòu)造輸入/輸出方法等5.1.2編碼風格程序內(nèi)部的文檔（恰當?shù)臉俗R符、適當?shù)淖⒔夂统绦虻囊曈X組織等）恰當?shù)臉俗R符選取含義鮮明的名字，使它能正確地提示程序?qū)ο笏淼膶嶓w。如果使用縮寫，那么縮寫規(guī)則應該一致，并且應該給每個名字加注解。一般的命名約定有不少人編程時用拼音給函數(shù)或變量命名，這樣做并不能說明你很愛國，卻會讓用此程序的人迷糊（很多南方人不懂拼音）。程序中的英文一般不會太復雜，用詞要力求準確。

匈牙利命名法是Microsoft公司倡導的

[Maguire1993]，雖然很煩瑣，但用習慣了也就成了自然。沒有人強迫你采用何種命名法，但有一點應該做到：自己的程序命名必須一致。（1）宏定義用大寫字母加下劃線表示，如MAX_LENGTH；

（2）函數(shù)用大寫字母開頭的單詞組合而成，如SetName,GetName；

（3）指針變量加前綴p，如*pNode；

（4）BOOL變量加前綴b，如

bFlag；

（5）int變量加前綴i，如

iWidth；

（6）float變量加前綴f，如

fWidth；

（7）double變量加前綴d，如

dWidth；

（8）字符串變量加前綴str，如

strName；

（9）枚舉變量加前綴e，如

eDrawMode；

（10）類的成員變量加前綴m_，如

m_strName,m_iWidth；

5.1.2編碼風格適當?shù)淖⒔馔ǔＴ诿總€模塊開始處有一段序言性的注解，簡要描述模塊的功能、主要算法、接口特點、重要數(shù)據(jù)以及開發(fā)簡史。插在程序中間與一段程序代碼有關(guān)的注解，主要解釋包含這段代碼的必要性。對于用高級語言書寫的源程序，不需要用注解的形式把每個語句翻譯成自然語言，應該利用注解提供一些額外的信息。應該用空格或空行清楚地區(qū)分注解和程序。程序的視覺組織程序清單的布局對于程序的可讀性也有很大影響，應該利用適當?shù)碾A梯形式使程序的層次結(jié)構(gòu)清晰明顯。5.1.2編碼風格數(shù)據(jù)說明數(shù)據(jù)說明的次序應該標準化（例如，按照數(shù)據(jù)結(jié)構(gòu)或數(shù)據(jù)類型確定說明的次序）。當多個變量名在一個語句中說明時，應該按字母順序排列這些變量。如果設計時使用了一個復雜的數(shù)據(jù)結(jié)構(gòu)，則應該用注解說明用程序設計語言實現(xiàn)這個數(shù)據(jù)結(jié)構(gòu)的方法和特點。5.1.2編碼風格語句構(gòu)造構(gòu)造語句時應該遵循的原則是，每個語句都應該簡單而直接，不能為了提高效率而使程序變得過分復雜。不要為了節(jié)省空間而把多個語句寫在同一行；盡量避免復雜的條件測試；盡量減少對“非”條件的測試；避免大量使用循環(huán)嵌套和條件嵌套；利用括號使邏輯表達式或算術(shù)表達式的運算次序清晰直觀。5.1.2編碼風格輸入／輸出對所有輸入數(shù)據(jù)都進行檢驗；檢查輸入項重要組合的合法性；保持輸入格式簡單；使用數(shù)據(jù)結(jié)束標記，不要要求用戶指定數(shù)據(jù)的數(shù)目；明確提示交互式輸入的請求，詳細說明可用的選擇或邊界數(shù)值；當程序設計語言對格式有嚴格要求時，應保持輸入格式一致；設計良好的輸出報表；給所有輸出數(shù)據(jù)加標志。5.1.2編碼風格效率效率主要指處理機時間和存儲器容量兩個方面。在討論提高效率前，應該記住3條原則：效率是性能要求，因此應該在需求分析階段確定效率方面的要求。效率是靠好設計來提高的。程序的效率和程序的簡單程度是一致的。不要犧牲程序的清晰性和可讀性來不必要地提高效率。從三個方面進一步討論效率問題：5.1.2編碼風格1.程序運行時間寫程序之前先簡化算術(shù)的和邏輯的表達式；仔細研究嵌套的循環(huán)，以確定是否有語句可以從內(nèi)層往外移；盡量避免使用多維數(shù)組；盡量避免使用指針和復雜的表；使用執(zhí)行時間短的算術(shù)運算；不要混合使用不同的數(shù)據(jù)類型；盡量使用整數(shù)運算和布爾表達式。在效率是決定性因素的應用領域，盡量使用有良好優(yōu)化特性的編譯程序，以自動生成高效目標代碼。5.1.2編碼風格2.存儲器效率在大型計算機中必須考慮操作系統(tǒng)頁式調(diào)度的特點，一般說來，使用能保持功能域的結(jié)構(gòu)化控制結(jié)構(gòu)，是提高效率的好方法。在微處理機中如果要求使用最少的存儲單元，則應選用有緊縮存儲器特性的編譯程序，在非常必要時可以使用匯編語言。提高執(zhí)行效率的技術(shù)通常也能提高存儲器效率。提高存儲器效率的關(guān)鍵同樣是簡單。5.1.2編碼風格3.輸入輸出效率如果用戶為了給計算機提供輸入信息或為了理解計算機輸出的信息，所需花費的腦力勞動是經(jīng)濟的，那么人和計算機通信的效率就高。因此，簡單清晰同樣是提高人機通信效率的關(guān)鍵。硬件之間的通信效率比較復雜，但從寫程序的角度看，有些簡單原則可以提高輸入輸出效率：所有輸入輸出都應該有緩存，以減少用于通信的額外開銷。對二級存儲器應該選用最簡單的訪問方法。二級緩存器的輸入輸出應該以信息組為單位進行。如果“超高效的”輸入輸出很難被人理解，則不采用這種方法。5.2

軟件測試基礎

軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程?；蛘哒f，軟件測試是根據(jù)軟件開發(fā)各階段的規(guī)格說明和程序的內(nèi)部結(jié)構(gòu)而精心設計一批測試用例（即輸入數(shù)據(jù)及其預期的輸出結(jié)果），并利用這些測試用例去運行程序，以發(fā)現(xiàn)程序錯誤的過程。 軟件測試在軟件生存期中橫跨兩個階段： 單元測試：編寫完一個模塊后所作的測試。通常編寫者和測試者是同一個人， 綜合測試：對軟件系統(tǒng)進行的各種綜合測試,通常由專門的測試人員承擔。5.2.1軟件測試的目的

軟件測試的目的是設計測試用例以最小的代價、在最短的時間內(nèi)系統(tǒng)地發(fā)現(xiàn)各種不同類型的錯誤GrenfordJ.Myers就軟件測試目的提出以下觀點：測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤；一個好的測試用例在于能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤；一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

注意：測試的可以證明程序中存在錯誤，但是測試不能證明程序中沒有錯誤。

5.2.2軟件測試準則為了能設計出有效的測試方案，主要的測試準則：（1）所有測試都應該能追溯到用戶需求。正如上一小節(jié)講過的，軟件測試的目標是發(fā)現(xiàn)錯誤。從用戶的角度看，最嚴重的錯誤是導致程序不能滿足用戶需求的那些錯誤。（2）應該遠在測試開始之前就制定出測試計劃。完成需求模型可著手制定測試計劃，在建立了設計模型之后就可以立即開始設計詳細的測試方案。（3）Pareto原理：測試發(fā)現(xiàn)的錯誤中的80%很可能是由程序中20%的模塊造成的。當然，問題是怎樣找出這些可疑的模塊并徹底地測試它們。5.2.2軟件測試準則（4）應該從“小規(guī)?！?/p>

“大規(guī)模”測試。首先重點測試單個程序模塊，然后把測試重點轉(zhuǎn)向在集成的模塊簇中尋找錯誤，最后在整個系統(tǒng)中尋找錯誤。（5）窮舉測試是不可能的。所謂窮舉測試就是把程序所有可能的執(zhí)行路徑都檢查一遍的測試。此路不通！因此，測試只能證明程序中有錯誤，不能證明程序中沒有錯誤。但是，精心地設計測試方案，有可能充分覆蓋程序邏輯并使程序達到所要求的可靠性。（6）為了達到最佳的測試效果，應該由獨立的第三方從事測試工作。5.2.3軟件測試方法測試有兩種方法,即黑盒測試和白盒測試：如果已經(jīng)知道了產(chǎn)品應該具有的功能，可以通過測試來檢驗是否每個功能都能正常使用——黑盒測試；如果知道產(chǎn)品的內(nèi)部工作過程，可以通過測試來檢驗產(chǎn)品內(nèi)部動作是否按照規(guī)格說明書的規(guī)定正常進行——白盒測試。5.2.3軟件測試方法黑盒測試法把程序看作一個黑盒子，完全不考慮程序的內(nèi)部結(jié)構(gòu)和處理過程。黑盒測試又稱為功能測試。白盒測試法與黑盒測試法相反，它的前提是可以把程序看成裝在一個透明的白盒子里，測試者完全知道程序的結(jié)構(gòu)和處理算法。這種方法按照程序內(nèi)部的邏輯測試程序，檢測程序中的主要執(zhí)行通路是否都能按預定要求正確工作。白盒測試又稱為結(jié)構(gòu)測試。5.2.4軟件測試過程單元測試集成測試確認測試系統(tǒng)測試5.2.4軟件測試過程測試與軟件開發(fā)各階段的關(guān)系5.2.5測試信息流測試過程需要三類輸入：軟件配置——包括軟件需求規(guī)格說明、軟件設計規(guī)格說明、源代碼等；測試配置——包括測試計劃、測試用例、測試驅(qū)動程序等；測試工具——測試工具為測試的實施提供某種服務。例如，測試數(shù)據(jù)自動生成程序、靜態(tài)分析程序、動態(tài)分析程序、測試結(jié)果分析程序以及驅(qū)動測試的工作臺等。5.2.5測試信息流比較測試的實際結(jié)果和預期結(jié)果，若兩者不一致則很可能是程序中有錯誤。設法確定錯誤的準確位置并且改正它，這就是調(diào)試的任務。與測試不同，通常由程序的編寫者負責調(diào)試。如果出現(xiàn)要求修改設計的嚴重錯誤，軟件的質(zhì)量和可靠性是值得懷疑的，應該進一步仔細測試；同上述相反，功能完成得很正常，遇到的錯誤也很容易改正，則仍然應該考慮兩種可能：(1)軟件的可靠性是可以接受的；(2)所進行的測試尚不足以發(fā)現(xiàn)嚴重的錯誤。這些錯誤最終將被用戶發(fā)現(xiàn)，而且需要在維護階段改正它們(但是改正同一個錯誤需要付出的代價比在開發(fā)階段高出許多倍)。5.3

軟件測試3.1.1單元測試單元測試：測試模塊。單元測試和編碼屬于軟件過程的同一個階段。在編寫出源程序代碼并通過了編譯程序的語法檢查之后，就可以用詳細設計作指南，對重要的執(zhí)行通路進行測試，以便發(fā)現(xiàn)模塊內(nèi)部的錯誤?？捎萌斯y試和計算機測試兩種測試方法，完成單元測試工作。單元測試主要使用白盒測試技術(shù)，而且對多個模塊的測試可以并行地進行。5.3.1單元測試單元測試的內(nèi)容1.模塊接口首先應該對通過模塊接口的數(shù)據(jù)流進行測試，主要檢查下述幾個方面：參數(shù)的數(shù)目、次序、屬性或單位系統(tǒng)與變元是否一致；是否修改了只作輸入用的變元；全局變量的定義和用法在各個模塊中是否一致。5.3.1單元測試模塊接口測試要點參數(shù)數(shù)目和由調(diào)用模塊送來的變元的數(shù)目是否相等？參數(shù)的屬性和變元的屬性是否匹配？參數(shù)和變元的單位系統(tǒng)是否匹配？傳送給被調(diào)用模塊的變元的數(shù)目是否等于那個模塊的參數(shù)的數(shù)目？傳送給被調(diào)用模塊的變元屬性和參數(shù)的屬性是否一致？傳送給被調(diào)用模塊的變元的單位系統(tǒng)和該模塊參數(shù)的單位系統(tǒng)是否一致？傳送給內(nèi)部函數(shù)的變元屬性、數(shù)目和次序是否正確？是否修改了只做輸入用的變元。全程變量的定義和用法在各個模塊中是否一致？5.3.1單元測試2.局部數(shù)據(jù)結(jié)構(gòu)對于模塊來說，局部數(shù)據(jù)結(jié)構(gòu)是常見的錯誤來源。應該仔細設計測試方案，以便發(fā)現(xiàn)局部數(shù)據(jù)說明、初始化、默認值等方面的錯誤。局部數(shù)據(jù)結(jié)構(gòu)測試要點錯誤的或不相容的說明使用尚未賦值或尚未初始化的變量錯誤的初始值或不正確的缺省值錯誤的變量名字（拼寫錯或截短了）數(shù)據(jù)類型不相容上溢、下溢或地址異常5.3.1單元測試3.重要的執(zhí)行通路由于通常不可能進行窮盡測試，因此，在單元測試期間選擇最有代表性、最可能發(fā)現(xiàn)錯誤的執(zhí)行通路進行測試就是十分關(guān)鍵的。應該設計測試方案用來發(fā)現(xiàn)由于錯誤的計算、不正確的比較或不適當?shù)目刂屏鞫斐傻腻e誤。重要的執(zhí)行通路測試要點 選擇最具有代表性的,最可能發(fā)現(xiàn)錯誤的執(zhí)行通路進行測試5.3.1單元測試4.出錯處理通路出錯處理通路測試要點 應重點測試下述可能發(fā)生的錯誤對錯誤的描述是難于理解的記下的錯誤與實際遇到的錯誤不同在對錯誤進行處理之前，錯誤條件已經(jīng)引起系統(tǒng)干預。對錯誤的處理不正確描述錯誤的信息不足以幫助確定造成錯誤的位置。5.3.1單元測試5.邊界條件邊界測試是單元測試中最后的也可能是最重要的任務。使用剛好小于、剛好等于和剛好大于最大值或最小值的數(shù)據(jù)結(jié)構(gòu)、控制量和數(shù)據(jù)值的測試方案，非常可能發(fā)現(xiàn)軟件中的錯誤。5.3.1單元測試邊界條件測試要點比較數(shù)據(jù)類型不同的量邏輯運算符不正確或優(yōu)先次序的錯誤當由于精度問題兩個量不會相等時，程序中卻期待著相等條件的出現(xiàn)“差1”錯（即，多循環(huán)一次或少循環(huán)一次）錯誤的或不存在的循環(huán)終止條件當遇到發(fā)散的迭代時不能終止循環(huán)錯誤地修改循環(huán)變量5.3.1單元測試代碼檢查單元測試采用靜、動結(jié)合的方法。在進行動態(tài)測試之前，首先采用靜態(tài)方法對程序的代碼進行檢查。代碼檢查主要檢查代碼和設計的一致性，其內(nèi)容包括代碼的可讀性、邏輯表達的正確性、代碼結(jié)構(gòu)的合理性、編程的風格、程序的語法、結(jié)構(gòu)等。代碼檢查有桌面檢查、代碼審查、走查三種方式。其中，桌面檢查是由程序員檢查自己的程序；代碼審查和走查基本相同，是由若干程序員和測試員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析。通過代碼檢查可以找到程序中30%～70%的邏輯設計和編碼缺陷，而且代碼檢查看到的是問題本身而不是問題的征兆。5.3.1單元測試單元測試的環(huán)境=所測模塊+驅(qū)動模塊+樁模塊

驅(qū)動模塊：用來模擬所測模塊的上一級模塊，相當于是一個接受測試數(shù)據(jù)，并把數(shù)據(jù)傳送給所測模塊，然后打印相關(guān)結(jié)果的“主程序”。樁模塊：又稱為“存根程序”，是用來代替被所測模塊調(diào)用的子模塊。它不需要把子模塊的所有功能都帶進來，但是也不能什么都不做。樁模塊不能只簡單的給出“曾經(jīng)進入”的信息，而可能需要使用子模塊的接口模擬實際子模塊的功能。 5.3.2集成測試

集成測試是在單元測試的基礎上，將模塊按照總體設計時的要求組裝成子系統(tǒng)或整個系統(tǒng)進行測試，因此集成測試又被稱為組裝測試。

集成測試關(guān)注的問題主要有：在把各個模塊連接起來的時侯，穿越模塊接口的數(shù)據(jù)是否會丟失一個模塊的功能是否會對另一個模塊的功能產(chǎn)生不利的影響各個子功能組合起來，能否達到預期要求的父功能全局數(shù)據(jù)結(jié)構(gòu)是否有問題單個模塊的誤差累積起來，是否會放大，從而達到不能接受的程度。單個模塊的錯誤是否會導致數(shù)據(jù)庫錯誤。

5.3.2集成測試集成測試的策略選擇什么方式把模塊組裝起來形成一個可運行的系統(tǒng)，直接影響到模塊測試用例的形式、所用測試工具的類型、模塊編號的次序和測試的次序、以及生成測試用例的費用和調(diào)試的費用。

通常，把模塊組裝成系統(tǒng)的方式有一次性組裝方式和增量式組裝方式。

5.3.2集成測試非增量式集成 非增量式集成又稱為一次性集成，其策略是首先將各模塊作為單個的實體進行測試，然后將所有的已經(jīng)測試好的模塊一次性組合到被測系統(tǒng)中，組成最終的系統(tǒng)進行測試。5.3.2集成測試非增量式集成的特點①測試的額外工作量比較大②模塊間的接口錯誤發(fā)現(xiàn)得比較晚③錯誤的定位和修改比較困難④使用樁模塊和驅(qū)動模塊模擬軟件的執(zhí)行環(huán)境進行的測試與將測試模塊放入到實際運行環(huán)境中進行的測試效果是不同的。因此仍然會有許多模塊的接口錯誤躲過單元測試而進入到系統(tǒng)范圍測試.⑤在測試過程中，除編寫驅(qū)動模塊和樁模塊比較費時，花在每個模塊單元測試上的時間相對增量式集成要少.⑥對于大型程序而言，由于所有的模塊的單元測試都可以同時進行，多個測試人員可以并行工作，因此對人力和物力資源的利用率較高。

特點①～④是非增量式集成策略的缺點，⑤～⑥是它的優(yōu)點。5.3.2集成測試

由于程序中不可避免地存在涉及模塊間接口、全局數(shù)據(jù)結(jié)構(gòu)等方面的問題，因此一次試運行成功的可能性并不很大。5.3.2集成測試增量式集成

增量式集成的策略是按不同的順序依次向被測系統(tǒng)加入新的模塊，進行集成測試，新模塊可以用來取代被測系統(tǒng)在之前的測試中所使用的相應的驅(qū)動模塊或樁模塊。 為了保證在組裝過程中不引入新錯誤，需要進行回歸測試——重新執(zhí)行以前做過的全部或部分測試，以確保在增加新的模塊的同時沒有增加新的錯誤。

5.3.2集成測試5.3.2集成測試增量式集成的特點①可以減少編寫驅(qū)動或樁模塊的工作量；②模塊接口錯誤可以較早被發(fā)現(xiàn)；③較容易對錯誤進行定位和修改；④多次的回歸測試，以及被測系統(tǒng)中模塊在不同環(huán)境下的多次運行，為充分暴露模塊接口錯誤提供了更多的機會，因此測試更徹底；⑤由于用實際模塊替代了驅(qū)動模塊或樁模塊，在測試過程中所測模塊的上（下）級模塊將會多次重復執(zhí)行；因此花費在所測模塊上的測試時間相對非增量式集成較多；⑥測試工作的并行程度相對非增量式集成要低一些。

特點①～④是增量式集成的優(yōu)點，⑤～⑥是缺點5.3.2集成測試

非增量式集成增量式集成編寫驅(qū)動模塊/樁模塊工作量大小接口錯誤發(fā)現(xiàn)的時間晚早錯誤定位與修改的難度大小測試的徹底程度低高單個模塊測試所需時間少多模塊單元測試的并行程度高低非增量式集成與增量式集成測試策略對比表

增量式集成測試策略要比非增量式集成測試策略更好。因此，建議使用增量式集成測試策略5.3.2集成測試增量式集成測試的三種不同策略自底向上集成具體策略：整個測試過程的起點是系統(tǒng)模塊層次結(jié)構(gòu)中的最底層模塊；然后用待加入的新模塊替換被測系統(tǒng)先前所使用的驅(qū)動模塊，新模塊的直接上級模塊用驅(qū)動模塊替換；這個替換的過程一直持續(xù)到頂層模塊加入被測系統(tǒng)中。主要優(yōu)點：不需要編寫樁模塊，設計測試用例比較容易。主要缺點：對主要的控制直到最后才接觸到。5.3.2集成測試自頂向下集成具體策略：整個測試過程的起點是頂層模塊（主控模塊），然后用待加入的新模塊替換被測系統(tǒng)先前所使用的樁模塊，新模塊的所有直接下級模塊全部用樁模塊替換；這個替換的過程一直持續(xù)到所有的模塊都加入到被測系統(tǒng)中為止。主要優(yōu)點：不需要編寫驅(qū)動模塊，能夠較早的發(fā)現(xiàn)主要控制方面的問題。主要缺點：需要編寫樁模塊，而要使樁模塊能夠模擬實際子模塊的功能是十分困難的，特別是一些涉及到輸入/輸出的模塊。5.3.2集成測試混合式集成具體策略：將系統(tǒng)劃分成三層，上層采用自頂向下的策略，下層采用自底向上的策略，最后在中間層會合?；旌鲜郊刹呗越Y(jié)合了自頂向下集成和自底向上集成策略的優(yōu)點，當被測軟件關(guān)鍵模塊（注：關(guān)鍵模塊應及早測試）比較多時，它是最好的折衷方法。

5.3.2集成測試在集成測試的范疇中，所謂回歸測試是指重新執(zhí)行已經(jīng)做過的測試的某個子集，以保證一些程序的變化沒有帶來非預期的副作用?；貧w測試集包括3類不同的測試用例：檢測軟件全部功能的代表性測試用例子；專門針對可能受修改影響的軟件功能的附加測試；針對被修改過的軟件成分的測試?；貧w測試5.3.3確認測試

確認測試又稱有效性測試。它的任務是驗證軟件的有效性，即驗證軟件的功能和性能及其他特性是否與用戶的要求一致。 在確認測試階段需要做的工作：首先要進行有效性測試以及軟件配置復審，然后進行驗收測試和安裝測試，在通過了專家鑒定之后，才能成為可交付的軟件。5.3.3確認測試有效性測試 有效性測試是在模擬的環(huán)境（可能就是開發(fā)的環(huán)境）下，運用黑盒測試的方法，驗證被測軟件是否滿足需求規(guī)格說明書列出的需求。測試結(jié)果可以分為兩類。測試結(jié)果與預期結(jié)果相符。說明軟件的這部分功能或性能特征與需求規(guī)格說明書相符合，可以被接受。測試結(jié)果與預期結(jié)果不符。說明軟件的這部分功能或性能特征與需求規(guī)格說明書不相符，需要為軟件的這一部分提交問題報告5.3.3確認測試軟件配置復查軟件配置復查的目的是保證軟件配置的所有成分都齊全，各方面的質(zhì)量都符合要求，具有維護階段所必需的細節(jié)，而且已經(jīng)編排好分類的目錄。

除了按合同規(guī)定的內(nèi)容和要求，由人工審查軟件配置之外，在確認測試的過程中，應當嚴格遵守用戶手冊和操作手冊中規(guī)定的使用步驟，以便檢查這些文檔資料的完整性和正確性。必須仔細記錄發(fā)現(xiàn)的遺漏和錯誤，并且適當?shù)匮a充和改正。

5.3.3確認測試驗收測試

驗收測試是以用戶為主的測試。軟件開發(fā)人員和QA（質(zhì)量保證）人員也應參加。由用戶參加設計測試用例，使用用戶界面輸入測試數(shù)據(jù)，并分析測試的輸出結(jié)果。一般使用生產(chǎn)中的實際數(shù)據(jù)進行測試。α測試——是由一個用戶在開發(fā)環(huán)境下進行的測試，也可以是開發(fā)機構(gòu)內(nèi)部的用戶在模擬實際操作環(huán)境下進行的測試。開發(fā)者在整個測試過程中隨時記錄使用中的情況和錯誤，因此α測試是在受控的環(huán)境下進行的測試。β測試——是由軟件的多個用戶在一個或多個用戶的實際使用環(huán)境下進行的測試。測試時，開發(fā)者通常不在測試的現(xiàn)場，因此β測試是在開發(fā)者無法控制的環(huán)境下進行的軟件現(xiàn)場應用。5.3.4系統(tǒng)測試所謂系統(tǒng)測試，是將通過確認測試的軟件，作為整個基于計算機系統(tǒng)的一個元素，與計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素結(jié)合在一起，在實際運行或模擬環(huán)境下，對計算機系統(tǒng)進行一系列的綜合性的測試。系統(tǒng)測試的目的在于通過與系統(tǒng)的需求定義作比較，發(fā)現(xiàn)軟件與系統(tǒng)定義不符合或與之矛盾的地方。系統(tǒng)測試的測試用例應根據(jù)需求分析規(guī)格說明來設計，并在實際使用環(huán)境下來運行。

5.3.4系統(tǒng)測試幾種常見的系統(tǒng)測試功能測試（FunctionTesting） 功能測試的目的是找出軟件系統(tǒng)的功能與規(guī)格說明書中對于產(chǎn)品功能定義之間的差異。容量測試（VolumeTesting） 容量測試的目的是使系統(tǒng)承受超額的數(shù)據(jù)容量來發(fā)現(xiàn)它是否能夠正確處理。壓力測試（StressTesting） 壓力測試的目的是測試在一個短時間里，資源超負荷或數(shù)據(jù)量、活動達到峰值情況下時系統(tǒng)的表現(xiàn)，即測試系統(tǒng)承受速度方面的超額負載。比如：基于Web的應用中用戶的并發(fā)訪問量的測試。5.3.4系統(tǒng)測試可用性測試（UsabilityTesting） 可用性測試是基于程序系統(tǒng)中充分考慮到以人為本的因素而出現(xiàn)的。其目的是檢測用戶在理解和使用系統(tǒng)方面到底有多好。安全性測試（SecurityTesting） 安全性測試的目的是通過測試破壞系統(tǒng)的安全檢查機制，從而暴露系統(tǒng)在安全方面的不足與缺陷。性能測試（PerformanceTesting） 性能測試的目標是度量系統(tǒng)相對于預定義的目標的差異。性能要求包括響應時間、吞吐率等。性能功能測試常和壓力測試一起進行。5.3.4系統(tǒng)測試恢復性測試（RecoveryTesting） 恢復性測試的目的是驗證系統(tǒng)（如操作系統(tǒng)、數(shù)據(jù)庫管理系統(tǒng)等）從軟件或硬件失敗中恢復的能力。其中包含系統(tǒng)能否正確地完成恢復功能，以及系統(tǒng)能否在要求的MTTR時間內(nèi)恢復兩方面的測試。兼容性測試（CompatibilityTesting） 兼容性測試的目的是測試應用對其他應用或系統(tǒng)的兼容性?？砂惭b性測試（Install-abilityTesting） 可安裝性測試的目的是驗證成功安裝系統(tǒng)的能力。5.3.4系統(tǒng)測試文檔測試（DocumentationTesting） 文檔測試的目的是驗證用戶文檔是正確的并且保證操作手冊的過程能正確工作。配置測試（ConfigurationTesting）

配置測試的目的是驗證系統(tǒng)在不同的系統(tǒng)配置下能否正確工作。配置包括：硬件、軟件、網(wǎng)絡等。5.3

軟件測試方法5.3.1軟件測試方法概述靜態(tài)測試 通常不要求在計算機上實際執(zhí)行所測程序，主要以一些人工的模擬技術(shù)對軟件進行分析和測試。代碼審查：由有經(jīng)驗的程序設計人員根據(jù)軟件的詳細設計說明書，閱讀程序來發(fā)現(xiàn)軟件錯誤和缺陷。靜態(tài)分析：主要是對程序進行以圖形的方式表現(xiàn)程序的內(nèi)部結(jié)構(gòu)。主要有控制流分析、數(shù)據(jù)流分析、接口分析和表達式分析等5.4.1軟件測試方法概述動態(tài)測試 通過輸入一組預先按照一定的測試準則構(gòu)造的實例數(shù)據(jù)來動態(tài)運行程序，而達到發(fā)現(xiàn)程序錯誤的過程。白盒測試 根據(jù)軟件產(chǎn)品的內(nèi)部工作過程，在計算機上進行測試，以證實每種內(nèi)部操作是否符合設計規(guī)格要求，所有內(nèi)部成分是否已經(jīng)過檢查黑盒測試 根據(jù)軟件產(chǎn)品的功能設計規(guī)格，在計算機上進行測試，以證實每個實現(xiàn)了的功能是否符合要求。 測試人員完全不考慮程序內(nèi)部的邏輯結(jié)構(gòu)和內(nèi)部特性，只依據(jù)程序的需求分析規(guī)格說明，檢查程序的功能是否符合它的功能說明。5.4.1軟件測試方法概述“窮盡”測試是不可能的！

不論是黑盒測試，還是白盒測試，都不可能把所有可能的輸入數(shù)據(jù)都拿來進行所謂的窮舉測試。因為可能的測試輸入數(shù)據(jù)數(shù)目往往達到天文數(shù)字。5.4.2軟件測試方法表1測試項目比較黑盒測試法

白盒測試法邊界值分析等價類劃分因果分析猜測錯誤邏輯覆蓋

控制結(jié)構(gòu)測試

語句覆蓋

基本路徑測試判定覆蓋條件測試條件覆蓋循環(huán)測試判定/條件覆蓋條件組合覆蓋路徑覆蓋

白盒測試（結(jié)構(gòu)性測試）的基礎是模塊說明書或軟件的詳細設計說明白盒測試按照程序內(nèi)部的邏輯結(jié)構(gòu)測試程序，檢查程序中的每條通路是否能按照預定的要求正確工作黑盒測試（功能性測試）的基礎是軟件的規(guī)格說明把程序看成一個黑盒子，完全不考慮程序的內(nèi)部機構(gòu)和處理過程黑盒測試只檢查程序的功能是否能按照規(guī)格說明書的規(guī)定正常使用，程序是否能適當?shù)慕邮蛰斎霐?shù)據(jù)產(chǎn)生正確的輸出信息，并保持外部信息的完整性5.4.2軟件測試方法黑盒（功能性）測試用例設計方法方法

實例講解等價類劃分邊界值分析因果分析錯誤推測（黑盒）等價類劃分基本思想

根據(jù)程序的輸入數(shù)據(jù)性質(zhì)的不同，將其劃分為幾個不同的集合類，然后從每個集合類中挑選有代表性的數(shù)據(jù)作為測試用例。每個集合類中的數(shù)據(jù)對于發(fā)現(xiàn)程序中的錯誤具有等效的作用。這樣的集合類就被稱為等價類。

無效等價類指的是不合理、無意義的或與規(guī)格說明中的規(guī)定不符的輸入數(shù)據(jù)的集合，利用無效等價類可以測試程序?qū)σ馔獾摹⒉缓侠淼妮斎霐?shù)據(jù)的處理能力即程序的健壯性

有效等價類指的是對于程序的規(guī)格說明來說有意義的、合法的輸入數(shù)據(jù)的集合。利用有效等價類可以檢測程序是否正確實現(xiàn)了要求的功能和處理（黑盒）等價類劃分等價類的劃分方法在輸入條件規(guī)定了取值范圍或值的個數(shù)的情況下，可以確立一個有效等價類和兩個無效等價類。在輸入條件規(guī)定了輸入值的集合或者規(guī)定了“必須如何”的條件的情況下，可以確立一個有效等價類和一個無效等價類在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類在規(guī)定了輸入數(shù)據(jù)的一組值(假定n個)，并且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類在規(guī)定了輸入數(shù)據(jù)必須遵守的規(guī)則的情況下，可確立一個有效等價類(符合規(guī)則)和若干個無效等價類(從不同角度違反規(guī)則)在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步地劃分為更小的等價類（黑盒）等價類劃分等價劃分法的實施基本步驟（1）劃分等價類并列出等價類表（2）構(gòu)造測試用例 根據(jù)已列出的等價類表，按以下步驟確定測試用例：設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步，最后使得所有有效等價類均被測試用例所覆蓋；設計一個新的測試用例，使其只覆蓋一個無效等價類。重復這一步使所有無效等價類均被覆蓋。

應按照輸入條件（如輸入值的范圍，值的個數(shù)，值的集合，輸入條件必須如何）劃分為有效等價類和無效等價類。例如：每個學生可選修1-3門課程可以劃分一個有效等價類：選修1-3門課程?？梢詣澐謨蓚€無效等價類：未選修課，選修課超過3門。輸入等價類有效等價類無效等價類

報表日期的類型及長度6個數(shù)字字符(1)有非數(shù)字字符(4)少于6個數(shù)字字符(5)多于6個數(shù)字字符(6)年份范圍在2001～2005之間(2)小于2001(7)大于2005(8)月份范圍在1～12之間(3)“報表日期”輸入條件的等價類表小于1(9)大于12(10)第一步：等價類劃分（黑盒）等價類劃分第二步：為有效等價類設計測試用例

對表中編號為1,2,3的3個有效等價類用一個測試用例覆蓋：200105等價類(1)(2)(3)輸入有效測試數(shù)據(jù)期望結(jié)果覆蓋范圍第三步：為每一個無效等價類至少設計一個測試用例

測試數(shù)據(jù)期望結(jié)果覆蓋范圍001MAY等價類(4)輸入無效20015等價類(5)輸入無效2001005等價類(6)輸入無效200005等價類(7)輸入無效200805等價類(8)輸入無效200100等價類(9)輸入無效200113等價類(10)輸入無效不能出現(xiàn)相同的測試用例本例的10個等價類至少需要8個測試用例（黑盒）等價類劃分實例講解-1問題陳述（三角形問題）三角形問題接受三個整數(shù)a,b,c作為輸入，用作三角形的邊。程序的輸出是由這三條邊確定的三角形的類型：等邊三角形、等腰三角形、不等邊三角形或非三角形。整數(shù)a,b,c必須滿足以下條件：

c1. 1<=a<=200

c2. 1<=b<=200

c3. 1<=c<=200

c4. a<b+c

c5. b<a+c

c6. c<a+b（黑盒）等價類劃分等價類劃分: R1={<a,b,c>:有三條邊a,b,c的等邊三角形} R2={<a,b,c>:有三條邊a,b,c的等腰三角形} R3={<a,b,c>:有三條邊a,b,c的不等邊三角形} R4={<a,b,c>:三條邊a,b,c不構(gòu)成三角形}a,b,c可能的取值: D1={<a,b,c>:a=b=c} D2={<a,b,c>:a=b,a<>c} D3={<a,b,c>:a=c,a<>b} D4={<a,b,c>:b=c,a<>b} D5={<a,b,c>:a<>c,a<>b,b<>c} D6={<a,b,c>:a>=c+b} D7={<a,b,c>:b>=a+c} D8={<a,b,c>:c>=a+b}（黑盒）等價類劃分實例講解-2問題陳述（標識符定義問題）某PASCAL語言版本中規(guī)定:”標識符由字母開頭,后跟字母或數(shù)字的任意組合構(gòu)成,有效字符數(shù)為8個,最大字符數(shù)為80個.并且標識符必須先說明,再使用.在同一說明語句中,標識符至少必須有一個.

等價類劃分：輸入條件有效等價類無效等價類標識符個數(shù)1個(1),多個(2)0個(3)標識符字符個數(shù)1~8個(4)0個(5),>8個(6),>80個標識符組成字母(8),數(shù)字(9)非字母數(shù)字字符(10),保留字(11)第一個字符字母(12)非字符(13)標識符使用先說明后使用(14)未說明已使用(15)（黑盒）等價類劃分編號用例類的覆蓋情況1VARx,T1234567:REAL;BEGINx:=3.14;T1234567:=2.73;….(1),(2),(4),(8),(9),(12),(14)2VAR:REAL;(3)3VARx,:REAL;(5)4VART12345678:REAL(6)5VART12345…….:REAL;(7)6VART$:CHAR;(10)7VARGOTO:INTEGER;(11)8VAR2T:REAL;(13)9VARPAR:REAL;BEGIN……PAP:=SIN(3.14*0.8)/6;(15)（黑盒）邊界值分析法基本思想

選取輸入/輸出范圍的邊界值、略大于邊界值和略小于邊界值的數(shù)據(jù)來測試程序是否存在錯誤。

邊界是指，相當于輸入等價類和輸出等價類而言，稍高于其邊界值及稍低于其邊界值的一些特定情況。因此，

邊界值分析法可作為等價類劃分法的一種有益補充。

（黑盒）邊界值分析法邊界值法中測試用例的選擇原則（1）如果輸入條件規(guī)定了值的范圍，則應該取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入數(shù)據(jù)；（2）如果輸入條件規(guī)定了值的個數(shù)，則用最大個數(shù)、最小個數(shù)、比最大個數(shù)多1個、比最小個數(shù)少1的數(shù)作為測試數(shù)據(jù)；（3）根據(jù)規(guī)格說明的每一個輸出條件，使用規(guī)則（1）；（4）根據(jù)規(guī)格說明的每一個輸出條件，使用規(guī)則（2）；（5）如果程序的規(guī)格說明給出的輸入域或輸出域是有序集合（如有序表、順序文件等），則應選取集合的第一個和最后一個元素作為測試用例；（6）如果程序用了一個內(nèi)部結(jié)構(gòu)，應該選取這個內(nèi)部數(shù)據(jù)結(jié)構(gòu)的邊界值作為測試用例；（7）分析規(guī)格說明，找出其他可能的邊界條件。（黑盒）邊界值分析法

A按照輸入值范圍的邊界。例如：輸入值的范圍是-1.0至1.0，則可選擇用例:

–1.0、1.0、-1.001、1.001。

B按照輸入/輸出值個數(shù)的邊界。

例如：輸入文件可有1-255個記錄，則設計用例： 文件的記錄數(shù)為0個、1個、255個、256個。

C輸出值域的邊界。

例如：檢索文獻摘要，最多4篇。設計用例： 可檢索0篇、1篇、4篇，和5篇（錯誤）。

D輸入/輸出有序集（如順序文件、線性表）的邊界。

應選擇第一個元素和最后一個元素。輸入條件報表日期的類型及長度1個數(shù)字字符5個數(shù)字字符7個數(shù)字字符有1個非數(shù)字字符全部是非數(shù)字字符6個數(shù)字字符顯示出錯顯示出錯顯示出錯顯示出錯顯示出錯輸入有效日期范圍月份范圍測試用例說明測試數(shù)據(jù)期望結(jié)果選取理由52001520010052001.5MAY---200105月份為1月月份為12月月份<1月份>12200101200112200100200113200101200512200100200513輸入有效輸入有效顯示出錯顯示出錯輸入有效輸入有效顯示出錯顯示出錯在有效范圍邊界上選取數(shù)據(jù)僅有1個合法字符比有效長度少1比有效長度多1只有1個非法字符6個非法字符類型及長度均有效最小日期最大日期剛好小于最小日期剛好大于最大日期最小月份最大月份剛好小于最小月份剛好大于最大月份“報表日期”邊界值分析法測試用例（黑盒）因果圖法

前面介紹的等價類劃分方法和邊界值分析方法，都是著重考慮輸入條件，但未考慮輸入條件之間的聯(lián)系。當需要測試的程序的輸入數(shù)據(jù)之間存在相互的制約關(guān)系或存在輸入情況的不同組合，相應產(chǎn)生多個動作的形式時，就需要用到因果圖法。

因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。

（黑盒）因果圖法因果圖中的因果關(guān)系 通常，在因果圖中，用Ci表示原因，Ei表示結(jié)果。各結(jié)點表示狀態(tài)，可取值“0”或“1”?！?”表示某狀態(tài)不出現(xiàn)，“1”表示某狀態(tài)出現(xiàn)。恒等非或（∨）與（∧）（黑盒）因果圖法因果圖中的約束關(guān)系E：a，b兩個原因不會同時成立，兩個中最多有一個可能成立。

I：a，b，c三個原因中至少有一個必須成立。

O：a和b當中必須有一個，且僅有一個成立。

R：當a出現(xiàn)時，b必須也出現(xiàn)。不可能a出現(xiàn)，b不出現(xiàn)。

M：當a是1時，b必須是0。而當a為0時，b的值不定。（黑盒）因果圖法基本步驟

（1）分析軟件規(guī)格說明描述中，哪些是原因（即輸入條件或輸入條件的等價類），哪些是結(jié)果（即輸出條件），并給每個原因和結(jié)果賦予一個標識符。 （2）分析軟件規(guī)格說明描述中的語義，找出原因與結(jié)果之間，原因與原因之間對應的是什么關(guān)系?根據(jù)這些關(guān)系，畫出因果圖。 （3）由于語法或環(huán)境限制，有些原因與原因之間，原因與結(jié)果之間的組合情況不可能出現(xiàn)。為表明這些特殊情況，在因果圖上用一些記號標明約束或限制條件 （4）把因果圖轉(zhuǎn)換成判定表。 （5）把判定表的每一列拿出來作為依據(jù)，設計測試用例。（黑盒）因果圖法實例講解-1

問題描述: 某個軟件的規(guī)格說明中包含了下面的要求：

第一列字符必須是A或B，第二列字符必須是一個數(shù)字，在此情況下進行文字的修改。但如果第一列字符不正確，則給出信息L;如果第二列字符非數(shù)字，則給出信息M。

（黑盒）因果圖法編號

原因（條件）

編號

結(jié)果（動作）

1第一列字符是

A21修改文件

2第一列字符是

B22給出信息

L3第二列字符是一數(shù)字

23給出信息

M11中間原因

(1)列出原因和結(jié)果(2)畫出因果圖.所有原因結(jié)點列在左邊,所有結(jié)果結(jié)點列在右邊.建立四個中間結(jié)點,表示處理的中間狀態(tài)（黑盒）因果圖法(3)加上約束條件E。

(4)由因果圖得到判定表12345678條件(原因)11111000021100110031010101011111100動作(結(jié)果)220000112110100023010101測試用例

A3AMB5BNC2DYA8A7B4B!X6P（黑盒）因果圖法實例講解-2

一個處理單價為5角錢的飲料的自動售貨機軟件測試用例的設計

問題描述：

若投入5角錢或1元硬幣,按下[澄汁]或[啤酒]的按鈕,則相應的飲料就送出來.若售貨機沒有零錢找,則一個顯示[零錢找完]的紅燈亮,這時在投入1元硬幣并按下按鈕后,飲料不送出來而且1元硬幣也退出來;若有零錢找,則顯示[零錢找完]的紅燈滅,在送出飲料的同時退還5角硬幣（黑盒）因果圖法

原因1.售貨機有零錢找

2.投入1元硬幣

3.投入5角硬幣

4.按下澄汁按鈕

5.按下啤酒按鈕

結(jié)果21.售貨機[零錢找完]的紅燈亮

22.退還1元硬幣

23.退還5角硬幣

24.送出澄汁飲料

25.送出啤酒飲料(1)列出原因和結(jié)果(2)畫出因果圖.所有原因結(jié)點列在左邊,所有結(jié)果結(jié)點列在右邊.建立四個中間結(jié)點,表示處理的中間狀態(tài).（黑盒）因果圖法中間結(jié)點:11.投入1元硬幣并按下飲料按鈕

12.按下[澄汁]或[啤酒]的按鈕

13.應當找5角硬幣并且售貨機有零錢找

14.錢已付清因為2/3,4/5不能同時發(fā)生,分別加上約束條件E（黑盒）因果圖法(4)由因果圖得到判定表(3)由于2與3，4與5不能同時發(fā)生，分別加上約束條件E。

（黑盒）錯誤推測法

等價類劃分和邊界值分析法都只是孤立的考慮各種測試用例的效果，因果圖是比較機械的設計測試用例。他們都缺乏綜合考慮的效應。基本思想通過經(jīng)驗或直覺推測程序中可能存在的各種錯誤，從而有針對性設計測試用例。白盒（結(jié)構(gòu)性）測試用例的設計方法---覆蓋測試表結(jié)構(gòu)性測試覆蓋標準標準

覆蓋說明語句覆蓋使被測程序中的每個語句至少執(zhí)行一次判定覆蓋語句覆蓋+每個判定的每種可能的結(jié)果至少執(zhí)行一次條件覆蓋語句覆蓋+判定表達式中的每個條件都取到各種可能的結(jié)果判定/條件覆蓋判定覆蓋+條件覆蓋條件組合覆蓋每個判定表達式中條件的各種可能組合都至少出現(xiàn)一次路徑覆蓋程序的每一條可能路徑都至少執(zhí)行一次（如果程序圖中有環(huán)，則要求每個環(huán)至少要經(jīng)過一次）

白盒法需要了解程序的功能與結(jié)構(gòu)，測試用例必須根據(jù)程序內(nèi)部的邏輯來設計。如果想用白盒法發(fā)現(xiàn)程序中的所有錯誤，則至少必須使程序中每種可能的路徑都執(zhí)行一次。白盒法又稱為邏輯覆蓋法，目前常用的覆蓋標準有：白盒（結(jié)構(gòu)性）方法實例圖1被測模塊的流程圖被測模塊的源程序BEGIN

……

IF(A>1)AND(B=0)

THENX:=X/A

IF(A=2ORX>1)

THENX:=X+1

END入口A>1ANDB=0X=X/AA=2ORX>1X=X+1返回TTabcde1234567s白盒（結(jié)構(gòu)性）方法-語句覆蓋入口A>1ANDB=0X=X/AA=2ORX>1X=X+1返回TTabcde1234567圖2被測模塊的流程圖測試分析：1.該測試用例可以使每條語句都執(zhí)行一次2.如果將程序中的第2個判定的OR改為AND，將不能發(fā)現(xiàn)錯誤3.將第2個判定的“X>1”誤寫為”X<1”，將不能發(fā)現(xiàn)錯誤測試用例程序執(zhí)行路徑A=2,B=0,X=4sacbed特點：

語句覆蓋只關(guān)心判定表達式的值，而沒有分別測試判定表達式中每個條件取不同的值時的情況白盒（結(jié)構(gòu)性）方法-判定覆蓋圖3被測模塊的流程圖測試分析：1.該測試用例可以使每個判定分支都執(zhí)行一次2.將第2個判定的“X>1”誤寫為”X<1”，仍然不能發(fā)現(xiàn)錯誤測試用例程序執(zhí)行路徑A=3,B=0,X=3sacbdA=2,B=1,X=1sabed入口A>1ANDB=0X=X/AA=2ORX>1X=X+1返回TTabcde1234567s白盒（結(jié)構(gòu)性）方法-條件覆蓋入口A>1ANDB=0X=X/AA=2ORX>1X=X+1返回TTabcde1234567s圖4被測模塊的流程圖測試用例程序執(zhí)行路徑A=2,B=0,X=3sabdA=1,B=1,X=1scbed測試分析：1.該測試用例可以使每個判定內(nèi)部的條件都能夠取一次“真”和“假”

即：下面的每個取值都出現(xiàn)一次

A>1B=0A=2X>1

A<=1B<>0A<>2X<=12.仍然無法發(fā)現(xiàn)第2個判定表達式中的錯誤3.條件覆蓋看起來似乎覆蓋了判定覆蓋，實際卻不一定。對于第1個判定式：若使用測試用例：A=2,B=1和A=0,B=0，則判定永遠為假，后面的“X=X/A”語句永遠也檢測不到。白盒（結(jié)構(gòu)性）方法-判定/條件覆蓋入口A>1ANDB=0X=X/AA=2ORX>1X=X+1返回TTabcde1234567s圖5被測模塊的流程圖測試用例（與條件覆蓋同）程序執(zhí)行路徑A=2,B=0,X=3sabdA=1,B=1,X=1scbed測試分析：1.該測試用例可以使判定中的條件都能夠取一次“真”和“假”，且每個判定本身的所有結(jié)果至少出現(xiàn)一次2.這組測試用例與上面的條件覆蓋的測試用例相同，這說明，有時判定/條件覆蓋并不比條件覆蓋更強。白盒（結(jié)構(gòu)性）方法-條件組合覆蓋（1）入口A>1ANDB=0X=X/AA=2OR

X>1X=X+1返回TTabcde1234567s圖6被測模塊的流程圖測試分析：1.該測試用例可使判定表達式中條件的各種可能組合都至少出現(xiàn)一次2.滿足條件組合測試覆蓋標準的測試數(shù)據(jù)，也一定滿足判定覆蓋、條件覆蓋、判定/條件覆蓋。3.滿足條件組合測試覆蓋標準的測試數(shù)據(jù)并不一定能使程序中的每條路徑都執(zhí)行到。例如：本測試方案中路徑sacbd就沒有測試到測試用例程序執(zhí)行路徑A=2,B=0,X=4sacbedA=2,B=1,X=1sabedA=1,B=0,X=2sabedA=1,B=1,X=1sabd白盒（結(jié)構(gòu)性）方法-條件組合覆蓋（2）A>1B=0A=2,B=0,X=4A>1B<>0A=2,B=1,X=1A<=1B=0A=1,B=0,X=2A<=1B<>0A=1,B=1,X=1A=2X>1A=2,B=0,X=4A=2X<=1A=2,B=1,X=1A<>2X>1A=1,B=0,X=2A<>2X<=1A=1,B=1,X=1入口A>1X=X/AA=2X=X+1返回TTabcdesB=0X>1TT圖7圖6的計算機執(zhí)行的實際流程圖白盒（結(jié)構(gòu)性）方法-路徑覆蓋入口A>1ANDB=0X=X/AA=2OR

X>1X=X+1返回TTabcde1234567s圖8被測模塊的流程圖測試分析：1.該測試用例可使使程序的每一條可能路徑都至少執(zhí)行一次2.路徑覆蓋是相當強的邏輯覆蓋標準，但他沒有檢驗表達式中條件的各種可能組合情況；結(jié)合路經(jīng)測試和條件組合測試，可以設計出檢錯能力更強的測試數(shù)據(jù)測試用例程序執(zhí)行路徑A=2,B=0,X=4sacbedA=1,B=1,X=1sabdA=1,B=1,X=2sabedA=3,B=0,X=3sacbd白盒（結(jié)構(gòu)性）測試用例的設計方法---基本路徑測試表控制結(jié)構(gòu)測試基本路徑測試測試用例能保證每條語句至少執(zhí)行一次,每個條件在執(zhí)行時分別取真假兩種值條件測試測試用例能檢查程序模塊中包含的邏輯條件循環(huán)測試測試循環(huán)結(jié)構(gòu)的有效性

現(xiàn)在的很多結(jié)構(gòu)性測試技術(shù)，是根據(jù)程序的控制結(jié)構(gòu)設計測試數(shù)據(jù)的技術(shù)，下面列出了幾種常用的控制結(jié)構(gòu)測試技術(shù)。本節(jié)重點介紹基本路徑測試（白盒）基本路徑法

基本路徑測試，首先計算程序的環(huán)形復雜度，并用該復雜度為指南定義執(zhí)行路徑的基本集合，從該基本集合導出的測試用例可以保證程序中的每條語句至少執(zhí)行一次，而且每個條件在執(zhí)行時都將分別取真、假兩種值。（白盒）基本路徑法第一步，根據(jù)過程設計結(jié)果畫出相應的流圖。第二步，計算流圖的環(huán)形復雜度。第三步，確立線性獨立路徑的基本集合所謂獨立路徑是指至少引入程序的一個新處理語句集合或一個新條件的路徑，也就是說，獨立路徑至少包含一條在定義該路徑之前不曾用過的邊。使用基本路徑測試法設計測試用例時，程序的環(huán)形復雜度決定了程序中獨立路徑的數(shù)量，而且這個數(shù)是確保程序中所有語句至少被執(zhí)行一次所需的測試數(shù)量的上界。第四步，設計可強制執(zhí)行基本集合中每條路徑的測試用例。（白盒）基本路徑法106分析例子流圖環(huán)形復雜度6基本集合（白盒）條件測試基本路徑測試簡單高效，但是只有這樣的技術(shù)還不夠，為了進一步提高白盒測試的質(zhì)量，還需要使用其他控制結(jié)構(gòu)技術(shù)。條件測試技術(shù)設計出的測試用例，能夠檢查程序模塊中包含的邏輯條件。條件測試基礎簡單條件格式：一個布爾變量或一個關(guān)系表達式，在布爾變量或關(guān)系表達式之前還可能有一個NOT算符。關(guān)系表達式的形式如下：

E1<關(guān)系算符>E2

關(guān)系算符:>,<,≥≤≠=復合條件：復合條件由兩個或多個簡單條件、布爾算符和括弧組成。布爾算符有OR，AND和NOT。不包含關(guān)系表達式的條件稱為布爾表達式。條件成分類型：包括布爾算符、布爾變量、布爾括弧、關(guān)系算符及算術(shù)表達式。（白盒）條件測試條件測試的目的不僅是檢測程序條件中的錯誤，而且是檢測程序中的其他錯誤。如果程序P的測試集能有效地檢測P中條件的錯誤，則它很可能也可以有效地檢測P中的其他錯誤