第3章軟件測試過程

第五章單元測試Zhu.Kerry@5.1什么是單元測試5.2單元測試的目標(biāo)和任務(wù)5.3靜態(tài)測試5.4驅(qū)動程序和樁程序5.5調(diào)試與評估5.6單元測試的管理5.7單元測試工具5.1什么是單元測試測試的4個階段：單元測試集成測試系統(tǒng)測試驗收測試按階段進行測試是一種基本的測試策略Zhu.Kerry@單元測試的定義定義:單元測試是對軟件基本組成單元進行的測試。時機:一般在代碼完成后由開發(fā)人員完成,QA人員輔助.概念:模塊,組件,單元

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

Zhu.Kerry@12小時6小時3小時單元測試集成測試系統(tǒng)測試單元測試的背景開發(fā)流程時間表與修改Bug代價的關(guān)系圖開發(fā)結(jié)束開發(fā)早期修改代價Zhu.Kerry@單元測試的背景（續(xù)）編程過程中，每寫100行代碼會犯150個錯誤編程與編譯運行結(jié)束后，每100行代碼中大約殘留有1-3個Bug尋找與修改程序錯誤的代價占總體開發(fā)投資的40%-80%Bug在整個研發(fā)流程中被發(fā)現(xiàn)的越早，修改的代價就越低Zhu.Kerry@5.2單元測試的目標(biāo)和任務(wù)目標(biāo):

