第3章 軟件測試

1、,第三章 單元測試,[本章要點]單元測試的定義；單元測試同集成測試和系統(tǒng)測試的區(qū)別；單元測試環(huán)境的組成；單元測試的分析方法；單元測試的用例設(shè)計方法；單元測試的過程；單元測試舉例。,[本章目標(biāo)]掌握單元測試的概念；了解單元測試的誤區(qū)；了解單元測試與集成測試和系統(tǒng)測試的區(qū)別；掌握單元測試的策略；掌握單元測試分析的方法；掌握單元測試用例設(shè)計方法。,3.1單元測試概述 通常而言，單元測試是在軟件

2、開發(fā)過程中要進行的最低級別的測試活動，或者說是針對軟件設(shè)計的最小單位——程序模塊，進行正確性檢驗的測試工作。其目的在于發(fā)現(xiàn)每個程序模塊內(nèi)部可能存在的差錯。 在單元測試活動中，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試，主要工作分為兩個步驟：人工靜態(tài)檢查和動態(tài)執(zhí)行跟蹤。 單元測試的分工大致如下：一般由開發(fā)組在一般由開發(fā)組在開發(fā)組組長監(jiān)督下進行，保證使,用合適的測試技術(shù)，根據(jù)單元測試計劃和

3、測試說明文檔中制定的要求，執(zhí)行充分的測試；由編寫該單元的開發(fā)組中的成員設(shè)計所需要的測試用例，測試該單元并修改缺陷。 3.1.1單元測試誤區(qū) 1、單元測試是一種浪費時間的工作 2、單元測試只能證明代碼做了什么 3、我是個很棒的程序員， 我是不是可以不進行單元測試？ 4、集成測試能捕捉到所有的Bug 5、單元測試的成本效率不高,其實，在經(jīng)過了單元測試之后，系統(tǒng)集成過程將會大大地簡化。

4、 3.1.2單元測試與集成測試區(qū)別 單元測試與集成測試的主要區(qū)別在于測試的對象不同。單元測試對象是實現(xiàn)具體功能的單元，一般對應(yīng)詳細(xì)設(shè)計中所描述的設(shè)計單元。集成測試是針對概要設(shè)計所包含的模塊以及模塊組合進行的測試。 單元測試所使用的主要測試方法是基于代碼的白盒測試。而集成測試所使用的主要測試方法是基于功能的黑盒測試。,因為集成測試要在所有要集成的模塊都通過了單元測試之后才能進行，也就是說在測試時間上，集

5、成測試要晚于單元測試，所以單元測試的好壞直接影響著集成測試。 單元測試的工作內(nèi)容包括模塊內(nèi)程序的邏輯、功能、參數(shù)傳遞、變量引用、出錯處理、需求和設(shè)計中有具體的要求等方面測試。集成測試的工作內(nèi)容主要是驗證各個接口、接口之間的數(shù)據(jù)傳遞關(guān)系、模塊組合后能否達到預(yù)期效果。 雖然單元測試和集成測試有一些區(qū)別，但是二者之間也有著千絲萬縷的聯(lián)系。目前集成測試和單元測試的界限趨向模糊。,3.1.3單元測試與系統(tǒng)測試區(qū)

6、別 單元測試與系統(tǒng)測試的區(qū)別不僅僅在于測試的對象和測試的層次的不同，最重要的區(qū)別是測試性質(zhì)不同。在單元測試過程中，單元測試的執(zhí)行早于系統(tǒng)測試，測試的是軟件單元的具體實現(xiàn)、內(nèi)部邏輯結(jié)構(gòu)以及數(shù)據(jù)流向等。系統(tǒng)測試屬于后期測試，主要是根據(jù)需求規(guī)格說明書進行的，是從用戶角度來進行的功能測試和性能測試等等，證明系統(tǒng)是否滿足用戶的需求。 單元測試中發(fā)現(xiàn)的錯誤容易進行定位，并且多個單元測試可以并行進行；而系統(tǒng)測試

