測試驅動開發

.

1

大綱

.測試驅動開發介紹

2.單元測試

?3.測試工具

。4.當前面臨的問題

。5.相關資料

1.測試驅動開發介紹

1.背景

測試驅動開發(TestDrivenDevelopment,英文縮寫

TDD)是極限編程的一個重要組成部分，它的基本思想就是

在開發功能代碼之前，先編寫測試代碼。也就是說在明確要

開發某個功能后，首先思考如何對這個功能進行測試，并完

成測試代碼的編寫，然后編寫相關的代碼滿足這些測試用例。

然后循環進行添加其他功能，直到完成全部功能的開發。代

碼整潔可用(cleancodethatworks)是測試驅動開發所追求

的目標。雖然TDD光大于極限編程，但測試驅動開發完全可

以單獨應用。

1.測試驅動開發介紹

2.極限編程

極限編程誕生于一種加強開發者與用戶的溝通需求，讓客戶全面參與軟件

的開發設計，保證變化的需求及時得到修正。要讓客戶能方便地與開發人員溝通,

一定要用客戶理解的語言，先測試再編碼就是先給客戶軟件的外部輪廓，客戶使

用的功能展現，讓客戶感覺到未來軟件的樣子，先測試再編碼與瀑布模型顯然是

背道而馳的。同時，極限編程注重用戶反饋與讓客戶加入開發是一致的，讓客戶

參與就是隨時反饋軟件是否符合客戶的要求。有了反饋，開發子過程變短，迭代

也就很自然出現了，快速迭代，小版本發布都讓開發過程變成更多的自反饋過

程。

1.測試驅動開發介紹

?：?3.測試驅動開發的優點)

跟測試后進行的開發方式相比，它有如下好處：

。(1)測試驅動開發最重要的功能還在于保障代碼的正確性，能夠迅速發現、定

位bug。針對關鍵代碼的測試集，以及不斷完善的測試用例，為迅速發現、定位.

bug提供了條件。

。(2)痛過翁寫i弋碼的測試用例，對其功能的分解、使用過程、接口都進行了設

計。而且這種從使用角度對代碼的設計通常更符合后期開發的需求。可測試的要

求，對代碼的內聚性的提高和復用都非常有益。因此測試驅動開發也是一種代碼

設計的過程。(

*(3)寫單元測試的時候，很容易就可以為一個行為寫一個測試用例，讓它通過，

然后為另一種行為寫另一個測試用例。也就是說，整個任務會械劃分成很多小的

任務，獨立完成。如果我們不用TDD而直接實現的話，我們很容易就會同時把所

有的行為都實現了。這樣花的時間長，而且在這相當長的時間里面，寫的代碼都

是沒有測試過，不能保證準確性的。相反的，用TDD的話，我們只實現要測的

行為的代碼。它只花費很少的時間(幾分鐘)，而且可以馬上測試。

1.測試驅動開發介紹

。（4）為了更容易的寫單元測試，我們會廣泛的使用接口。這個會讓單

元測試代碼很容易讀跟寫，因為測試代碼里面沒有多余的數據。如果我

不用TDD而是直接寫實現的話，我們經常會使用現成的類，測試為了

調用現成的類，就不得不創建很多多余的數據，創建很巨型的對象。

。（5）因為廣泛的使用接口，我們的類之間就不會藕合，因此重用性更

好。

。（6）發現比傳統測試方式更多的Bug。

。（7）完工時完工。表明我可以很清楚的看到自己的這段工作已經結束

了，而傳統的方式很難知道什么時候編碼工作結束了。

1.測試驅動開發介紹

?：?4.測試驅動開發的過程

?：?1）明確當前要完成的功能。可以記錄成一個TODO列表。

。2）快速完成針對此功能的測試用例編寫。

。3）測試代碼編譯不通過。

。4）編寫對應的功能代碼。

。5）測試通過。

。6）對代碼進行重構，并保證測試通過。

。7）循環完成所有功能的開發。

可參考《測試驅動開發》第175頁

1.測試驅動開發介紹

?5.原則)

