復(fù)件軟件測試方法技術(shù)ch5單元測試stmt

軟件測試方法和技術(shù)

第2版

第5章單元測試謝紅薇Mobil：QQ：740393608

第4章回顧4.1測試過程模型V模型、W模型、TMap4.2測試過程改進(jìn)模型TMM、TPI、CTP、STEP4.3軟件測試標(biāo)準(zhǔn)和規(guī)范4.4建立軟件測試管理和評(píng)判體系

第二篇軟件測試的技術(shù)在實(shí)際項(xiàng)目的測試過程中，我們會(huì)面對(duì)許多復(fù)雜的問題和具體的困難，不僅要采用前面所學(xué)的方法，還要擁有很好的技術(shù)，熟悉業(yè)務(wù)領(lǐng)域知識(shí)，深入系統(tǒng)架構(gòu)、設(shè)計(jì)模式和開發(fā)框架，靈活運(yùn)用測試工具，才能真正解決問題。第5章單元測試第6章集成測試和系統(tǒng)測試第7章驗(yàn)收測試第8章面向?qū)ο筌浖臏y試第9章基于應(yīng)用服務(wù)器的測試第10章軟件本地化測試第11章軟件測試自動(dòng)化

第五章單元測試5.1什么是單元測試5.2單元測試的目標(biāo)和任務(wù)5.3靜態(tài)測試5.4驅(qū)動(dòng)程序和樁程序5.5調(diào)試與評(píng)估5.6單元測試的管理5.7單元測試工具

5.1什么是單元測試測試的4個(gè)階段：單元測試

集成測試

系統(tǒng)測試

驗(yàn)收測試按階段進(jìn)行測試是一種基本的測試策略

單元測試的定義定義:單元測試是對(duì)軟件基本組成單元進(jìn)行的測試。時(shí)機(jī):一般在代碼完成后由開發(fā)人員完成,QA人員輔助.概念:模塊,組件,單元

為何要進(jìn)行單元測試?盡早發(fā)現(xiàn)錯(cuò)誤錯(cuò)誤發(fā)現(xiàn)越早,成本越低.開發(fā)人員過于自信,后期復(fù)雜度高,發(fā)現(xiàn)解決BUG困難.檢查代碼是否符合設(shè)計(jì)和規(guī)范

12小時(shí)6小時(shí)3小時(shí)單元測試集成測試系統(tǒng)測試

單元測試的背景開發(fā)流程時(shí)間表與修改Bug代價(jià)的關(guān)系圖開發(fā)結(jié)束開發(fā)早期修改代價(jià)

單元測試的背景（續(xù)）編程過程中，每寫100行代碼會(huì)犯150個(gè)錯(cuò)誤編程與編譯運(yùn)行結(jié)束后，每100行代碼中大約殘留有1-3個(gè)Bug尋找與修改程序錯(cuò)誤的代價(jià)占總體開發(fā)投資的40%-80%Bug在整個(gè)研發(fā)流程中被發(fā)現(xiàn)的越早，修改的代價(jià)就越低

5.2單元測試的目標(biāo)和任務(wù)目標(biāo):

單元模塊被正確編碼信息能否正確地流入和流出單元；在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯(cuò)誤，也包括全局變量在單元中的處理和影響。在為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作。單元的運(yùn)行能否做到滿足特定的邏輯覆蓋。單元中發(fā)生了錯(cuò)誤，其中的出錯(cuò)處理措施是否有效。

任務(wù)１：模塊獨(dú)立執(zhí)行通路測試檢查每一條獨(dú)立執(zhí)行路徑的測試。保證每條語句被至少執(zhí)行一次。Checklist:誤解或用錯(cuò)了算符優(yōu)先級(jí)?；旌项愋瓦\(yùn)算。變量初值錯(cuò)。精度不夠。表達(dá)式符號(hào)錯(cuò)。其它

任務(wù)2：模塊局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:不適合或不相容的類型說明。變量無初值。變量初始化或默認(rèn)值有錯(cuò)。不正確的變量名或從來未被使用過。出現(xiàn)上溢或下溢和地址異常。其它

