軟件測試技術(shù)東北大學(xué)軟件學(xué)院吳辰鈮第四章單元測試主要內(nèi)容4.1什么是單元測試4.2單元測試策略4.3單元測試分析4.4單元測試用例設(shè)計4.5單元測試過程4.6單元測試應(yīng)堅持的原則4.7小結(jié)4.1什么是單元測試規(guī)格定義設(shè)計編碼系統(tǒng)測試集成測試單元測試用戶需求驗收測試回歸測試配置管理缺陷跟蹤4.1什么是單元測試單元測試（UnitTesting）是對軟件基本組成單元進(jìn)行的測試，又稱為模塊測試。單元的基本屬性：明確的功能規(guī)格定義與其它部分明確的接口定義例：C++中的public的成員函數(shù)，單獨(dú)的函數(shù)或類。4.1什么是單元測試單元測試的目的：驗證代碼是否與設(shè)計相符；跟蹤需求和設(shè)計的實現(xiàn)；發(fā)現(xiàn)設(shè)計和需求中存在的錯誤；發(fā)現(xiàn)編碼過程中引入的錯誤。4.1什么是單元測試對單元測試的誤解單元測試?yán)速M(fèi)了太多時間。單元測試僅僅是證明這些代碼做了些什么。我是個很棒的程序員，我可以不進(jìn)行單元測試。不管怎樣，集成測試將會抓住所有的Bug。它的成本效率不高。4.2單元測試策略樁模塊（Stub）：用以模擬被測模塊工作過程中所調(diào)用的模塊，它們一般只進(jìn)行很少的數(shù)據(jù)處理，例如打印入口和返回。驅(qū)動模塊（Driver）：用以模擬被測模塊的上級模塊，它接受測試數(shù)據(jù)，把相關(guān)的數(shù)據(jù)傳送給被測模塊，啟動被測模塊，并打印相應(yīng)的結(jié)果。4.2單元測試策略由頂向下的單元測試策略先對最頂層的單元進(jìn)行測試，把頂層所調(diào)用的單元做成樁模塊，其次對第二層進(jìn)行測試，使用上面已測試的單元做驅(qū)動模塊，以此類推。

由底向上的單元測試策略先對模塊調(diào)用層次圖上最底層的模塊進(jìn)行單元測試，為該模塊建立驅(qū)動模塊，其次對上一層做單元測試，下面測試過的模塊做樁模塊，以此類推。