?(1)測試隔離。不同代碼的測試應該相互隔離。對一塊代碼的測試只考慮此代

碼的測試，不要考慮其實現細節(比如它使用了其他類的邊界條件)。

。(2)一頂帽子。開發人員開發過程中要做不同的工作，比如：編寫測試代碼、

開發功能代碼、對代碼重構等。做不同的事，承擔不同的角色。開發人員完成

對應的工作時應該保持注意力集中在當前工作上，而不要過多的考慮其他方面的

細節，保證頭上只有一頂帽子。避免考慮無關細節過多，無謂地增加復雜度。

(3)測試列表。需要測試的功能點很多。應該在任何階段想添加功能需求問題

時，把相關功能點加到測試列表中，然后繼續手頭工作。然后不斷的完成對應；

的測試用例、功能代碼、重構。一是避免疏漏，也避免干擾當前進行的工作。

?(4)測試驅動。這個比較核心。完成某個功能，某個類，首先編寫測試代碼，

考慮其如何使用、如何測試。然后在對其進行設計、編碼。

*(5)先寫斷言。測試代碼編寫時，應該首先編寫對功能代碼的判斷用的斷言語’

句，然后編寫相應的輔助語句。

1.測試驅動開發介紹

(6)可測試性。功能代碼設計、開發時應該具有較強的可測試性。其實遵循比

較好的設計原則的代碼都具備較好的測試性。比如比較高的內聚性，盡量依賴

于接口等。

(7)及時重構。無論是功能代碼還是測試代碼，對結構不合理，重復的代碼等

情況，在測試通過后，及時進行重構。

(8)小步前進。軟件開發是個復雜性非常高的工作，開發過程中要考慮很多東

西，包括代碼的正確任、可擴展性、性能等等，很多問題都是因為復雜性太大尋日

致的。極限編程提出】個非常好的思路就是小步前進。把所有的規模大、復雜

性高的工作，分解成小的任務來兀對于一人類來說，一個功能一個功能的完

成，如果太困難就再分解。每個功能的完成就走測試代碼一功能代碼一測試一重

構的循環。通過分解降低整個系統開發的復雜性。這樣的效果非常明顯。幾個小

的功能代碼完成后，大的功能代碼幾乎是不用調試就可以通過。一個個類方法的

實現，很快就看到整個類很快就完成啦。本來感覺很多特性需要增加，很快就會

看到沒有兒人啦。你甚至會為這個速度感到震驚。(我理解，是大幅度減少調

試、出錯的時間產生的這種速度感)

1.測試驅動開發介紹

?6.測試范圍、粒度

對哪些功能進行測試？會不會太繁瑣？什么時候可以停止測試？這些問題比較常見。按大

師KentBenk的話，對那些你認為應該測試的代碼進行測試。就是說，要相信自己的感覺，；

O感到疲勞就應該停下來休息

一下。囑贏梭嚕鰥僵髓點測試。

測試驅動開發強調測試并不應該是負擔，而應該是幫助我們減輕工作量的方法。而對于何

時停止編寫測試用例，也是應該根烤你的經驗，功能復雜、核心功能的代碼就應該編寫更

全面、細致的測試用例，否則測試流程即可。

測試范圍沒有靜查的標準，同時也應該可以隨著時間改變。對于開始沒有編寫足夠的測試

的功能代碼，朗著bug的出現，根據bug補齊相關的測試用例即可。

小步前進的原則，要求我們對大的功能塊測試時，應該先分拆成更小的功能塊進行測試，

比如一個類A使用了類B、C,就應該編寫到A使用B、C功能的測試代碼前，完成對B、C

的測試和開發。那么是不是每個小類或者小函數都應該測試哪？我認為沒有必要。你應該

運用你的經物驗,，對那些可能出問題的地方重點測試，感覺不可能出問題的地方就等它真正

出問題的時族再補測試吧。

1.測試驅動開發介紹

。7.怎么編寫測試用例

Y測試用例的編寫就用上了傳統的測試技術。

9操作過程盡量模擬正常使用的過程。

力全面的測試用例應該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋。

