軟件測試全套課件和教案-第3章-單元測試

單元測試單元測試1為什么要進(jìn)行單元測試2單元測試的基本概念3單元測試過程對于單元測試的一些錯(cuò)誤認(rèn)識太浪費(fèi)時(shí)間了，現(xiàn)在要趕進(jìn)度，時(shí)間上根本不允許，或者隨便做做應(yīng)付領(lǐng)導(dǎo)。我是一個(gè)很棒的程序員，我寫的代碼肯定是沒有問題的。做單元測試太煩了，直接集成，到時(shí)有問題在集成測試時(shí)肯定能發(fā)現(xiàn)的，實(shí)在不行在系統(tǒng)測試總該能發(fā)現(xiàn)吧。它僅僅是證明這些代碼做了什么。單元測試具有的優(yōu)點(diǎn)它是一種驗(yàn)證行為。它是一種設(shè)計(jì)行為。它是一種編寫文檔的行為。它具有回歸性。為什么要進(jìn)行單元測試？驗(yàn)證代碼的正確性：單元測試可以幫助開發(fā)人員驗(yàn)證代碼的正確性，確保代碼按照預(yù)期工作。通過編寫測試用例并執(zhí)行單元測試，可以盡早發(fā)現(xiàn)代碼中存在的問題，提高代碼質(zhì)量。提高代碼可維護(hù)性：單元測試可以幫助開發(fā)人員理解代碼的邏輯結(jié)構(gòu)和功能，提高代碼的可讀性和可維護(hù)性。通過編寫測試用例，開發(fā)人員可以更加清晰地了解代碼各部分的作用和關(guān)聯(lián)，有助于后續(xù)開發(fā)和維護(hù)工作。方便重構(gòu)和優(yōu)化：單元測試可以確保代碼在重構(gòu)和優(yōu)化過程中不會(huì)引入新的問題或破壞原有功能。通過運(yùn)行測試用例，開發(fā)人員可以及時(shí)發(fā)現(xiàn)重構(gòu)或優(yōu)化后的代碼是否依然符合預(yù)期的功能。促進(jìn)團(tuán)隊(duì)合作：編寫單元測試可以促進(jìn)團(tuán)隊(duì)成員之間的合作和溝通。通過共享測試用例和結(jié)果，團(tuán)隊(duì)成員可以更好地理解彼此編寫的代碼，并協(xié)助發(fā)現(xiàn)和解決潛在問題。節(jié)省時(shí)間和成本：盡早發(fā)現(xiàn)和修復(fù)問題可以避免在后期開發(fā)階段花費(fèi)更多的時(shí)間和成本。通過自動(dòng)化運(yùn)行單元測試，可以有效地提高代碼質(zhì)量，減少后續(xù)測試和調(diào)試的工作量。單元測試的基本概念單元測試是一種細(xì)粒度的測試，又稱模塊測試。屬于白盒測試，是最小單位的測試。模塊可分為程序模塊和功能模塊。單元測試的對象單元測試的對象是軟件設(shè)計(jì)的最小單位——模塊或函數(shù)，單元測試的依據(jù)是詳細(xì)設(shè)計(jì)描述。測試的內(nèi)容模塊接口測試局部數(shù)據(jù)結(jié)構(gòu)測試路徑測試錯(cuò)誤處理測試邊界測試模塊接口調(diào)用所測模塊的輸入?yún)?shù)與模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；所測模塊調(diào)用子模塊時(shí)，它輸入個(gè)子模塊的參數(shù)與子模塊的形式參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；是否修改了只做輸入用的形式參數(shù)；輸出給標(biāo)準(zhǔn)函數(shù)的參數(shù)在個(gè)數(shù)、屬性、順序上是否匹配；全局變量的定義在各模塊中是否一致；限制是否通過形式參數(shù)來傳送。局部數(shù)據(jù)結(jié)構(gòu)測試檢查不正確或不一致的數(shù)據(jù)類型說明；使用尚未賦值或尚未初始化的變量；錯(cuò)誤的初始值或錯(cuò)誤的默認(rèn)值；變量名拼寫錯(cuò)誤或書寫錯(cuò)誤；不一致的數(shù)據(jù)類型。路徑測試常見的不正確的計(jì)算有：運(yùn)算的優(yōu)先次序不正確或誤解了運(yùn)算的優(yōu)先次序；運(yùn)算的方式錯(cuò)誤（運(yùn)算的對象彼此在類型上不相容）；算法錯(cuò)誤；初始化不正確；運(yùn)算精度不夠；表達(dá)式的符號表示不正確等。常見的比較和控制流錯(cuò)誤有：不同數(shù)據(jù)類型的比較；不正確的邏輯運(yùn)算符或優(yōu)先次序；因浮點(diǎn)運(yùn)算精度問題而造成的兩值比較不等；關(guān)系表達(dá)式中不正確的變量和比較符；“差1錯(cuò)”，即不正確地多循環(huán)或少循環(huán)一次；錯(cuò)誤的或不可能的循環(huán)終止條件；當(dāng)遇到發(fā)散的迭代時(shí)不能終止循環(huán)；不適當(dāng)?shù)匦薷牧搜h(huán)變量等。錯(cuò)誤處理測試出錯(cuò)的描述難以理解；出錯(cuò)的描述不足以對錯(cuò)誤定位和確定出錯(cuò)的原因；顯示的錯(cuò)誤與實(shí)際的錯(cuò)誤不符；對錯(cuò)誤條件的處理不正確；在對錯(cuò)誤進(jìn)行處理之前，錯(cuò)誤條件已經(jīng)引起系統(tǒng)的干預(yù)；如果出錯(cuò)情況不予考慮，那么檢查恢復(fù)正常后模塊可否正常工作。邊界測試在n次循環(huán)的第0次、1次、n次是否有錯(cuò)誤；運(yùn)算或判斷中取最大最小值時(shí)是否有錯(cuò)誤；數(shù)據(jù)流、控制流中剛好等于、大于、小于確定的比較值時(shí)是否出現(xiàn)錯(cuò)誤。單元測試的環(huán)境構(gòu)成在單元測試時(shí)，如果模塊不是獨(dú)立的程序，需要輔助測試模塊，有兩種輔助模塊：驅(qū)動(dòng)模塊（Driver）樁模塊（Stub）主要單元測試方法人工靜態(tài)分析自動(dòng)靜態(tài)分析自動(dòng)動(dòng)態(tài)測試人工動(dòng)態(tài)測試測試過程中各種人員的作用系統(tǒng)分析設(shè)計(jì)人員進(jìn)行需求跟蹤，確保系統(tǒng)需求的實(shí)現(xiàn)和更新。進(jìn)行軟件單元可測性分析，確定單元測試的對象、范圍和方法。軟件開發(fā)人員負(fù)責(zé)編碼和單元測試過程，完成單元測試計(jì)劃、方案和報(bào)告。軟件測試人員參與單元測試計(jì)劃、方案和報(bào)告的評審，對單元測試的計(jì)劃、設(shè)計(jì)和執(zhí)行質(zhì)量進(jìn)行監(jiān)控。根據(jù)實(shí)際情況，可選擇參與由開發(fā)人員負(fù)責(zé)的代碼檢視、單元測試等活動(dòng)。