單元模塊被正確編碼信息能否正確地流入和流出單元；在單元工作過程中，其內(nèi)部數(shù)據(jù)能否保持其完整性，包括內(nèi)部數(shù)據(jù)的形式、內(nèi)容及相互關(guān)系不發(fā)生錯誤，也包括全局變量在單元中的處理和影響。在為限制數(shù)據(jù)加工而設(shè)置的邊界處，能否正確工作。單元的運行能否做到滿足特定的邏輯覆蓋。單元中發(fā)生了錯誤，其中的出錯處理措施是否有效。Zhu.Kerry@任務(wù)１：模塊獨立執(zhí)行通路測試檢查每一條獨立執(zhí)行路徑的測試。保證每條語句被至少執(zhí)行一次。Checklist:誤解或用錯了算符優(yōu)先級?；旌项愋瓦\算。變量初值錯。精度不夠。表達式符號錯。其它Zhu.Kerry@任務(wù)2：模塊局部數(shù)據(jù)結(jié)構(gòu)測試檢查局部數(shù)據(jù)結(jié)構(gòu)完整性Checklist:不適合或不相容的類型說明。變量無初值。變量初始化或默認(rèn)值有錯。不正確的變量名或從來未被使用過。出現(xiàn)上溢或下溢和地址異常。其它Zhu.Kerry@任務(wù)３：模塊接口測試檢查模塊接口是否正確，checklist:輸入的實際參數(shù)與形式參數(shù)是否一致。個數(shù)、屬性、量綱調(diào)用其他模塊的實際參數(shù)與被調(diào)模塊的形參是否一致。個數(shù)、屬性、量綱全程變量的定義在各模塊是否一致。外部輸入、輸出文件、緩沖區(qū)、錯誤處理其它Zhu.Kerry@任務(wù)４：模塊邊界條件測試檢查臨界數(shù)據(jù)處理的正確性Checklist:普通合法數(shù)據(jù)的處理。普通非法數(shù)據(jù)的處理。邊界值內(nèi)合法邊界數(shù)據(jù)的處理。邊界值外非法邊界數(shù)據(jù)的處理。其它Zhu.Kerry@任務(wù)5：模塊的各條錯誤處理通路測試預(yù)見、預(yù)設(shè)的各種出錯處理是否正確有效。Checklist:輸出的出錯信息難以理解。記錄的錯誤與實際不相符。程序定義的出錯處理前系統(tǒng)已介入。異常處理不當(dāng)。未提供足夠的定位出錯的信息。其它Zhu.Kerry@Microsoft對單元測試的理解Zhu.Kerry@單元測試具體分類驗證產(chǎn)品實現(xiàn)符合功能規(guī)格書驗證產(chǎn)品代碼運行的正確性邊緣條件測試產(chǎn)品安全性測試從已有Bug增加的回歸測試產(chǎn)品代碼覆蓋度測試(CodeCoverage)產(chǎn)品代碼注射測試(CodeInjection)異常測試Zhu.Kerry@單元測試具體分類產(chǎn)品速度性能的比較測試產(chǎn)品極限情況測試產(chǎn)品與國際標(biāo)準(zhǔn)的兼容性測試產(chǎn)品與以前版本的操作系統(tǒng)，文件格式的兼容測試同一產(chǎn)品不同版本共同運行的兼容性測試產(chǎn)品在不同語言操作系統(tǒng)下的運行測試Zhu.Kerry@單元測試具體流程測試過程從產(chǎn)品設(shè)計開始SpecReview非常重要微軟產(chǎn)品SpecReview演示SharepointServer的應(yīng)用測試代碼編寫由軟件開發(fā)設(shè)計者(SDE)自己開始DRT(DeveloperRegressionTest)的重要性沒有相隨的DRT，F(xiàn)eatureArea不算開發(fā)完DRT不全部編譯并100%通過，不允許Check-in測試組的測試不100%編譯并100%通過0級測試(BVT),70%通過1級測試，不允許Check-inZhu.Kerry@單元測試具體流程(續(xù))測試代碼主體由軟件測試工程師(SDET,STE)編寫測試從寫軟件測試規(guī)格書(TestSpec)開始TestSpec必須通過PM，Dev與同組Tester共同開會研究通過測試代碼根據(jù)不同測試的情景分為0-4級的優(yōu)先級0級測試稱為BVT(BuildVerificationTest)在Dev主要的功能實現(xiàn)Check-in前,0-1級測試代碼必須已由測試工程師完成在Dev進行Check-in時，0級測試必須100%通過Zhu.Kerry@單元測試具體流程(續(xù))在Dev進行Check-in時，1級測試必須至少有70%通過Dev進行產(chǎn)品代碼的Check-inTest進行測試代碼的Check-in產(chǎn)品編譯由Build團隊每日進行Test編譯由測試團隊在產(chǎn)品編譯完成后進行測試編譯完成后，由測試自動化系統(tǒng)進行測試在隨后的代碼優(yōu)化與穩(wěn)定期內(nèi)，測試工程師編寫2-4級測試代碼，并報告產(chǎn)品Bug，Dev負(fù)責(zé)修改Bug，穩(wěn)定并優(yōu)化產(chǎn)品Zhu.Kerry@5.3靜態(tài)測試技術(shù)的運用靜態(tài)測試技術(shù)：不運行被測試程序，對代碼通過檢查、閱讀進行分析。三步曲：走查（WalkThrough）。審查（Inspection）。評審（Review）Zhu.Kerry@編碼的標(biāo)準(zhǔn)和規(guī)范標(biāo)準(zhǔn)：建立起來必須遵守的規(guī)則。規(guī)范：建議最佳做法，推薦更好方式。實施標(biāo)準(zhǔn)和規(guī)范的原因：可靠性?？勺x性和可維護性?？梢浦残浴hu.Kerry@走查（WalkThrough）定義：采用講解、討論和模擬運行的方式進行的查找錯誤的活動。注意：引導(dǎo)小組成員在走查前通讀設(shè)計和編碼。限時，避免跑題。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。檢查要點是代碼是否符合標(biāo)準(zhǔn)和規(guī)范，是否有邏輯錯誤。Zhu.Kerry@審查（Inspection）定義：采用講解、提問方式進行，一般有正式的計劃、流程和結(jié)果。主要方法采用缺陷檢查表。注意：以會議形式，制定會議目標(biāo)、流程和規(guī)則，結(jié)束后要編寫報告。按缺陷檢查表逐項檢查。發(fā)現(xiàn)問題適當(dāng)記錄，避免現(xiàn)場修改。發(fā)現(xiàn)重大缺陷，改正后會議需要重開。檢查要點是缺陷檢查表，所以該表要根據(jù)項目不同不斷積累完善。Zhu.Kerry@走查與審查的比較Zhu.Kerry@走查審查準(zhǔn)備通讀設(shè)計和編碼應(yīng)準(zhǔn)備好需求描述文檔、程序設(shè)計文檔、程序的源代碼清單、代碼編碼標(biāo)準(zhǔn)和代碼缺陷檢查表形式非正式會議正式會議參加人員開發(fā)人員為主項目組成員包括測試人員主要技術(shù)方法無缺陷檢查表注意事項限時、不要現(xiàn)場修改代碼限時、不要現(xiàn)場修改代碼生成文檔會議記錄靜態(tài)分析錯誤報告目標(biāo)代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯誤代碼標(biāo)準(zhǔn)規(guī)范，無邏輯錯誤評審（Review）定義：通常在審查會后進行，審查小組根據(jù)記錄和報告進行評估。注意：充分審查了所規(guī)定的代碼，并且全部編碼準(zhǔn)則被遵守。審查中發(fā)現(xiàn)的錯誤已全部修改。Zhu.Kerry@5.4驅(qū)動程序和樁程序動態(tài)測試需要真正將程序運行起來，需要設(shè)計系列的測試用例保證測試的完整性和有效性。白盒測試黑盒（灰盒）測試Zhu.Kerry@驅(qū)動程序和樁程序運行單元程序有時需要基于被測單元的接口，開發(fā)相應(yīng)的驅(qū)動模塊和樁模塊。驅(qū)動模塊（drive）:對底層或子層模塊進行測試所編寫的調(diào)用這些模塊的程序。樁模塊（stub）：對頂層或上層模塊進行測試時所編寫的替代下層模塊的程序。Zhu.Kerry@5.5調(diào)試與評估調(diào)試與測試的對象及采用的方法有很大程度上的相似，調(diào)試還用到斷點控制等排錯方法，但其目的卻完全不同。測試是為了找出軟件中存在的缺陷，而調(diào)試是為了解決存在的缺陷。軟件單元功能與設(shè)計需求一致。