任務(wù)３：模塊接口測試檢查模塊接口是否正確，checklist:輸入的實(shí)際參數(shù)與形式參數(shù)是否一致。個(gè)數(shù)、屬性、量綱調(diào)用其他模塊的實(shí)際參數(shù)與被調(diào)模塊的形參是否一致。個(gè)數(shù)、屬性、量綱全程變量的定義在各模塊是否一致。外部輸入、輸出文件、緩沖區(qū)、錯(cuò)誤處理其它

任務(wù)４：模塊邊界條件測試檢查臨界數(shù)據(jù)處理的正確性Checklist:普通合法數(shù)據(jù)的處理。普通非法數(shù)據(jù)的處理。邊界值內(nèi)合法邊界數(shù)據(jù)的處理。邊界值外非法邊界數(shù)據(jù)的處理。其它

任務(wù)5：模塊的各條錯(cuò)誤處理通路測試預(yù)見、預(yù)設(shè)的各種出錯(cuò)處理是否正確有效。Checklist:輸出的出錯(cuò)信息難以理解。記錄的錯(cuò)誤與實(shí)際不相符。程序定義的出錯(cuò)處理前系統(tǒng)已介入。異常處理不當(dāng)。未提供足夠的定位出錯(cuò)的信息。其它

Microsoft對(duì)單元測試的理解

單元測試具體分類驗(yàn)證產(chǎn)品實(shí)現(xiàn)符合功能規(guī)格書驗(yàn)證產(chǎn)品代碼運(yùn)行的正確性邊緣條件測試產(chǎn)品安全性測試從已有Bug增加的回歸測試產(chǎn)品代碼覆蓋度測試(CodeCoverage)產(chǎn)品代碼注射測試(CodeInjection)異常測試

單元測試具體分類產(chǎn)品速度性能的比較測試產(chǎn)品極限情況測試產(chǎn)品與國際標(biāo)準(zhǔn)的兼容性測試產(chǎn)品與以前版本的操作系統(tǒng)，文件格式的兼容測試同一產(chǎn)品不同版本共同運(yùn)行的兼容性測試產(chǎn)品在不同語言操作系統(tǒng)下的運(yùn)行測試

單元測試具體流程測試過程從產(chǎn)品設(shè)計(jì)開始SpecReview非常重要微軟產(chǎn)品SpecReview演示SharepointServer的應(yīng)用測試代碼編寫由軟件開發(fā)設(shè)計(jì)者(SDE)自己開始DRT(DeveloperRegressionTest)的重要性沒有相隨的DRT，F(xiàn)eatureArea不算開發(fā)完DRT不全部編譯并100%通過，不允許Check-in測試組的測試不100%編譯并100%通過0級(jí)測試(BVT),70%通過1級(jí)測試，不允許Check-in

單元測試具體流程(續(xù))測試代碼主體由軟件測試工程師(SDET,STE)編寫測試從寫軟件測試規(guī)格書(TestSpec)開始TestSpec必須通過PM，Dev與同組Tester共同開會(huì)研究通過測試代碼根據(jù)不同測試的情景分為0-4級(jí)的優(yōu)先級(jí)0級(jí)測試稱為BVT(BuildVerificationTest)在Dev主要的功能實(shí)現(xiàn)Check-in前,0-1級(jí)測試代碼必須已由測試工程師完成在Dev進(jìn)行Check-in時(shí)，0級(jí)測試必須100%通過

單元測試具體流程(續(xù))在Dev進(jìn)行Check-in時(shí)，1級(jí)測試必須至少有70%通過Dev進(jìn)行產(chǎn)品代碼的Check-inTest進(jìn)行測試代碼的Check-in產(chǎn)品編譯由Build團(tuán)隊(duì)每日進(jìn)行Test編譯由測試團(tuán)隊(duì)在產(chǎn)品編譯完成后進(jìn)行測試編譯完成后，由測試自動(dòng)化系統(tǒng)進(jìn)行測試在隨后的代碼優(yōu)化與穩(wěn)定期內(nèi)，測試工程師編寫2-4級(jí)測試代碼，并報(bào)告產(chǎn)品Bug，Dev負(fù)責(zé)修改Bug，穩(wěn)定并優(yōu)化產(chǎn)品

