軟件測試 第6章單元測試

軟件測試第6章單元測試單元測試概述什么是單元傳統(tǒng)軟件對“單元”一詞有著不同的定義單元是可以編譯和執(zhí)行的最小軟件組件單元是決不會指派給多個設(shè)計(jì)人員開發(fā)的軟件組件“單元”與被測軟件系統(tǒng)所采用的分析設(shè)計(jì)方法以及在其開發(fā)過程中采用的實(shí)現(xiàn)技術(shù)有關(guān)函數(shù)、子程序、緊密相關(guān)的一組函數(shù)、類、復(fù)雜類中的單個方法、緊密相關(guān)的一組類……基本單元必須具備一定的基本屬性，有明確的規(guī)格定義，以及包含與其他部分接口的明確定義等從軟件工程的角度來說，具有功能的獨(dú)立性、符合高內(nèi)聚和低耦合的特性能夠清晰地與同一程序中的其他單元劃分開來什么是單元測試？通常而言，單元測試是在軟件開發(fā)過程中要進(jìn)行的最低級別的測試活動或者說是針對軟件設(shè)計(jì)的最小單位即程序模塊、函數(shù)、類或方法所進(jìn)行的正確性檢驗(yàn)的測試工作其目的在于發(fā)現(xiàn)每個單元內(nèi)部可能存在的錯誤或缺陷單元測試的主要工作分兩個步驟：人工靜態(tài)檢查（靜態(tài)測試）保證代碼算法的邏輯正確性（盡量通過人工檢查發(fā)現(xiàn)代碼的邏輯錯誤）、清晰性、規(guī)范性、一致性、算法高效性盡可能地發(fā)現(xiàn)程序中可能存在的錯誤或缺陷動態(tài)執(zhí)行跟蹤（動態(tài)測試）通過設(shè)計(jì)測試用例，執(zhí)行待測程序來跟蹤比較實(shí)際結(jié)果與預(yù)期結(jié)果來發(fā)現(xiàn)錯誤或缺陷什么時候進(jìn)行單元測試單元測試越早越好在測試驅(qū)動開發(fā)（TDD,TestDrivenDevelopment）中，先編寫測試代碼，再進(jìn)行開發(fā)在實(shí)際過程中，先寫函數(shù)的框架，再針對函數(shù)的功能編寫測試用例，然后編寫函數(shù)的實(shí)現(xiàn)代碼。一邊編寫代碼，一邊測試，往往會有比較好的效果。單元測試由誰來執(zhí)行一般情況下由程序員完成單元測試工作單元測試也可以看作是編碼工作的一部分，在編碼的過程中考慮測試問題，得到的將是更優(yōu)質(zhì)的代碼所以，單元測試有時也稱自測試許多集成開發(fā)環(huán)境（IDE）可以集成各種單元測試工具幫助編碼人員進(jìn)行單元測試，如Eclipse環(huán)境中集成Junit必要時可以由測試團(tuán)隊(duì)專門進(jìn)行單元測試單元測試的一般流程開發(fā)小組承擔(dān)單元測試在開發(fā)負(fù)責(zé)人（Leader）的監(jiān)督下進(jìn)行根據(jù)單元測試計(jì)劃和測試說明文檔，設(shè)計(jì)測試用例，執(zhí)行充分的測試，達(dá)到覆蓋要求建議專人負(fù)責(zé)監(jiān)控測試過程單元測試具有回歸性單元測試的實(shí)質(zhì)主要是證明代碼的行為和我們的期望是否一致在進(jìn)行單元測試時常常并不關(guān)心整個產(chǎn)品或系統(tǒng)的確認(rèn)、驗(yàn)證及其正確性等方面主要側(cè)重于功能有時也關(guān)注性能方面的問題只有所有單元的行為都通過了驗(yàn)證，確保它和我們的期望一致，才能開始進(jìn)行集成測試所以，足夠的單元測試的好處在于：使開發(fā)工作變得更輕松對設(shè)計(jì)工作也能提供幫助大大減少了花費(fèi)在調(diào)試上面的時間單元測試的目標(biāo)驗(yàn)證開發(fā)人員所編寫的代碼是否產(chǎn)生預(yù)期結(jié)果、是否符合設(shè)計(jì)的要求，最終確保單元符合需求代碼的質(zhì)量、可復(fù)用性、代碼的可維護(hù)性及代碼的可擴(kuò)展性的檢查也是單元測試的目標(biāo)符合需求的單元代碼通常具備以下性質(zhì)正確性：代碼邏輯正確，能實(shí)現(xiàn)預(yù)期功能清晰性：代碼簡明、易懂，注釋準(zhǔn)確規(guī)范性：代碼符合規(guī)范一致性：代碼在命名上、風(fēng)格上保持統(tǒng)一高效性：盡可能減少執(zhí)行時間可復(fù)用性：代碼盡量標(biāo)準(zhǔn)化，便于復(fù)用為什么要進(jìn)行單元測試未經(jīng)測試覆蓋的單元代碼可能會存在大量的錯誤或缺陷這些錯誤或缺陷可能是嚴(yán)重的，可能是微小的或表面的但是，這些錯誤或缺陷可能會相互影響尤其在開發(fā)后期，錯誤或缺陷可能會擴(kuò)展這些暴露的錯誤或缺陷難于定位，結(jié)果會大幅度提高后期測試和維護(hù)成本，降低了開發(fā)商的市場競爭力單元測試在軟件測試中的作用和地位單元測試被認(rèn)為是集成測試的基礎(chǔ)：只有通過了單元測試，才能將各個單元集成在一起進(jìn)行集成測試單元測試通常在項(xiàng)目的詳細(xì)設(shè)計(jì)階段已經(jīng)開始了，貫穿于項(xiàng)目開發(fā)的生命周期中單元測試已經(jīng)不僅僅是只有編碼完成以后才能進(jìn)行的工作了單元測試的環(huán)境及過程驅(qū)動模塊（Driver）扮演被測模塊的主程序接收測試數(shù)據(jù)，將數(shù)據(jù)傳遞給被測模塊，最后輸出實(shí)際測試結(jié)果作用接受測試輸入對輸入進(jìn)行判斷將輸入傳給被測單元，驅(qū)動被測單元執(zhí)行接受被測單元執(zhí)行結(jié)果，并對結(jié)果進(jìn)行判斷將判斷結(jié)果作為用例執(zhí)行結(jié)果并輸出測試報告樁模塊（Stub）代替被測模塊需要調(diào)用的子模塊可以進(jìn)行少量的數(shù)據(jù)操作，不需要實(shí)現(xiàn)子模塊的所有功能根據(jù)需要實(shí)現(xiàn)或代替子模塊的一部分功能樁模塊是一次性模塊，主要是為了配合調(diào)用它的父模塊被測模塊和與它相關(guān)的驅(qū)動模塊和（或）樁模塊共同構(gòu)成了一個“測試環(huán)境”單元測試的過程缺陷的提交、跟蹤和報告一般借助于工具來支撐，如buzzilla、TestDirector等工具代碼審查、用例評審以靜態(tài)測試作為技術(shù)基礎(chǔ)用例的設(shè)計(jì)以黑盒測試方法和白盒測試方法及兩種方法的結(jié)合作為技術(shù)基礎(chǔ)是單元測試的進(jìn)入準(zhǔn)則缺陷的提交、跟蹤和報告一般借助于工具來支撐，如buzzilla、TestDirector等工具代碼審查、用例評審以靜態(tài)測試作為技術(shù)基礎(chǔ)用例的設(shè)計(jì)以黑盒測試方法和白盒測試方法及兩種方法的結(jié)合作為技術(shù)基礎(chǔ)是單元測試的進(jìn)入準(zhǔn)則單元測試的策略單元測試分析單元測試分析是單元測試用例設(shè)計(jì)的基礎(chǔ)，全面地分析才能設(shè)計(jì)出合理的測試用例涉及詳細(xì)設(shè)計(jì)、代碼、功能業(yè)務(wù)需求、非功能業(yè)務(wù)需求、組件內(nèi)部數(shù)據(jù)結(jié)構(gòu)、組件接口等方面單元測試分析的9條指導(dǎo)原則檢查詳細(xì)設(shè)計(jì)是否通過評審并驗(yàn)證其和代碼邏輯的一致性，為代碼審查和白盒測試用例設(shè)計(jì)服務(wù)分析單元組件涉及到的所有功能點(diǎn)和非功能需求，為功能性和非功能性用例設(shè)計(jì)服務(wù)分析單元組件是否滿足所有的邊界條件，為經(jīng)典的邊界值方法設(shè)計(jì)用例服務(wù)對強(qiáng)制發(fā)生的一些錯誤情況進(jìn)行分析，為意外情況設(shè)計(jì)補(bǔ)充用例服務(wù)分析被測單元組件接口分析模塊內(nèi)部的數(shù)據(jù)結(jié)構(gòu)分析基路徑覆蓋，為基路徑覆蓋設(shè)計(jì)用例服務(wù)分析其他覆蓋，為基本覆蓋設(shè)計(jì)用例服務(wù)分析單元出錯處理的正確性，為設(shè)計(jì)出錯處理用例服務(wù)單元測試用例的設(shè)計(jì)靜態(tài)測試技術(shù)用于單元測試一般不需要設(shè)計(jì)具體的測試用例按照靜態(tài)測試技術(shù)的要求完成相關(guān)工作即可動態(tài)測試技術(shù)用于單元測試黑盒方法：單元最小功能點(diǎn)覆蓋，邊界值法……白盒方法：對單元的內(nèi)部邏輯進(jìn)行測試黑盒測試—最小功能點(diǎn)覆蓋以ATM取款單元組件為例，其功能點(diǎn)有:（1）正常取款，（2）輸入的取款金額是否合法，（3）檢查超出當(dāng)天的最大取款（假設(shè)為2000RMB），（4）余額不足（假設(shè)賬號余額為1500RMB）（5）打印收據(jù)各功能點(diǎn)各一次，前提是銀行卡和密碼為有效非功能性測試非功能特性一般實(shí)現(xiàn)為特定的功能對排序算法效率的測試首先要實(shí)現(xiàn)排序功能，然后對其數(shù)據(jù)量、時間進(jìn)行測試系統(tǒng)登錄的安全性通過完成多次密碼輸入錯誤后拒絕登錄來實(shí)現(xiàn)，因此首先也要實(shí)現(xiàn)密碼多次錯誤的檢查功能。因此，非功能性測試一般通過黑盒測試實(shí)現(xiàn)特定的功能來達(dá)到測試的目的。黑盒測試—邊界值法銀行系統(tǒng)規(guī)定在每次ATM交易中，密碼輸入錯誤次數(shù)不能超過5次，超過5次要吞卡設(shè)N為密碼輸入錯誤的次數(shù)N小于等于5，則不吞卡，否則吞黑盒測試—強(qiáng)制錯誤情況發(fā)生主動造成磁盤空間不足主動造成內(nèi)存不足例如：黑盒技術(shù)設(shè)計(jì)單元測試用例小結(jié)測試程序單元的所有最小功能點(diǎn)是否覆蓋測試程序單元非功能性是否滿足要求，比如安全性、可靠性、強(qiáng)度/壓力測試（可選）考慮可選的其他測試特性，如接口、邊界、余量、強(qiáng)制性出錯、人機(jī)交互界面測試等白盒測試單元測試用例的設(shè)計(jì)可以使用黑盒測試方法，但以白盒測試為主黑盒測試側(cè)重于功能，白盒測試側(cè)重于邏輯白盒測試進(jìn)入單元測試的前提條件是測試人員已經(jīng)對被測試對象有了一定的了解，基本明確了被測試軟件的邏輯結(jié)構(gòu)為了度量測試的完整性，白盒測試通常也要求達(dá)到一定的覆蓋率通常使用下面幾種測試覆蓋率來度量測試如語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋、路徑覆蓋等白盒測試最低應(yīng)該達(dá)到的覆蓋率目標(biāo)是：語句覆蓋率達(dá)到100%分支覆蓋率達(dá)到100%覆蓋程序中主要的路徑測試人員在實(shí)際工作中要根據(jù)不同的覆蓋要求用白盒方法來設(shè)計(jì)面向代碼的單元測試用例，運(yùn)行測試用例后至少應(yīng)該同時滿足如下幾個覆蓋：對程序模塊的所有獨(dú)立的執(zhí)行路徑至少覆蓋一次，達(dá)到基路徑覆蓋，即McCabe覆蓋對所有