孤立測試不考慮每個模塊與其他模塊之間的關(guān)系，為每個模塊設(shè)計樁模塊和驅(qū)動模塊。4.3單元測試分析單元測試所考慮的方面：局部數(shù)據(jù)結(jié)構(gòu)模塊接口出錯處理獨(dú)立路徑邊界條件模塊4.3單元測試分析模塊接口：調(diào)用所測模塊時的輸入?yún)?shù)與模塊的形參在個數(shù)、屬性、順序上是否匹配。參數(shù)與變量的屬性、單位是否一致。全局變量的定義在每個模塊中是否一致。是否修改只是作為輸入值的變量。有沒有把常數(shù)當(dāng)變量來傳送。調(diào)用內(nèi)部函數(shù)時，變量的個數(shù)、屬性和次序是否正確。4.3單元測試分析局部數(shù)據(jù)結(jié)構(gòu)：檢查不正確或不一致的數(shù)據(jù)類型說明。使用尚未賦值或尚未初始化的變量。錯誤的初始值或錯誤的默認(rèn)值。變量名拼寫錯誤或書寫錯誤。不一致的數(shù)據(jù)類型。上溢、下溢或地址錯誤。4.3單元測試分析獨(dú)立路徑：誤解或不正確的算術(shù)優(yōu)先級。運(yùn)算方式錯誤。不同數(shù)據(jù)類型的比較。不正確的邏輯運(yùn)算符或優(yōu)先次序。錯誤或不可能的循環(huán)終止條件。不恰當(dāng)?shù)男薷牧搜h(huán)變量。因浮點數(shù)運(yùn)算精度問題而造成的兩值比較不等。4.3單元測試分析出錯處理：出錯的描述難以理解。出錯的描述不足以對錯誤定位和確定出錯的原因。顯示的錯誤與實際的錯誤不符。對錯誤條件的處理不正確。在對錯誤進(jìn)行處理之前，錯誤條件已經(jīng)引起系統(tǒng)的干預(yù)。遺漏的錯誤處理。4.3單元測試分析邊界條件：循環(huán)條件?？刂屏髦袆偤玫扔凇⒋笥?、小于確定的比較值時出現(xiàn)錯誤的可能性。4.4單元測試用例設(shè)計為系統(tǒng)運(yùn)行起來而設(shè)計用例為正向測試設(shè)計用例驗證設(shè)計說明書所對應(yīng)的功能項或性能指標(biāo)能否兌現(xiàn)。為逆向測試設(shè)計用例驗證被測的軟件單元有沒有做它不應(yīng)該做的事情。為滿足特殊需求設(shè)計用例為代碼覆蓋設(shè)計用例為覆蓋率指標(biāo)完成設(shè)計用例4.4單元測試用例設(shè)計主要采用的方法：等價類劃分邊界值分析定義/使用測試邏輯覆蓋測試路徑測試4.5單元測試過程測試計劃測試設(shè)計測試執(zhí)行測試記錄分析測試總結(jié)完畢缺陷跟蹤針對測試目標(biāo)，規(guī)定測試任務(wù)、資源分配、人員角色、進(jìn)度安排等。根據(jù)測試計劃，設(shè)計測試用例，包括：測試步驟、測試場景、測試代碼、測試數(shù)據(jù)(包括預(yù)期結(jié)果)。根據(jù)測試計劃，配置測試環(huán)境，并手動或者自動執(zhí)行測試設(shè)計。根據(jù)測試計劃，忠實地記錄測試執(zhí)行的過程和結(jié)果。分析測試記錄，如果發(fā)現(xiàn)與預(yù)期結(jié)果不同，確定并重現(xiàn)缺陷。檢查測試設(shè)計是否全部執(zhí)行完畢，缺陷是否全部關(guān)閉。記錄、分發(fā)、評估、關(guān)閉缺陷報告。分析測試過程和缺陷報告，評估測試質(zhì)量和測試效果，給出是否通過測試的建議。4.5單元測試過程測試文檔：測試計劃測試設(shè)計測試執(zhí)行測試記錄分析測試總結(jié)完畢缺陷跟蹤測試計劃文檔測試用例文檔測試記錄文檔缺陷跟蹤報告測試總結(jié)報告4.5單元測試過程測試計劃內(nèi)容：概要：明確測試目的和主要任務(wù)，被測系統(tǒng)的簡單描述，被測系統(tǒng)依賴的其它系統(tǒng)描述。領(lǐng)域：定義測試和不需要測試的內(nèi)容，描述與測試計劃相關(guān)的重要術(shù)語和縮略語，測試場所。測試內(nèi)容。建議的重大事件時間表：列出階段性進(jìn)度。測試配置和環(huán)境。測試執(zhí)行：錯誤管理，測試周期等。風(fēng)險和意外事故：意外事件的對策。更改記錄：到目前為止對測試計劃本身所作的更改和修訂。內(nèi)容可包括：編號、更改人、更改內(nèi)容、修訂的發(fā)布時間等。參考文檔：項目開發(fā)計劃。4.5單元測試過程錯誤管理—缺陷的級別：致命性錯誤（Critical）數(shù)據(jù)丟失，數(shù)據(jù)計算錯誤、系統(tǒng)崩潰和經(jīng)常死機(jī)。嚴(yán)重功能性錯誤(Serious)規(guī)定的功能沒有實現(xiàn)或不完整、設(shè)計不合理造成性能低下，影響系統(tǒng)的運(yùn)營。告警性錯誤(Moderate)不影響業(yè)務(wù)運(yùn)營的功能問題。建議性錯誤(Suggestion,Cosmetic)軟件設(shè)計和功能實現(xiàn)等不甚合理之處提出建議。4.5單元測試過程錯誤管理-錯誤描述：1.分配給錯誤的ID號2.提交錯誤的時間3.錯誤提交人4.版本號發(fā)生錯誤的子系統(tǒng)或模塊5.錯誤發(fā)生的條件6.對錯誤的詳細(xì)描述7.所使用的測試用例號8.錯誤被發(fā)現(xiàn)的數(shù)據(jù)庫9.使用的機(jī)器號10.錯誤的重要性11.錯誤的改正優(yōu)先級12.發(fā)生錯誤的子系統(tǒng)或模塊及相關(guān)的模塊13.錯誤是否易再現(xiàn)14.其他4.5單元測試過程錯誤管理-錯誤跟蹤：1.錯誤負(fù)責(zé)人6.錯誤改正后需要重新做的測試2.嚴(yán)重性7.改正錯誤所影響的組件3.優(yōu)先級8.目前錯誤的狀態(tài)4.估計改正錯誤的日期9.錯誤類別5.估計改正錯誤所要花費(fèi)的時間10.解決辦法4.5單元測試過程錯誤管理-錯誤分發(fā)：項目管理者測試管理者被分配修改錯誤的人組件代碼的編寫人測試小組中的其他成員4.5單元測試過程錯誤管理-益處：有利于缺陷的清楚傳達(dá)依據(jù)錯誤的相對和絕對重要性來修復(fù)問題對錯誤實現(xiàn)全生命周期管理當(dāng)錯誤變化時相關(guān)人員及時獲悉新的信息錯誤的統(tǒng)計分析報告提供更多的信息4.5單元測試過程錯誤管理-方法：使用商業(yè)錯誤跟蹤與管理系統(tǒng)TestdirectorIBMRational自行開發(fā)專用錯誤跟蹤與管理系統(tǒng)4.5單元測試過程測試報告內(nèi)容：1.測試活動概述6.結(jié)果描述2.測試環(huán)境描述7.意外事件3.測試資源使用情況8.遺留問題4.差異描述9.評價5.測試充分性的評價10.測試總結(jié)4.6單元測試應(yīng)堅持的原則應(yīng)當(dāng)盡早和不斷地進(jìn)行軟件測試。對全新的代碼或修改過的代碼一定要進(jìn)行單元測試。被測試的對象為實現(xiàn)一組相關(guān)功能的代碼。單元測試最好根據(jù)單元測試計劃和方案進(jìn)行，排除測試的隨意性。當(dāng)測試用例的測試結(jié)果與預(yù)期