軟件單元接口與設(shè)計需求一致。能夠正確處理輸入和運行中的錯誤。在單元測試中發(fā)現(xiàn)的錯誤已經(jīng)得到修改并且通過了測試。達到了相關(guān)的覆蓋率的要求。完成軟件單元測試報告Zhu.Kerry@單元測試檢查表(1)借助單元測試檢查表進行評估。案例：單元測試檢查表單元名稱___________系統(tǒng)_______________構(gòu)造______________任務(wù)編號____________________初次測試日期_________________關(guān)鍵測試項是否已糾正有無任何輸入?yún)?shù)沒有使用？有無任何輸出參數(shù)沒有產(chǎn)生？有無任何數(shù)據(jù)類型不正確或不一致？有無任何算法與PDL或功能需求中的描述不一致？有無任何局部變量使用前沒有初始化？有無任何外部接口編碼錯誤？即調(diào)用語句、文件存取、數(shù)據(jù)庫錯誤。有無任何邏輯路徑錯誤？該單元是否有多個入口或多個正常的出口？Zhu.Kerry@單元測試檢查表(2)額外測試項8.該單元中有任何地方與PDL與PROLOG中的描述不一致？9.代碼中有無任何偏離本項目標(biāo)準(zhǔn)的地方？10.代碼中有無任何對于用戶來說不清楚的錯誤提示信息？11.如果該單元是設(shè)計為可重用的，代碼中是有可能妨礙重用的地方？采取的動作和說明（請用單獨的一頁或多頁。每一項動作必須指出所引用的問題。）審查結(jié)果1.如果上述11個問題的答案均為"否"，那么測試通過，請在此標(biāo)記并且在最后簽名。2.如果代碼存在嚴(yán)重的問題，例如多個關(guān)鍵問題的答案為"是"，那么程序編制者糾正這些錯誤，并且必須重新安排一次單元測試。下一次單元測試的日期：_________________________3.如果代碼存在小的缺陷，那么程序編制者糾正這些錯誤，并且仲裁者必須安排一次跟蹤會議。跟蹤會議的日期：_________________________測試人簽名：__________________日期：_________________

Zhu.Kerry@5.6單元測試的管理過程:在詳細設(shè)計階段完成單元測試計劃。建立單元測試環(huán)境，完成測試設(shè)計和開發(fā)。執(zhí)行單元測試用例，并且詳細記錄測試結(jié)果。判定測試用例是否通過。提交《單元測試報告》。Zhu.Kerry@單元測試的文檔《軟件需求規(guī)格說明書》、《軟件詳細設(shè)計說明書》

《單元測試計劃》

《單元測試計劃》、《軟件詳細設(shè)計說明書》 《單元測試用例》《單元測試用例》文檔及《軟件需求規(guī)格說明書》、《軟件詳細設(shè)計說明書》 《缺陷跟蹤報告》/《缺陷檢查表》《單元測試用例》、《缺陷跟蹤報告》、《缺陷檢查表》 《單元測試檢查表》評估 《單元測試報告》Zhu.Kerry@5.7單元測試常用工具簡介JUnit介紹在Eclipse中JUnit應(yīng)用舉例Junit+Ant構(gòu)建自動的單元測試CheckStyle/PMD與FindBug的使用SourceMonitor檢測代碼復(fù)雜度開源的單元測試工具商業(yè)的單元測試工具Zhu.Kerry@5.7單元測試常用工具簡介JUnit介紹Zhu.Kerry@JUnit是一個開放源代碼的Java測試框架，用在編寫和運行可重復(fù)的的測試上，它是單元測試框架體系xUnit的一個實例，包括如下特性。用于測試期望結(jié)果的斷言用于共享共同測試數(shù)據(jù)的測試工具用于方便地組織和運行測試的測試套件2.Junit的優(yōu)點可以使測試代碼與產(chǎn)品代碼分開，這更有利于代碼的打包發(fā)布和測試代碼的管理針對某一個類的測試代碼，通地較少的改動便可以應(yīng)用另一個類的測試，JUnit提供了一個編寫測試類的框架，使測試代碼的