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

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

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