軟件測試第四章單元測試

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

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

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