培訓教材2-軟件單元測試

軟件測試實際—單元測試

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

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