測(cè)試驅(qū)動(dòng)開發(fā)課件

測(cè)試驅(qū)動(dòng)開發(fā)

.

1

大綱

.測(cè)試驅(qū)動(dòng)開發(fā)介紹

2.單元測(cè)試

?3.測(cè)試工具

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

1.背景

測(cè)試驅(qū)動(dòng)開發(fā)(TestDrivenDevelopment,英文縮寫

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

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

開發(fā)某個(gè)功能后，首先思考如何對(duì)這個(gè)功能進(jìn)行測(cè)試，并完

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

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

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

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

以單獨(dú)應(yīng)用。

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

2.極限編程

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

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

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

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

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

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

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

程。

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

?：?3.測(cè)試驅(qū)動(dòng)開發(fā)的優(yōu)點(diǎn))

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

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

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

bug提供了條件。

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

計(jì)。而且這種從使用角度對(duì)代碼的設(shè)計(jì)通常更符合后期開發(fā)的需求。可測(cè)試的要

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

設(shè)計(jì)的過程。(

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

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

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

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

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

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

元測(cè)試代碼很容易讀跟寫，因?yàn)闇y(cè)試代碼里面沒有多余的數(shù)據(jù)。如果我

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

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

。（5）因?yàn)閺V泛的使用接口，我們的類之間就不會(huì)藕合，因此重用性更

好。

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

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

?：?4.測(cè)試驅(qū)動(dòng)開發(fā)的過程

?：?1）明確當(dāng)前要完成的功能。可以記錄成一個(gè)TODO列表。

。2）快速完成針對(duì)此功能的測(cè)試用例編寫。

。3）測(cè)試代碼編譯不通過。

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

。5）測(cè)試通過。

。6）對(duì)代碼進(jìn)行重構(gòu)，并保證測(cè)試通過。

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

?5.原則)

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

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

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

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

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

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

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

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

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

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

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

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

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

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

于接口等。

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

情況，在測(cè)試通過后，及時(shí)進(jìn)行重構(gòu)。

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

西，包括代碼的正確任、可擴(kuò)展性、性能等等，很多問題都是因?yàn)閺?fù)雜性太大尋日

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

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

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

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

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

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

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

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

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

?6.測(cè)試范圍、粒度

對(duì)哪些功能進(jìn)行測(cè)試？會(huì)不會(huì)太繁瑣？什么時(shí)候可以停止測(cè)試？這些問題比較常見。按大

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

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

一下。囑贏梭嚕鰥僵髓點(diǎn)測(cè)試。

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

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

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

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

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

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

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

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

運(yùn)用你的經(jīng)物驗(yàn),，對(duì)那些可能出問題的地方重點(diǎn)測(cè)試，感覺不可能出問題的地方就等它真正

出問題的時(shí)族再補(bǔ)測(cè)試吧。

1.測(cè)試驅(qū)動(dòng)開發(fā)介紹

。7.怎么編寫測(cè)試用例

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

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

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

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

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

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

Object)。

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

符串的方式進(jìn)行驗(yàn)證。

2.單元測(cè)試

?1.概述

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

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

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

測(cè)試可用白盒測(cè)試方法。

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

2.單元測(cè)試

2.單元測(cè)試的重要性

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

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

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

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

力無論什么時(shí)候做出修改都要進(jìn)行完整的回歸測(cè)試，在生命周期中盡

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

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

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

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

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

這包含了完全的單元測(cè)試的概念，以及對(duì)測(cè)試過程的良好的管理，

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

2.單元測(cè)試

3.為什么要進(jìn)行單元測(cè)試

(1)單元測(cè)試是不是太浪費(fèi)時(shí)間了？

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

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

』編寫完整計(jì)劃的單元測(cè)試和編寫實(shí)際的代碼所花費(fèi)的精力大致相同。但是，一旦

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

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

進(jìn)步。

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

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

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

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

任何事情。?

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

設(shè)土的錯(cuò)誤。

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

2.單元測(cè)試

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

工每個(gè)人都可能犯錯(cuò)誤。

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

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

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

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

可能會(huì)花費(fèi)大量的時(shí)間僅僅是為了使該系統(tǒng)能夠運(yùn)行。

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

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

進(jìn)行的單元測(cè)試過程。

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

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

2.單元測(cè)試

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

無論什么時(shí)候做出修改都要進(jìn)行完整的回

歸測(cè)試。

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

越早測(cè)試付出代價(jià)就越低

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

Bug修改越晚，費(fèi)用就越高，單元測(cè)試是

一個(gè)在早期抓住Bug的機(jī)會(huì)。

成本

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

單，維護(hù)更容易，并且可以更方便的進(jìn)行

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

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

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

單元測(cè)試所需的費(fèi)用是最低的。

2.單元測(cè)試

?4.單元測(cè)試的策略

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

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

。以下是單元測(cè)試常采用的策略：

。1）哪些是重點(diǎn)模塊？

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

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

。4）哪些程序最容易擴(kuò)散錯(cuò)誤？

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

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

后還會(huì)經(jīng)常出錯(cuò)，這種應(yīng)該列入測(cè)試重點(diǎn)。

2,單元測(cè)試

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

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

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

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

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

通常采用黑盒測(cè)試的方法。常用的方法有邊界值、等價(jià)類、

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

計(jì)白皮書.doc》。

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

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

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

2,單元測(cè)試

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

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

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

事”。TDD其實(shí)并不是單純強(qiáng)調(diào)測(cè)試，它首

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

3.測(cè)試工具

?1.概述

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

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

?針對(duì)C++的單元測(cè)試工具是CppUnit

針對(duì)c#的單元測(cè)試工具是NUnit

3.測(cè)試工具

?2.NUnit介紹

。NUM是一個(gè)單元測(cè)試框架，專門針對(duì)于.NET來寫的.其實(shí)在前面有

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

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

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

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

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

T.J

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

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

。最重要的一點(diǎn)是它適合于所有.NET語言.

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

3.測(cè)試工具

?3.NUnit的安裝

免費(fèi)，開源的單元測(cè)試軟件。

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

NUNIT：www.nunit.org

NUNITADDIN：

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

VisualStudio2005的一個(gè)用來集成Nunit單元測(cè)試工具的插

件。

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

3.測(cè)試工具

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

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

3.測(cè)試工具

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.測(cè)試工具

6.NUrdt的各種斷言

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

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

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

Expected是被測(cè)試代碼的期望值，actual是被測(cè)試代碼的實(shí)際值，message是一個(gè)可選的消息,

在二個(gè)值不一