5.3靜態(tài)測試技術(shù)的運(yùn)用靜態(tài)測試技術(shù)：不運(yùn)行被測試程序，對(duì)代碼通過檢查、閱讀進(jìn)行分析。三步曲：走查（WalkThrough）。審查（Inspection）。評(píng)審（Review）

編碼的標(biāo)準(zhǔn)和規(guī)范標(biāo)準(zhǔn)：建立起來必須遵守的規(guī)則。規(guī)范：建議最佳做法，推薦更好方式。實(shí)施標(biāo)準(zhǔn)和規(guī)范的原因：可靠性?？勺x性和可維護(hù)性?？梢浦残?。

走查（WalkThrough）定義：采用講解、討論和模擬運(yùn)行的方式進(jìn)行的查找錯(cuò)誤的活動(dòng)。注意：引導(dǎo)小組成員在走查前通讀設(shè)計(jì)和編碼。限時(shí)，避免跑題。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。檢查要點(diǎn)是代碼是否符合標(biāo)準(zhǔn)和規(guī)范，是否有邏輯錯(cuò)誤。

審查（Inspection）定義：采用講解、提問方式進(jìn)行，一般有正式的計(jì)劃、流程和結(jié)果。主要方法采用缺陷檢查表。注意：以會(huì)議形式，制定會(huì)議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報(bào)告。按缺陷檢查表逐項(xiàng)檢查。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。發(fā)現(xiàn)重大缺陷，改正后會(huì)議需要重開。檢查要點(diǎn)是缺陷檢查表，所以該表要根據(jù)項(xiàng)目不同不斷積累完善。

走查與審查的比較走查審查準(zhǔn)備通讀設(shè)計(jì)和編碼應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計(jì)文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表形式非正式會(huì)議正式會(huì)議參加人員開發(fā)人員為主項(xiàng)目組成員包括測試人員主要技術(shù)方法無缺陷檢查表注意事項(xiàng)限時(shí)、不要現(xiàn)場修改代碼限時(shí)、不要現(xiàn)場修改代碼生成文檔會(huì)議記錄靜態(tài)分析錯(cuò)誤報(bào)告目標(biāo)代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯(cuò)誤代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯(cuò)誤

評(píng)審（Review）定義：通常在審查會(huì)后進(jìn)行，審查小組根據(jù)記錄和報(bào)告進(jìn)行評(píng)估。注意：充分審查了所規(guī)定的代碼，并且全部編碼準(zhǔn)則被遵守。審查中發(fā)現(xiàn)的錯(cuò)誤已全部修改。

5.4驅(qū)動(dòng)程序和樁程序動(dòng)態(tài)測試需要真正將程序運(yùn)行起來，需要設(shè)計(jì)系列的測試用例保證測試的完整性和有效性。白盒測試黑盒（灰盒）測試

驅(qū)動(dòng)程序和樁程序運(yùn)行單元程序有時(shí)需要基于被測單元的接口，開發(fā)相應(yīng)的驅(qū)動(dòng)模塊和樁模塊。驅(qū)動(dòng)模塊（drive）:對(duì)底層或子層模塊進(jìn)行測試所編寫的調(diào)用這些模塊的程序。樁模塊（stub）：對(duì)頂層或上層模塊進(jìn)行測試時(shí)所編寫的替代下層模塊的程序。

5.5調(diào)試與評(píng)估調(diào)試與測試的對(duì)象及采用的方法有很大程度上的相似，調(diào)試還用到斷點(diǎn)控制等排錯(cuò)方法，但其目的卻完全不同。測試是為了找出軟件中存在的缺陷，而調(diào)試是為了解決存在的缺陷。軟件單元功能與設(shè)計(jì)需求一致。

軟件單元接口與設(shè)計(jì)需求一致。能夠正確處理輸入和運(yùn)行中的錯(cuò)誤。在單元測試中發(fā)現(xiàn)的錯(cuò)誤已經(jīng)得到修改并且通過了測試。達(dá)到了相關(guān)的覆蓋率的要求。完成軟件單元測試報(bào)告

