培訓(xùn)教材2-軟件單元測試

軟件測試實(shí)際—單元測試

.課程內(nèi)容1.為什么做單元測試2.單元測試的概念和內(nèi)容3.如何做單元測試4.單元測試的難點(diǎn)和對策.程序員的難題開發(fā)的模塊出現(xiàn)問題，很難定位，曾經(jīng)熬了幾個(gè)通宵了?。?！怎樣辦？剛矯正了一個(gè)BUG，過沒幾天，又發(fā)現(xiàn)了新問題?。?！程序總在出問題，聯(lián)調(diào)了幾個(gè)月，還是問題不斷！??！.高質(zhì)量的程序高質(zhì)量的程序取決于以下幾個(gè)方面：1.高質(zhì)量的設(shè)計(jì)2.規(guī)范的編碼3.有效的測試.程序員的職責(zé)我是程序員，除了編碼我還需做些什么？.程序員的職責(zé)傳統(tǒng)的開發(fā)觀念？1.開發(fā)人員的義務(wù)是完成編程，讓系統(tǒng)正確運(yùn)轉(zhuǎn)起來。2.程序調(diào)試經(jīng)過義務(wù)就完成了。3.自信本人的程序不會出錯(cuò)。實(shí)踐：1.開發(fā)人員的義務(wù)是完成程序，直到交付和維護(hù)。2.人的失誤是不可防止的，無論多小心，都會有錯(cuò)誤。.小插曲他以前做過程序開發(fā)任務(wù)么？他是怎樣自測的？效果如何？.現(xiàn)實(shí)中的發(fā)現(xiàn)編碼階段引入的缺陷遠(yuǎn)遠(yuǎn)多于其它階段系統(tǒng)測試發(fā)現(xiàn)的缺陷大多數(shù)是編碼缺陷測試版本頻繁，測試和工程進(jìn)度被無休止的拖延。

