測試驅(qū)動開發(fā)課件

測試驅(qū)動開發(fā)

.

1

大綱

.測試驅(qū)動開發(fā)介紹

2.單元測試

?3.測試工具

。4.當(dāng)前面臨的問題

。5.相關(guān)資料

1.測試驅(qū)動開發(fā)介紹

1.背景

測試驅(qū)動開發(fā)(TestDrivenDevelopment,英文縮寫

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

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

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

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

然后循環(huán)進行添加其他功能，直到完成全部功能的開發(fā)。代

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

的目標(biāo)。雖然TDD光大于極限編程，但測試驅(qū)動開發(fā)完全可

以單獨應(yīng)用。

1.測試驅(qū)動開發(fā)介紹

2.極限編程

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

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

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

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

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

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

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

程。

1.測試驅(qū)動開發(fā)介紹

?：?3.測試驅(qū)動開發(fā)的優(yōu)點)

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

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

位bug。針對關(guān)鍵代碼的測試集，以及不斷完善的測試用例，為迅速發(fā)現(xiàn)、定位.

bug提供了條件。

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

計。而且這種從使用角度對代碼的設(shè)計通常更符合后期開發(fā)的需求?？蓽y試的要

求，對代碼的內(nèi)聚性的提高和復(fù)用都非常有益。因此測試驅(qū)動開發(fā)也是一種代碼

設(shè)計的過程。(

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

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

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

有的行為都實現(xiàn)了。這樣花的時間長，而且在這相當(dāng)長的時間里面，寫的代碼都

是沒有測試過，不能保證準(zhǔn)確性的。相反的，用TDD的話，我們只實現(xiàn)要測的

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

1.測試驅(qū)動開發(fā)介紹

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

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

不用TDD而是直接寫實現(xiàn)的話，我們經(jīng)常會使用現(xiàn)成的類，測試為了

調(diào)用現(xiàn)成的類，就不得不創(chuàng)建很多多余的數(shù)據(jù)，創(chuàng)建很巨型的對象。

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

好。

。（6）發(fā)現(xiàn)比傳統(tǒng)測試方式更多的Bug。

。（7）完工時完工。表明我可以很清楚的看到自己的這段工作已經(jīng)結(jié)束

了，而傳統(tǒng)的方式很難知道什么時候編碼工作結(jié)束了。

1.測試驅(qū)動開發(fā)介紹

?：?4.測試驅(qū)動開發(fā)的過程

?：?1）明確當(dāng)前要完成的功能?？梢杂涗洺梢粋€TODO列表。

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

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

。4）編寫對應(yīng)的功能代碼。

。5）測試通過。

。6）對代碼進行重構(gòu)，并保證測試通過。

。7）循環(huán)完成所有功能的開發(fā)。

可參考《測試驅(qū)動開發(fā)》第175頁

1.測試驅(qū)動開發(fā)介紹

?5.原則)

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

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

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

開發(fā)功能代碼、對代碼重構(gòu)等。做不同的事，承擔(dān)不同的角色。開發(fā)人員完成

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

細(xì)節(jié)，保證頭上只有一頂帽子。避免考慮無關(guān)細(xì)節(jié)過多，無謂地增加復(fù)雜度。

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

時，把相關(guān)功能點加到測試列表中，然后繼續(xù)手頭工作。然后不斷的完成對應(yīng)；

的測試用例、功能代碼、重構(gòu)。一是避免疏漏，也避免干擾當(dāng)前進行的工作。

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

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

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

句，然后編寫相應(yīng)的輔助語句。

1.測試驅(qū)動開發(fā)介紹

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

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

于接口等。

(7)及時重構(gòu)。無論是功能代碼還是測試代碼，對結(jié)構(gòu)不合理，重復(fù)的代碼等

情況，在測試通過后，及時進行重構(gòu)。

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

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

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

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

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

構(gòu)的循環(huán)。通過分解降低整個系統(tǒng)開發(fā)的復(fù)雜性。這樣的效果非常明顯。幾個小

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

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

看到?jīng)]有兒人啦。你甚至?xí)檫@個速度感到震驚。(我理解，是大幅度減少調(diào)

試、出錯的時間產(chǎn)生的這種速度感)

1.測試驅(qū)動開發(fā)介紹

?6.測試范圍、粒度

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

師KentBenk的話，對那些你認(rèn)為應(yīng)該測試的代碼進行測試。就是說，要相信自己的感覺，；

O感到疲勞就應(yīng)該停下來休息

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

測試驅(qū)動開發(fā)強調(diào)測試并不應(yīng)該是負(fù)擔(dān)，而應(yīng)該是幫助我們減輕工作量的方法。而對于何

時停止編寫測試用例，也是應(yīng)該根烤你的經(jīng)驗，功能復(fù)雜、核心功能的代碼就應(yīng)該編寫更

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