7、發(fā)現(xiàn)的錯誤比較難定位。,3.2單元測試環(huán)境 由于一個模塊或一個方法（Method）并不是一個獨立的程序，在考慮測試它時要同時考慮它和外界的聯(lián)系，因此要用到一些輔助模塊，來模擬與所測模塊相聯(lián)系的其他模塊。一般把這些輔助模塊分為兩種： 1、驅(qū)動模塊（driver）:相當(dāng)于所測模塊的主程序。 2、樁模塊（stub）:用于代替所測模塊調(diào)用的子模塊。 那么，所測模塊和與它相關(guān)

8、的驅(qū)動模塊及樁模塊共同構(gòu)成了一個“測試環(huán)境”，如圖3-2所示。,圖3-2 單元測試環(huán)境,3.3單元測試策略 單元測試涉及到的測試技術(shù)通常有：針對被測單元需求的功能測試、用于代碼評審和代碼走讀的靜態(tài)測試、白盒測試、狀態(tài)轉(zhuǎn)換測試和非功能測試。 為了提高單元測試的質(zhì)量，只了解這些單元測試技術(shù)還遠(yuǎn)遠(yuǎn)不夠，還要選擇合適的測試策略。在選擇測試策略時，主要考慮如下3種方式：自頂向下（Top Down Unit Te

9、sting）的單元測試策略、自底向上的單元測試策略（Bottom up Unit Testing）和孤立的單元測試策略。,3.3.1自頂向下的單元測試策略 一）步驟： 1. 從最頂層開始，把頂層調(diào)用的單元做成樁模塊。 2. 對第二層測試，使用上面已測試的單元做驅(qū)動模塊。 3. 依次類推，直到全部單元測試結(jié)束。 二）優(yōu)點：可以在集成測試之前為系統(tǒng)提供早期的集成途徑。 三）缺點：

10、單元測試被樁模塊控制，隨著單元測試的不斷進行，測試過程也會變得越來越復(fù)雜，測試難度以及開發(fā)和維護的成本都不斷增加；,要求的低層次的結(jié)構(gòu)覆蓋率也難以得到保證；由于需求變更或其他原因而必須更改任何一個單元時，就必須重新測試該單元下層調(diào)用的所有單元；低層單元測試依賴頂層測試，無法進行并行測試，使測試進度受到不同程度的影響，延長測試周期。 四）總結(jié)：從上述分析中，不難看出該測試策略的成本要高于孤立的單元測試成本，因此從測試成本方面來考慮

11、，并不是最佳的單元測試策略。 3.3.2自底向上的單元測試 一）步驟： 1、先對模塊調(diào)用圖上的最底層模塊開始測試，模擬調(diào)用該模塊的模塊為驅(qū)動模塊。,2、其次，對上一層模塊進行單元測試，用已經(jīng)被測試過的模塊做樁模塊。 3、依次類推，直到全部單元測試結(jié)束。 二）優(yōu)點：不需要單獨設(shè)計樁模塊。 三）缺點：隨著單元測試的不斷進行，測試過程會變得越來越復(fù)雜，測試周期延長，測試和維護的成本增加；隨著各

12、個基本單元逐步加入，系統(tǒng)會變得異常龐大，因此測試人員不容易控制；越接近頂層的模塊的測試其結(jié)構(gòu)覆蓋率就越難以保證； 另外，頂層測試易受底層模塊變更的影響，任何一個模塊修改之后，直接或間接調(diào)用該模塊的所有單元都要重新測試。,由于只有在底層單元測試完畢之后才能夠進行頂層單元的測試，所以并行性不好。另外，自底向上的單元測試也不能和詳細(xì)設(shè)計、編碼同步進行。 四）總結(jié)：相對其它測試策略而言，該測試策略比較合理,尤其是需要考慮

13、對象或復(fù)用時。它屬于面向功能的測試，而非面向結(jié)構(gòu)的測試。對那些以高覆蓋率為目標(biāo)或者軟件開發(fā)時間緊張的軟件項目來說，這種測試方法不適用。 3.3.3孤立測試 一）步驟：無需考慮每個模塊與其他模塊之間的關(guān)系，分別為每個模塊單獨設(shè)計樁模塊和驅(qū)動模塊，逐一完成所有單元模塊的測試。,二）優(yōu)點：該方法簡單、容易操作，因此所需測試時間短，能夠達到高覆蓋率。 三）缺點：不能為集成測試提供早期的集成途徑。依賴結(jié)構(gòu)設(shè)計信息，需要設(shè)