Why?.開發(fā)部的壓力現(xiàn)狀：一個(gè)承當(dāng)多個(gè)角色的團(tuán)隊(duì)參與或部分參與高層設(shè)計(jì)；承當(dāng)?shù)蛯釉O(shè)計(jì)；程序?qū)崿F(xiàn)；承當(dāng)?shù)蛯訙y試；設(shè)計(jì)編碼測試.開發(fā)部的測試效果不好：為什么？沒有時(shí)間測試不知道怎樣測試不好組織缺乏方法和工具這種情況下，往往把單元測試的義務(wù)堆積到系統(tǒng)測試階段.問題假設(shè)把單元測試的義務(wù)堆積到系統(tǒng)測試階段，將會怎樣？大量的缺點(diǎn)堆積在工程中后期：工程后10%的任務(wù)，占用了工程90%的時(shí)間。缺點(diǎn)難以定位缺點(diǎn)飄忽不定開發(fā)、測試人員疲于奔命.軟件缺陷的修復(fù)費(fèi)用.單元測試〔why〕最高的本錢收益比減少聯(lián)調(diào)和后續(xù)測試的時(shí)間BUG更容易定位更有自信心去修正老代碼.業(yè)界平均程度商業(yè)軟件單元測試任務(wù)量/總?cè)蝿?wù)量=8.3%編碼任務(wù)量/總?cè)蝿?wù)量=16.6%軍工軟件單元測試任務(wù)量/總?cè)蝿?wù)量=10.1%編碼任務(wù)量/總?cè)蝿?wù)量=18.1%.業(yè)界標(biāo)桿單元測試〔25%〕審查評審〔20%〕設(shè)計(jì)〔17%〕編碼〔14%〕需求〔7%〕系統(tǒng)測試〔4%〕方案和跟蹤〔4%〕發(fā)布后缺陷0.06Defects/KLOC單元測試發(fā)現(xiàn)的缺陷密度：31defects/KLOC.主題內(nèi)容1.為什么做單元測試2.單元測試的概念和內(nèi)容3.如何做單元測試4.單元測試的難點(diǎn)和對策.單元是什么？(IEEE)軟件單元指軟件設(shè)計(jì)闡明中一個(gè)可獨(dú)立測試的元素，是程序中一個(gè)邏輯上獨(dú)立的部分，它不能再分解為其他軟件成分。(實(shí)際中)軟件單元指軟件源代碼中單個(gè)的函數(shù)，源文件或類。.單元測試是什么？單元測試，對單個(gè)的軟件單元或者一組相關(guān)的軟件單元所進(jìn)展的測試，是代碼級的測試。Unit：函數(shù)，源代碼文件，類把測試比作是清洗一臺機(jī)器：系統(tǒng)測試就是去除機(jī)器外面的塵土。集成測試就是保證機(jī)器各個(gè)部件的接頭處干凈。單元測試就是清洗各個(gè)零件的內(nèi)部。.單元測試運(yùn)用輸入潛在錯(cuò)誤對象.單元測試測試一個(gè)類Thatiseasy!.單元測試原那么應(yīng)該盡早地進(jìn)展軟件單元測試。應(yīng)該保證單元測試的可反復(fù)性。盡能夠地采用測試自動化的手段來支持單元測試活動。.單元測試內(nèi)容單元功能測試單元接口測試單元部分?jǐn)?shù)據(jù)構(gòu)造測試單元中重要的執(zhí)行途徑測試單元的各類錯(cuò)誤處置途徑測試單元邊境條件測試.單元測試內(nèi)容開發(fā)測試設(shè)計(jì)評審代碼走查單元測試集成測試面向單元的白盒測試〔單元覆蓋率測試〕狹義的單元測試內(nèi)容面向單元的黑盒測試〔單元功能測試〕內(nèi)存和運(yùn)轉(zhuǎn)錯(cuò)誤分析〔內(nèi)存走漏、越界，異?！炒a運(yùn)轉(zhuǎn)性能profile〔函數(shù)效率和瓶頸分析〕.單元測試〔who〕單元測試可以是開發(fā)者本人執(zhí)行，也可以是獨(dú)立的專業(yè)測試人員執(zhí)行。兩者各有優(yōu)勢。建議開發(fā)人員必需完好地做單元測試，同時(shí)測試人員針對重點(diǎn)模塊實(shí)施獨(dú)立的單元測試。.主題內(nèi)容1.為什么做單元測試2.單元測試的概念和內(nèi)容3.如何做單元測試4.單元測試的難點(diǎn)和對策.單元測試過程單元測試過程包括8個(gè)活動：確定單元測試方案確定待測特性制定單元測試規(guī)程設(shè)計(jì)測試套件構(gòu)建測試套件執(zhí)行測試套件檢查終止條件評價(jià)測試結(jié)果.確定單元測試方案確定單元測試范圍盡能夠爭取完全地覆蓋〔原那么上應(yīng)該做到完全覆蓋〕參考：通常以下情況必需安排單元測試：a〕新模塊b〕新增代碼比例超越20％c〕中心模塊.確定單元測試方案單元測試充分性要求例如：語句行覆蓋率=100%；分支覆蓋率〉85%測試覆蓋率要求是測試充分性的一個(gè)方面，除此之外，在單元測試中還應(yīng)思索每個(gè)軟件特性的測試覆蓋，如函數(shù)性能。.確定單元測試方案確定終止條件確定單元測試過程的正常終止條件。該終止條件應(yīng)該包括了對測試充分性要求的滿足?！?00%代碼行覆蓋，85%分支覆蓋〕識別能夠呵斥單元測試過程異常終止的條件〔如發(fā)現(xiàn)艱苦的設(shè)計(jì)錯(cuò)誤、到達(dá)進(jìn)度期限等〕。.確定單元測試方案確定單元測試資源估算進(jìn)展測試活動所需的資源。應(yīng)思索測試人員、硬件、通訊或系統(tǒng)軟件、測試工具和其它資源。識別需求進(jìn)展預(yù)備或懇求的資源〔如定制的測試工具〕，并做出相應(yīng)的安排。指明總體進(jìn)度方案基于資源和工程方案等方面的要求，確定單元測試活動的總體進(jìn)度方案。.確定待測特性研討待測特性要從研討單元的需求開場功能需求、非功能需求〔如性能或設(shè)計(jì)約束等〕、與待測單元相關(guān)的任何運(yùn)用或操作過程單元的形狀識別針對形狀機(jī)測試單元的數(shù)據(jù)特性識別單元的輸入輸出數(shù)據(jù)分析以上研討分析對于制定單元測試方案和指點(diǎn)測試用例的設(shè)計(jì)很重要待測特性分析過程中還有能夠發(fā)現(xiàn)單元需求上的缺陷。.制定單元測試規(guī)程輸入單元測試方案、待測特性分析結(jié)果、工程總體進(jìn)度方案識別可重用技術(shù)〔待查〕經(jīng)過待測特性分析，可從用例庫中識別出可以重用的測試用例和測試規(guī)程，以減少反復(fù)任務(wù)。資源詳細(xì)列舉單元測試所需資源，包括人員、設(shè)備、工具、環(huán)境等，進(jìn)度方案詳細(xì)的進(jìn)度方案，包括風(fēng)險(xiǎn)分析和應(yīng)對措施規(guī)程評審.設(shè)計(jì)測試套件測試套件測試用例、腳本、驅(qū)動、樁、測試數(shù)據(jù)測試規(guī)程和測試用例的開發(fā)目前測試規(guī)程和測試用例是合一的。開發(fā)過程中在重用的根底上新增和修正。結(jié)合待測單元特性分析，充分思索測試用例的覆蓋率。?測試工具的設(shè)計(jì)自研測試工具的設(shè)計(jì)要充分思索可重用性，不同工程間通用性普通較小，一致工程不同版本間一定要具備通用性。測試規(guī)程/用例的評審.單元測試數(shù)據(jù)單元測試設(shè)計(jì)中，測試數(shù)據(jù)的設(shè)計(jì)是很關(guān)鍵的，同樣的測試規(guī)程，不同的測試數(shù)據(jù)，能夠會到達(dá)不同的測試結(jié)果。a)正常數(shù)據(jù)：在測試中所用的正常數(shù)據(jù)的量是最大的，而且也是最關(guān)鍵的。少量的測試數(shù)據(jù)不能完全覆蓋需求，但我們要從中提取出一些具有高度代表性的數(shù)據(jù)作為測試數(shù)據(jù)，以減少測試時(shí)間。b)邊緣數(shù)據(jù)：邊緣測試是界于正常數(shù)據(jù)和錯(cuò)誤數(shù)據(jù)之間的一種數(shù)據(jù)。它可以針對某一種編程言語、編程環(huán)境或特定的數(shù)據(jù)庫而專門設(shè)定。邊緣數(shù)據(jù)要靠測試人員的豐富閱歷來制定。c)錯(cuò)誤數(shù)據(jù)：顯而易見，錯(cuò)誤數(shù)據(jù)就是編寫與程序輸入規(guī)范不符的數(shù)據(jù)從而檢測輸入挑選、錯(cuò)誤處置等程序的分支。.構(gòu)建測試套件測試數(shù)據(jù)的預(yù)備測試工具的開發(fā)/調(diào)試構(gòu)建測試環(huán)境.執(zhí)行測試套件運(yùn)轉(zhuǎn)測試確定測試結(jié)果，處置測試過程中的異常對每個(gè)測試用例，確定單元能否經(jīng)過測試。對異常進(jìn)展分析，并根據(jù)情況處置：情況1：測試用例或測試數(shù)據(jù)的問題。修正并重新運(yùn)轉(zhuǎn)。情況2：測試規(guī)程執(zhí)行的問題。重新運(yùn)轉(zhuǎn)。情況3：測試環(huán)境的問題。糾正測試環(huán)境并重新運(yùn)轉(zhuǎn)；或者異常終止測試，并匯報(bào)記錄異常終止緣由。情況4：單元實(shí)現(xiàn)中的缺點(diǎn)。糾正單元的缺點(diǎn)，并運(yùn)轉(zhuǎn)一切的測試；或者異常終止測試，并匯報(bào)記錄異常終止緣由。情況5：單元設(shè)計(jì)中的缺點(diǎn)。糾正單元設(shè)計(jì)和實(shí)現(xiàn)中的缺點(diǎn)，必要時(shí)修正測試設(shè)計(jì)和測試數(shù)據(jù)，并重新運(yùn)轉(zhuǎn)一切的測試。.檢查終止條件測試充分性檢查檢查能否到達(dá)覆蓋率要求，包括測試用例執(zhí)行/經(jīng)過覆蓋率和被測單元代碼/分支覆蓋率。以及其它測試充分性要求。異常終止條件檢查補(bǔ)充測試套件以上條件不滿足時(shí)，那么需求補(bǔ)充測試套件，繼續(xù)進(jìn)展測試。.評價(jià)測試結(jié)果按照單元測試報(bào)告模塊出具單元測試報(bào)告如有必要對單元測試報(bào)告進(jìn)展評審將一切測試相關(guān)任務(wù)產(chǎn)品納入配置管理.主題內(nèi)容1.為什么做單元測試2.單元測試的概念和內(nèi)容3.單元測試的方法、技術(shù)與工具4.如何做單元測試5.單元測試的難點(diǎn)和對策.參見的單元測試的難點(diǎn)沒有時(shí)間做單元測試單元測試責(zé)任人不清楚測試代碼難以管理覆蓋率難以手工統(tǒng)計(jì)缺點(diǎn)報(bào)告方式驅(qū)動和樁編寫困難〔可測試性〕.對策：沒有時(shí)間做單元測試單元測試方案在工程方案應(yīng)該有表達(dá)。編寫代碼之前或同時(shí)，先設(shè)計(jì)測試用例。每個(gè)軟件單元應(yīng)該有什么功能？能否每個(gè)功能都有測試用例來驗(yàn)證它？.對策：單元測試責(zé)任人不清楚強(qiáng)調(diào)單元測試必需由類包的設(shè)計(jì)者擔(dān)任編寫，由于只需這樣，測試才干保證對象的運(yùn)轉(zhuǎn)時(shí)態(tài)行為符合需求。讓測試人員或第三方人員編寫測試用例，將破費(fèi)更多的任務(wù)量。〔20>>1〕執(zhí)行測試用例可以讓測試人員或自動構(gòu)造系統(tǒng)。.對策：測試代碼難以管理采用測試工具管理測試代碼如XUnit、C++Test、RTRT配置管理中建立配置項(xiàng)如，不同模塊的一組代碼，建立相應(yīng)測試代碼目錄和配置項(xiàng).對策：覆蓋率難以手工統(tǒng)計(jì)利用各種工具PureCoverage(C/C++/Java/.Net,Windows/UNIX)RTRT(C/C++/Java/Ada,嵌入式系統(tǒng))C++Test(C/C++,Windows/UNIX)Discover(Delphi,Windows).對策：缺點(diǎn)報(bào)告方式各種工具普通都會生成測試報(bào)告XUnit測試用例執(zhí)行報(bào)告RTRT、C++Test各種綜合報(bào)告〔測試用例執(zhí)行結(jié)果、測試用例覆蓋率、內(nèi)存檢查和性能〕.對策：驅(qū)動和樁編寫困難〔可測試性差〕通常情形下，測試驅(qū)動難以編寫，測試難以進(jìn)展由以下幾方面緣由導(dǎo)致：1、被測試對象需求傳入的參數(shù)過多。2、內(nèi)部的邏輯判別過多〔內(nèi)部牽扯復(fù)雜〕。3、和界面顯示部分交互過于頻繁〔耦合性太強(qiáng)〕。4、被測對象過多的調(diào)用了其他類或方法。5、需求構(gòu)造的作為參數(shù)的對象本身過于復(fù)雜.處理：提高可測試性1、首先最重要的是堅(jiān)持測試驅(qū)動設(shè)計(jì)〔測試先于設(shè)計(jì)〕的方法。優(yōu)先編寫測試代碼。這是規(guī)范的XP方法。這不是說您應(yīng)該一次性編寫全部測試代碼后，再一次性全部實(shí)現(xiàn)。對一些單元接口，編寫一些測試代碼，實(shí)現(xiàn)它們，再編寫一些測試代碼，再實(shí)現(xiàn)它們等等是個(gè)更好的方法。設(shè)計(jì)以這種方式得以進(jìn)展；在實(shí)現(xiàn)階段捕捉錯(cuò)誤并在下一組測試中矯正它。2、功能分解類：把功能分解到細(xì)粒度，提倡小類。方法：盡量做到每個(gè)操作對應(yīng)一個(gè)方法，使方法小型化。功能分解促進(jìn)：提高重用性，降低耦合度3、分層原那么。對于顯示部分〔GUI〕，盡量做到顯示與控制分別。把代碼移到GUI視圖的外面。然后各種GUI動作就能成了模型上的簡一方法調(diào)用。這樣，對GUI測試者來說，經(jīng)過方法調(diào)用測試功能比間接地測試功能容易的多。另一個(gè)益處是它使修正程序功能而不影響視圖變的更容易。.處理：提高可測試性4、籠統(tǒng)我們可以想出各種各樣的方法來降低耦合程度，但是歸納起來，不外乎添加籠統(tǒng)的層次來隔離不同的類，這個(gè)抽象層次可以是詳細(xì)的類，也可以是接口。GOF的23種設(shè)計(jì)方式，沒有一種方式的思緒不是從添加抽象層次入手來處理問題的5、對于能夠要作為參數(shù)的復(fù)雜類，可以做一個(gè)接口，用接口闡明外部程序組件使得我們可以容易地在測試案例中模擬這些組件。當(dāng)需求時(shí)可以實(shí)現(xiàn)按接口生成一個(gè)模擬類作為參數(shù)傳入。特別是當(dāng)該類還沒有完全實(shí)現(xiàn)時(shí)，這種方法最為行之有效。.處理：提高可測試性6、假設(shè)本人不擔(dān)任測試任務(wù)，作為開發(fā)員在設(shè)計(jì)過程中要時(shí)辰提示本人“我如何才干測試這些代碼？我如何才干以可測試方式編寫這些代碼〞。7、重構(gòu)是提高可測試性的主要手段.單元測試閱歷測試驅(qū)動開發(fā)，開發(fā)以測試為導(dǎo)向?qū)懖怀鰷y試用例，就談不上編寫單元代碼開發(fā)一個(gè)單元的代碼的步驟：1.設(shè)計(jì)和編寫測試它的用例代碼2.運(yùn)轉(zhuǎn)自動測試，檢查能否發(fā)生錯(cuò)誤3.編寫單元的代碼4.運(yùn)用前面的用例回歸測試它單元測試是編碼的一部分！.單元測試閱歷測試驅(qū)動開發(fā)編寫單元測試用例促進(jìn)解除模塊之間的耦合。先編寫測試用例，強(qiáng)迫本人從利