單元測試檢查表(1)借助單元測試檢查表進(jìn)行評(píng)估。案例：單元測試檢查表單元名稱___________系統(tǒng)_______________構(gòu)造______________任務(wù)編號(hào)____________________初次測試日期_________________關(guān)鍵測試項(xiàng)是否已糾正有無任何輸入?yún)?shù)沒有使用？有無任何輸出參數(shù)沒有產(chǎn)生？有無任何數(shù)據(jù)類型不正確或不一致？有無任何算法與PDL或功能需求中的描述不一致？有無任何局部變量使用前沒有初始化？有無任何外部接口編碼錯(cuò)誤？即調(diào)用語句、文件存取、數(shù)據(jù)庫錯(cuò)誤。有無任何邏輯路徑錯(cuò)誤？該單元是否有多個(gè)入口或多個(gè)正常的出口？

單元測試檢查表(2)額外測試項(xiàng)8.該單元中有任何地方與PDL與PROLOG中的描述不一致？9.代碼中有無任何偏離本項(xiàng)目標(biāo)準(zhǔn)的地方？10.代碼中有無任何對(duì)于用戶來說不清楚的錯(cuò)誤提示信息？11.如果該單元是設(shè)計(jì)為可重用的，代碼中是有可能妨礙重用的地方？采取的動(dòng)作和說明（請(qǐng)用單獨(dú)的一頁或多頁。每一項(xiàng)動(dòng)作必須指出所引用的問題。）審查結(jié)果1.如果上述11個(gè)問題的答案均為"否"，那么測試通過，請(qǐng)?jiān)诖藰?biāo)記并且在最后簽名。2.如果代碼存在嚴(yán)重的問題，例如多個(gè)關(guān)鍵問題的答案為"是"，那么程序編制者糾正這些錯(cuò)誤，并且必須重新安排一次單元測試。下一次單元測試的日期：_________________________3.如果代碼存在小的缺陷，那么程序編制者糾正這些錯(cuò)誤，并且仲裁者必須安排一次跟蹤會(huì)議。跟蹤會(huì)議的日期：_________________________測試人簽名：__________________日期：_________________

5.6單元測試的管理過程:在詳細(xì)設(shè)計(jì)階段完成單元測試計(jì)劃。建立單元測試環(huán)境，完成測試設(shè)計(jì)和開發(fā)。執(zhí)行單元測試用例，并且詳細(xì)記錄測試結(jié)果。判定測試用例是否通過。提交《單元測試報(bào)告》。

單元測試的文檔《軟件需求規(guī)格說明書》、《軟件詳細(xì)設(shè)計(jì)說明書》

《單元測試計(jì)劃》

《單元測試計(jì)劃》、《軟件詳細(xì)設(shè)計(jì)說明書》

《單元測試用例》

《單元測試用例》文檔及《軟件需求規(guī)格說明書》、《軟件詳細(xì)設(shè)計(jì)說明書》 《缺陷跟蹤報(bào)告》/《缺陷檢查表》《單元測試用例》、《缺陷跟蹤報(bào)告》、《缺陷檢查表》

《單元測試檢查表》

評(píng)估

《單元測試報(bào)告》

5.7單元測試常用工具簡介JUnit介紹在Eclipse中JUnit應(yīng)用舉例Junit+Ant構(gòu)建自動(dòng)的單元測試CheckStyle/PMD與FindBug的使用SourceMonitor檢測代碼復(fù)雜度開源的單元測試工具商業(yè)的單元測試工具

5.7單元測試常用工具簡介JUnit介紹JUnit是一個(gè)開放源代碼的Java測試框架，用在編寫和運(yùn)行可重復(fù)的的測試上，它是單元測試框架體系xUnit的一個(gè)實(shí)例，包括如下特性。用于測試期望結(jié)果的斷言用于共享共同測試數(shù)據(jù)的測試工具用于方便地組織和運(yùn)行測試的測試套件2.Junit的優(yōu)點(diǎn)可以使測試代碼與產(chǎn)品代碼分開，這更有利于代碼的打包發(fā)布和測試代碼的管理針對(duì)某一個(gè)類的測試代碼，通地較少的改動(dòng)便可以應(yīng)用另一