軟件測(cè)試過程

第3章軟件測(cè)試過程

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

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

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

軟件單元接口與設(shè)計(jì)需求一致。能夠正確處理輸入和運(yùn)行中的錯(cuò)誤。在單元測(cè)試中發(fā)現(xiàn)的錯(cuò)誤已經(jīng)得到修改并且通過了測(cè)試。達(dá)到了相關(guān)的覆蓋率的要求。完成軟件單元測(cè)試報(bào)告Zhu.Kerry@單元測(cè)試檢查表(1)借助單元測(cè)試檢查表進(jìn)行評(píng)估。案例：?jiǎn)卧獪y(cè)試檢查表單元名稱___________系統(tǒng)_______________構(gòu)造______________任務(wù)編號(hào)____________________初次測(cè)試日期_________________關(guān)鍵測(cè)試項(xiàng)是否已糾正有無任何輸入?yún)?shù)沒有使用？有無任何輸出參數(shù)沒有產(chǎn)生？有無任何數(shù)據(jù)類型不正確或不一致？有無任何算法與PDL或功能需求中的描述不一致？有無任何局部變量使用前沒有初始化？有無任何外部接口編碼錯(cuò)誤？即調(diào)用語句、文件存取、數(shù)據(jù)庫(kù)錯(cuò)誤。有無任何邏輯路徑錯(cuò)誤？該單元是否有多個(gè)入口或多個(gè)正常的出口？Zhu.Kerry@單元測(cè)試檢查表(2)額外測(cè)試項(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è)問題的答案均為"否"，那么測(cè)試通過，請(qǐng)?jiān)诖藰?biāo)記并且在最后簽名。2.如果代碼存在嚴(yán)重的問題，例如多個(gè)關(guān)鍵問題的答案為"是"，那么程序編制者糾正這些錯(cuò)誤，并且必須重新安排一次單元測(cè)試。下一次單元測(cè)試的日期：_________________________3.如果代碼存在小的缺陷，那么程序編制者糾正這些錯(cuò)誤，并且仲裁者必須安排一次跟蹤會(huì)議。跟蹤會(huì)議的日期：_________________________測(cè)試人簽名：__________________日期：_________________

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

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

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