14、計多個樁模塊和驅(qū)動模塊，增加了額外的測試成本。 四）總結(jié)：該方法是比較理想的單元測試方法。如輔助適當(dāng)?shù)募蓽y試策略，有利于縮短項目的開發(fā)時間。 3.3.4綜合測試 在單元測試中，為了有效地減少開發(fā)樁模塊的工作量，可以考慮綜合自底向上測試策略和孤立測試策略。,3.4單元測試分析 一般可以從如下幾個方面進行分析和測試，即： 1、判斷得到的結(jié)果是否正確？ 因為，對于測試

15、而言，首要的任務(wù)就是察看一下所期望的結(jié)果是否正確，即對結(jié)果進行驗證。 2、判斷是否滿足所有的邊界條件？ 邊界條件是指軟件計劃的操作界限所在的邊緣條件。邊界條件測試是單元測試中最后也是最重要的一項任務(wù)。在使用邊界值測試的方法時，不妨結(jié)合實際項目參考以下測試技巧：輸入了完全偽造或者和要求不一致的數(shù)據(jù)。 1）輸入一個格式錯誤的數(shù)據(jù)。,2）提供一個空值或者不完整的值。 3）與意

16、料之中的值相差很遠(yuǎn)的值。 4）假如一個列表中不允許有重復(fù)的數(shù)值存在，就可以給它傳入一組存在重復(fù)數(shù)值的列表；如果某個字段的值要求唯一，那么可以輸入兩個或多個相同的數(shù)值來進行測試。 5）假如一個列表中不允許有重復(fù)的數(shù)值存在，就可以給它傳入一組存在重復(fù)數(shù)值的列表；如果某個字段的值 要求唯一，那么可以輸入兩個或多個相同的數(shù)值來進行測試。 6） 如果要求按照一定的順序來存儲一些數(shù)據(jù)，那么可以輸入一些順序打亂的數(shù)據(jù)

17、來做測試。,7）對于一些做了安全限制的部分，盡量通過各種途徑嘗試能否繞過安全限制的測試。 8） 如果功能的啟用有一定的順序限制，就用和期望不一致的順序來進行測試。 3、分析能否使用反向關(guān)聯(lián)檢查？ 在實際程序中，有一些方法可以使用反向的邏輯關(guān)系來驗證它們。 4、分析是否能使用其他手段來交叉檢查一下結(jié)果？ 一般而言，對某個值進行計算會有一種以上的算法，但我們會因考慮到運行效率或其他方面

18、的原因而選擇其中的一種。 5、分析是否可以強制一些錯誤發(fā)生？,在實際使用過程當(dāng)中，總會有意想不到各種各樣的情況和錯誤發(fā)生。 6、分析模塊接口 數(shù)據(jù)在接口處出錯就好像丟掉了進入大門的鑰匙，無法進行下一步的工作，只有在數(shù)據(jù)能正確流入、流出模塊的前提下，其他測試才有意義。 7、分析局部數(shù)據(jù)結(jié)構(gòu) 局部數(shù)據(jù)結(jié)構(gòu)往往是錯誤的根源，對其檢查主要是為了保證臨時存儲在模塊內(nèi)的數(shù)據(jù)在程序執(zhí)行

19、過程中完整、正確，因此應(yīng)仔細(xì)設(shè)計測試用例。 8、 分析獨立路徑,在模塊中應(yīng)對每一條獨立執(zhí)行路徑進行測試，單元測試的基本任務(wù)是保證模塊中每條語句至少執(zhí)行一次。 9、 分析出錯處理是否正確 一個好的設(shè)計應(yīng)能預(yù)見各種出錯條件，并進行適當(dāng)?shù)某鲥e處理，即預(yù)設(shè)各種出錯處理通路。 3.5單元測試用例設(shè)計 單元測試用例的設(shè)計既可以使用白盒測試也可以使用黑盒測試，但以白盒測試為主。 白