9測試數據盡量包括：真實數據、邊界數據。

9測試語句和測試數據應該盡量簡單，容易理解。

力為了避免對其他代碼過多的依賴，可以實現簡單的樁函數或樁類(Mock

Object)。

《如果內部狀態非常復雜或者應該判斷流程而不是狀態，可以通過記錄日志字

符串的方式進行驗證。

2.單元測試

?1.概述

i單元測試的目標:確保模塊被正確地編碼。

力由誰去做:通常由開發人員執行。

《怎樣去測試:功能測試可以用黑盒測試方法，代碼

測試可用白盒測試方法。

小什么時候停止:當開發人員感到代碼沒有缺陷時。

2.單元測試

2.單元測試的重要性

《一個盡責的單元測試方法將會在產品開發的某個階段發現很多的Bug,

并且修改它們的成本也很低。

&系統開發的后期階段，Bug的檢測和修改將會變得更加困難，并要消

耗大量的時間和開發費用。

力無論什么時候做出修改都要進行完整的回歸測試，在生命周期中盡

早的對產品代碼進行測試將是效率和質量得到最好的保證。

力在提供了經過單元測試的情況下，系統集成過程將會大大的簡化。

開發人員可以將精力集中在單元之間的交互作用和全局的功能實現

上，而不會陷入充滿很多Bug的單元之中不能自拔。

力使測試工作的效率發揮到最大化的關鍵在于選擇正確的測試策略，

這包含了完全的單元測試的概念，以及對測試過程的良好的管理，

還有適當的使用好工具來支持測試過程。

2.單元測試

3.為什么要進行單元測試

(1)單元測試是不是太浪費時間了？

不經過單元測試，直接進入集成測試，系統正常工作的可能性非常低，大量的時

間被花費在跟蹤那些簡單的BugI:,會導致集成為一個系統時增加額外的工期。

』編寫完整計劃的單元測試和編寫實際的代碼所花費的精力大致相同。但是，一旦

完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩定可靠的

加件的情況下，開發人員能夠進行更高效的系統集成工作，這才是真正意義上的

進步。

位調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。

(2)單元測試僅僅是為了證明這些代碼作了什么嗎？

』這是那些沒有首先為每個單元編寫一個詳細設計文檔而直接跳到編碼階段的開發

人員提出的一條普遍的抱怨。這樣的測試完全基于已經寫好的代碼，這無法證明

任何事情。?

工單元測試基于詳細設計文檔，這樣的測試可以找到更多的代碼錯誤，甚至是詳細］

設土的錯誤。

4因此，高質量的單元測試需要高質量的詳細設計文檔。

2.單元測試

(3)我是一個很棒的程序員，是不是可以不進行單元測試呢?

工每個人都可能犯錯誤。

4真正的完整的系統往往是非常復雜的，不能寄希望于沒有進行廣泛

的測試和Bug修改過程就可以正常工作。

(4)有集成測試就夠了，集成測試將會抓住所有的Bug。

工系統規模愈來愈大，復雜度愈來愈高，沒有單元測試，開發人員很

可能會花費大量的時間僅僅是為了使該系統能夠運行。

4任何實際的測試方案都無法執行。

工在系統集成階段，對單元功能全面測試的負載程度遠遠的超過獨立

進行的單元測試過程。

工最后的結果是測試將無法達到它所應該有的全面性，一些缺陷將被

遺漏，棄且很多Bug蔣斌忽略過去。

2.單元測試

(5)單元測試的成本效率不高？

無論什么時候做出修改都要進行完整的回

歸測試。

在生命周期中盡早的對產品進行測試將使

越早測試付出代價就越低

效率和質量得到最好的保證

Bug修改越晚，費用就越高，單元測試是

一個在早期抓住Bug的機會。

成本

相比后階段的測試，單元測試的創建更簡

單，維護更容易，并且可以更方便的進行

重復。開發部署

從全程的測試費用來考慮，相比復雜且曠階段需求設計編照單元測試驗收測試交付后維護

日持久的集成測試，或是不穩定的系統，到正費/p>