配置管理人員對代碼及單元測試文檔進(jìn)行配置管理。質(zhì)量保證（QA）人員參與編碼與單元測試評審，對編碼和單元測試過程進(jìn)行審計(jì)。

單元測試輸入《軟件需求規(guī)格說明書》《軟件詳細(xì)設(shè)計(jì)說明書》《軟件編碼與單元測試工作任務(wù)書》《軟件集成測試計(jì)劃》《軟件集成測試方案》用戶文檔單元測試的輸出《單元測試計(jì)劃》《單元測試方案》《需求跟蹤說明書》或需求跟蹤記錄代碼靜態(tài)檢查記錄《正規(guī)檢視報(bào)告》問題記錄問題跟蹤和解決記錄軟件代碼開發(fā)版本《單元測試報(bào)告》《軟件編碼與單元測試任務(wù)總結(jié)報(bào)告》本章小結(jié)單元測試不但保證局部代碼的質(zhì)量，同時(shí)使開發(fā)過程自然而然地變得"敏捷"。單元測試對項(xiàng)目或產(chǎn)品的整個(gè)生命周期都具有積極的影響：對需求分析、設(shè)計(jì)的影響：自動(dòng)回歸測試可以發(fā)現(xiàn)代碼修改所引入的錯(cuò)誤，使開發(fā)過程可以適應(yīng)頻繁變化的需求，減輕需求分析和架構(gòu)設(shè)計(jì)的壓力，輕松實(shí)現(xiàn)螺旋式的開發(fā)過程。對后期測試的影響：由于代碼錯(cuò)誤已很少，大幅減少集成測試和系統(tǒng)測試的成本，自動(dòng)回