20、盒測試進入的前提條件是測試人員已經(jīng)對被測試對象有了一定的了解，基本上明確了被測試軟件的邏輯結(jié)構(gòu)。,黑盒測試是要首先了解軟件產(chǎn)品具備的功能和性能等需求，再根據(jù)需求設(shè)計一批測試用例以驗證程序內(nèi)部活動是否符合設(shè)計要求的活動。 測試人員在實際工作中至少應(yīng)該設(shè)計能夠覆蓋如下需求的基于功能的單元測試用例： 測試程序單元的功能是否實現(xiàn)； 測試程序單元性能是否滿足要求（可選）； 是否有可選的其它測試

21、特性，如邊界、余量、安全性、可靠性、強度測試、人機交互界面測試等。 無論是白盒測試還是黑盒測試，每個測試用例都應(yīng)該包含下面4 個關(guān)鍵元素：,(1) 被測單元模塊初始狀態(tài)聲明，即測試用例的開始狀態(tài)（僅適用于被測單元維持了調(diào)用中間狀態(tài)的情況)； (2) 被測單元的輸入，包含由被測單元讀入的任何外部數(shù)據(jù)值； (3) 該測試用例實際測試的代碼，用被測單元的功能和測試用例設(shè)計中使用的分析來說明，如：單元中

22、哪一個決策條件被測試； (4) 測試用例的期望輸出結(jié)果（在測試進行之前的測試說明中定義）。 一、測試用例設(shè)計步驟 以下描述進行測試用例設(shè)計的6步通用過程。,步驟1：首先使被測單元運行； 這個階段適合的技術(shù)有： ①模塊設(shè)計說明導(dǎo)出的測試 ②對等區(qū)間劃分 步驟2：正面測試(Positive Testing)

23、 這個階段適合的技術(shù)： ①設(shè)計說明導(dǎo)出的測試 ②對等區(qū)間劃分 ③狀態(tài)轉(zhuǎn)換測試 步驟3：負(fù)面測試(Negative Testing) 適合的技術(shù)有： ①錯誤猜測,②邊界值分析 ③內(nèi)部邊界值測試 ④狀態(tài)轉(zhuǎn)換測試 步驟4:

24、模塊設(shè)計需求中其它測試特性用例設(shè)計 適合的技術(shù)：設(shè)計說明導(dǎo)出的測試 步驟5：覆蓋率測試用例設(shè)計 適合的技術(shù)： ①分支測試 ②條件測試 ③數(shù)據(jù)定義－使用測試 ④狀態(tài)轉(zhuǎn)換測試 步驟6：測試執(zhí)行,步驟7：完善代碼覆蓋 適合的技術(shù)：

25、 ①分支測試 ②條件測試 ③設(shè)計定義――試驗測試 ④狀態(tài)轉(zhuǎn)換測試,3.6單元測試過程 圖3-7從宏觀的角度概括了單元測試的工作過程圖。 一、單元測試進入和退出準(zhǔn)則 如表3-1和表3-2所示：,表3-1 進入準(zhǔn)則,,表3-2 退出準(zhǔn)則,二、單元測試過程,,圖3-7 單元測試工作過程,（1）準(zhǔn)備階段（2）編制階段（3）代碼審查階段

26、（4）單元測試階段（5）評審、提交階段,,,3.7單元測試舉例 一、單元測試計劃 1. 簡介 這份文檔的目標(biāo)是詳細(xì)描述對兩票系統(tǒng)的可以實現(xiàn)在二次系統(tǒng)圖上進行圖形開票模塊的功能驗證的測試過程。 2. 本測試的總目標(biāo)： 是否實現(xiàn)了需求文檔中定義的所有功能。 3. 完整性需求 在測試該模塊是否實現(xiàn)了需求文檔中定義的所有功能之前，應(yīng)該做如下兩項工作：,①測試數(shù)據(jù)初

27、始化是否無誤； ②測試二次圖開票GUI界面是否與系統(tǒng)維護模塊顯示一致。 4. 單元測試終止標(biāo)準(zhǔn) ①硬件資源不足或故障造成軟件無法運行 ②軟件運行后無法正確顯示（如：因數(shù)據(jù)初始化有誤造成GUI界面同系統(tǒng)維護模塊顯示不一致或不正確等）； ③所有功能測試均已經(jīng)完成 5. 資源需求 ①軟件資源 操作系統(tǒng)：windows 2000,web服務(wù)器：Tomcat 5.0