測試范圍沒有靜查的標(biāo)準(zhǔn)，同時也應(yīng)該可以隨著時間改變。對于開始沒有編寫足夠的測試

的功能代碼，朗著bug的出現(xiàn)，根據(jù)bug補齊相關(guān)的測試用例即可。

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

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

的測試和開發(fā)。那么是不是每個小類或者小函數(shù)都應(yīng)該測試哪？我認(rèn)為沒有必要。你應(yīng)該

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

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

1.測試驅(qū)動開發(fā)介紹

。7.怎么編寫測試用例

Y測試用例的編寫就用上了傳統(tǒng)的測試技術(shù)。

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

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

9測試數(shù)據(jù)盡量包括：真實數(shù)據(jù)、邊界數(shù)據(jù)。

9測試語句和測試數(shù)據(jù)應(yīng)該盡量簡單，容易理解。

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

Object)。

《如果內(nèi)部狀態(tài)非常復(fù)雜或者應(yīng)該判斷流程而不是狀態(tài)，可以通過記錄日志字

符串的方式進行驗證。

2.單元測試

?1.概述

i單元測試的目標(biāo):確保模塊被正確地編碼。

力由誰去做:通常由開發(fā)人員執(zhí)行。

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

測試可用白盒測試方法。

小什么時候停止:當(dāng)開發(fā)人員感到代碼沒有缺陷時。

2.單元測試

2.單元測試的重要性

《一個盡責(zé)的單元測試方法將會在產(chǎn)品開發(fā)的某個階段發(fā)現(xiàn)很多的Bug,

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

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

耗大量的時間和開發(fā)費用。

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

早的對產(chǎn)品代碼進行測試將是效率和質(zhì)量得到最好的保證。

力在提供了經(jīng)過單元測試的情況下，系統(tǒng)集成過程將會大大的簡化。

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

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

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

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

還有適當(dāng)?shù)氖褂煤霉ぞ邅碇С譁y試過程。

2.單元測試

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

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

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

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

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

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

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

進步。

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

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

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

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

任何事情。?

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

設(shè)土的錯誤。

4因此，高質(zhì)量的單元測試需要高質(zhì)量的詳細(xì)設(shè)計文檔。

2.單元測試

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

工每個人都可能犯錯誤。

4真正的完整的系統(tǒng)往往是非常復(fù)雜的，不能寄希望于沒有進行廣泛

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

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

工系統(tǒng)規(guī)模愈來愈大，復(fù)雜度愈來愈高，沒有單元測試，開發(fā)人員很

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

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

工在系統(tǒng)集成階段，對單元功能全面測試的負(fù)載程度遠(yuǎn)遠(yuǎn)的超過獨立

進行的單元測試過程。

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

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

2.單元測試

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

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

歸測試。

在生命周期中盡早的對產(chǎn)品進行測試將使

越早測試付出代價就越低

效率和質(zhì)量得到最好的保證

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

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

成本

相比后階段的測試，單元測試的創(chuàng)建更簡

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

重復(fù)。開發(fā)部署

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

日持久的集成測試，或是不穩(wěn)定的系統(tǒng)，到正費/p>

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

2.單元測試

?4.單元測試的策略

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

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

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

。1）哪些是重點模塊？

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

。3）哪些程序是相對獨立，應(yīng)當(dāng)提前測試的？

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

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

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

后還會經(jīng)常出錯，這種應(yīng)該列入測試重點。

2,單元測試

?5.測試用例的設(shè)計

?：?單元測試的核心是測試用例的設(shè)計，測試用例的核心是測試

數(shù)據(jù)的設(shè)計。

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

。(1)功能。我們?yōu)榱蓑炞C一個函數(shù)是否實現(xiàn)了它的功能，

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

因果圖，關(guān)于黑盒測試方法的詳細(xì)介紹，參見《測試用例設(shè)

計白皮書.doc》。

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

判定覆蓋、條件覆蓋、條件判定組合覆蓋，關(guān)于白盒測試的

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

2,單元測試

*6,TDD與單元測試的區(qū)別

TDD是一種設(shè)計手段，而不僅僅是測試手段。

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

事”。TDD其實并不是單純強調(diào)測試，它首

先是需求分析和設(shè)計技術(shù)。

3.測試工具

?1.概述

。為了完成測試驅(qū)動開發(fā)以及單元測試，我們

需要相應(yīng)的工具。

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

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

3.測試工具

?2.NUnit介紹

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

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

現(xiàn)在的版本是248.

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

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

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

T.J

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

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

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

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

3.測試工具

?3.NUnit的安裝

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

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

NUNIT：www.nunit.org

NUNITADDIN：

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

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

件。

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

3.測試工具

?4.如何在項目中應(yīng)用NUnit

參見《NUnit2.0詳細(xì)使用方法.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詳細(xì)使用方法.doc》第5頁

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

3.測試工具

6.NUrdt的各種斷言

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

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

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

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

在二個值不一