單元測試所需的費用是最低的。

2.單元測試

?4.單元測試的策略

。單元測試最核心的并不是工具的使用，而是測試的策略和方法。工具也

好，實現手段也好，只是開展單元測試的必需品。

。以下是單元測試常采用的策略：

。1）哪些是重點模塊？

2）哪些程序是最復雜、最容易出錯的？

。3）哪些程序是相對獨立，應當提前測試的？

。4）哪些程序最容易擴散錯誤？

。5）哪些程序是開發者最沒有信心的？

。6）80?20原則：80%的缺陷聚集在20%的模塊中，經常出錯的模塊改錯

后還會經常出錯，這種應該列入測試重點。

2,單元測試

?5.測試用例的設計

?：?單元測試的核心是測試用例的設計，測試用例的核心是測試

數據的設計。

。測試用例的設計主要從兩方面考慮：

。(1)功能。我們為了驗證一個函數是否實現了它的功能，

通常采用黑盒測試的方法。常用的方法有邊界值、等價類、

因果圖，關于黑盒測試方法的詳細介紹，參見《測試用例設

計白皮書.doc》。

(2)邏輯結構。通常采用白盒測試的方法。常用的方法有

判定覆蓋、條件覆蓋、條件判定組合覆蓋，關于白盒測試的

方法的詳細喬紹，參見《白盒測試方法.pdf》。

2,單元測試

*6,TDD與單元測試的區別

TDD是一種設計手段，而不僅僅是測試手段。

TDD的原則是“只做必要的事，不做多余的

事”。TDD其實并不是單純強調測試，它首

先是需求分析和設計技術。

3.測試工具

?1.概述

。為了完成測試驅動開發以及單元測試，我們

需要相應的工具。

?針對C++的單元測試工具是CppUnit

針對c#的單元測試工具是NUnit

3.測試工具

?2.NUnit介紹

。NUM是一個單元測試框架，專門針對于.NET來寫的.其實在前面有

JUEt(Java),CPPUEt(C++),他們者B是xllnit的一員.最初，它是從JUMt而來.

現在的版本是248.

NUn4最初是由JamesW.Newkirk,AlexeiA.Vorontsov和PhilipA.

Craig,后來開發團隊逐漸龐大起來.在并發過程中，KentBeck和Erich

Gamma2位牛人也提供了許多幫助.看來對于NUnit還真是下了一番力氣

T.J

。NUM是xUM家族種的第4個主打產品,完全由C#語言來編寫，并且編寫時

充分利用了許多.NET的特性，比如反射，客戶屬性等等.

。最重要的一點是它適合于所有.NET語言.

如果你還沒有下載，可以到/去下載.

3.測試工具

?3.NUnit的安裝

免費，開源的單元測試軟件。

安裝只要運行安裝程序，按所有缺省設置即可。

NUNIT：www.nunit.org

NUNITADDIN：

http://sourceforge.net/projects/mmitaddin/

VisualStudio2005的一個用來集成Nunit單元測試工具的插

件。

NUNIT的中文文檔：/nun巾index.html

3.測試工具

?4.如何在項目中應用NUnit

參見《NUnit2.0詳細使用方法.doc》第8頁

3.測試工具

5.NUn讓的常用屬性

(1)TestFixture

(2)Test

(3)SetUp/TearDown

(4)TestFixtureSetUp/TestFixtureTearDown

(5)ExpectedException

(6)Ignore

(7)Category

(8)Explicit

(9)ExpectedException

(1)至(2)參見《NUrdt2.0詳細使用方法.doc》第5頁

(3)至(8)參加《NUnit2.0詳細使用方法.doc》第13頁

3.測試工具

6.NUrdt的各種斷言

斷言用于幫助你確定某個被測試函蒙是否工作正常，通常一個測試方法中會有多個斷言,

當一個斷言失敗時，該測試方法就會終止。Assert類下面有如下幾個斷言函數：

(1)AreEquals(expected,actual[,stringmessage])

Expected是被測試代碼的期望值，actual是被測試代碼的實際值，message是一個可選的消息,

在二個值不一