28、 數(shù)據(jù)庫服務(wù)器：SQL Server 2000 瀏覽器：Microsoft IE 6.0 測試工具：Junit ②硬件資源 同開發(fā)用pc機配置相同即可。 ③測試進度,表3-3 二次系統(tǒng)圖圖形開票模塊,6. 準(zhǔn)備測試的特征 以下特征將被測試，以確保該模塊能滿足需求規(guī)格說明書中指定的需求： 需求2.2.1 用戶界面 需求2.2

29、.2 彈出菜單 需求2.2.3圖形開票 7. 不準(zhǔn)備測試的特征 本次測試將不考慮是否能夠同一次系統(tǒng)圖圖形開票模塊的集成。 8. 測試方法 該單元測試方法包括功能測試、GUI測試。,9. 通過/失敗標(biāo)準(zhǔn) 10. 測試結(jié)束后須提交的產(chǎn)物包括以下幾個文檔： 本測試計劃 測試規(guī)格說明文檔 測試結(jié)果報告 向測試經(jīng)理和開發(fā)經(jīng)理提交

30、的每日測試狀態(tài)報告 缺陷報告 11、測試執(zhí)行人員 12、風(fēng)險和應(yīng)急計劃,,二、測試的設(shè)計和開發(fā) 測試設(shè)計和開發(fā)要以測試計劃作為輸入。在設(shè)計測試時，首先應(yīng)明確測試目標(biāo)（細(xì)化測試的方法和范圍）；確定每個測試的輸入規(guī)格說明；確定每個測試使用的測試配置；復(fù)查測試設(shè)計的覆蓋率和測試的準(zhǔn)確度。 在對本單元進行測試時所采用的方法是：先完成黑盒測試，然后統(tǒng)計白盒覆蓋率，針對未覆蓋的

31、邏輯單位設(shè)計測試用例覆蓋它。 然后，就應(yīng)該開發(fā)測試用例，應(yīng)該注意的是在測試用例中應(yīng)該盡可能詳細(xì)地描述測試過程，對于耗時的測試進行自動化。 最后，驗證和調(diào)試測試。,3.8單元測試經(jīng)驗總結(jié) 測試人員在進行測試的工作過程中，應(yīng)該注意積累測試工作經(jīng)驗，這樣可以縮短單元測試的時間，提高測試效果和效率。如： 1、在做單元測試的過程中，要靈活選用測試用例設(shè)計技術(shù)，如本章中的兩票系統(tǒng)單元測試過程

32、中，首先使用黑盒測試用例設(shè)計技術(shù)，然后根據(jù)相應(yīng)的覆蓋率統(tǒng)計再補充白盒測試用例。既減少了測試工作的重復(fù)，又保證了單元測試的完整性。 2、應(yīng)該盡量開發(fā)簡單測試驅(qū)動代碼，增強其可讀性。最重要的是，單元測試代碼中不能包含分支和邏輯語句，因為這意味著有多個測試在同時進行。這樣將會使測試代碼變得難以理解和維護。,本章小結(jié) 通過單元測試，我們驗證開發(fā)人員所書寫的編碼是可以按照其所設(shè)想的方式執(zhí)行的，產(chǎn)出了符合預(yù)期值的結(jié)果。這就實

33、現(xiàn)了單元測試的目的。相比后面階段的測試，單元測試的創(chuàng)建更簡單，維護更容易，并且可以更方便的進行重復(fù)。 從全程的費用來考慮， 相比起那些復(fù)雜且曠日持久的集成測試，或是不穩(wěn)定的軟件系統(tǒng)來說，單元測試所需的費用是很低的。 模塊單元設(shè)計完畢之后的開發(fā)階段就是單元測試。,值得注意的是，如果在書寫代碼之前就進行單元測試，測試設(shè)計就會顯得更加靈活，因為一旦代碼完成，對軟件的測試可能就受制于代碼，傾向于測試該段代碼完