在 IBM Bluemix 云平臺(tái)上開發(fā)并部署您的下一個(gè)應(yīng)用,。

開始您的試用

背景

一個(gè)高效的軟件開發(fā)過程對(duì)軟件開發(fā)人員來說是至關(guān)重要的，決定著開發(fā)是痛苦的掙扎,，還是不斷進(jìn)步的喜悅。國人對(duì)軟件藍(lán)領(lǐng)的不屑,，對(duì)繁瑣冗長的傳統(tǒng)開發(fā)過程的不耐,，使大多數(shù)開發(fā)人員無所適從。最近興起的一些軟件開發(fā)過程相關(guān)的技術(shù),，提供一些比較高效,、實(shí)用的軟件過程開發(fā)方法。其中比較基礎(chǔ),、關(guān)鍵的一個(gè)技術(shù)就是測試驅(qū)動(dòng)開發(fā)（Test-Driven Development）,。雖然TDD光大于極限編程，但測試驅(qū)動(dòng)開發(fā)完全可以單獨(dú)應(yīng)用,。下面就從開發(fā)人員使用的角度進(jìn)行介紹,，使開發(fā)人員用最少的代價(jià)盡快理解、掌握,、應(yīng)用這種技術(shù),。下面分優(yōu)勢，原理,，過程,，原則，測試技術(shù),，Tips等方面進(jìn)行討論,。

回頁首

1. 優(yōu)勢

TDD的基本思路就是通過測試來推動(dòng)整個(gè)開發(fā)的進(jìn)行。而測試驅(qū)動(dòng)開發(fā)技術(shù)并不只是單純的測試工作,。

需求向來就是軟件開發(fā)過程中感覺最不好明確描述,、易變的東西。這里說的需求不只是指用戶的需求,，還包括對(duì)代碼的使用需求,。很多開發(fā)人員最害怕的就是后期還要修改某個(gè)類或者函數(shù)的接口進(jìn)行修改或者擴(kuò)展，為什么會(huì)發(fā)生這樣的事情就是因?yàn)檫@部分代碼的使用需求沒有很好的描述,。測試驅(qū)動(dòng)開發(fā)就是通過編寫測試用例,，先考慮代碼的使用需求（包括功能、過程,、接口等）,，而且這個(gè)描述是無二義的,，可執(zhí)行驗(yàn)證的。

通過編寫這部分代碼的測試用例,，對(duì)其功能的分解,、使用過程、接口都進(jìn)行了設(shè)計(jì),。而且這種從使用角度對(duì)代碼的設(shè)計(jì)通常更符合后期開發(fā)的需求,。可測試的要求,，對(duì)代碼的內(nèi)聚性的提高和復(fù)用都非常有益,。因此測試驅(qū)動(dòng)開發(fā)也是一種代碼設(shè)計(jì)的過程。

開發(fā)人員通常對(duì)編寫文檔非常厭煩,，但要使用,、理解別人的代碼時(shí)通常又希望能有文檔進(jìn)行指導(dǎo)。而測試驅(qū)動(dòng)開發(fā)過程中產(chǎn)生的測試用例代碼就是對(duì)代碼的最好的解釋,。

快樂工作的基礎(chǔ)就是對(duì)自己有信心,，對(duì)自己的工作成果有信心。當(dāng)前很多開發(fā)人員卻經(jīng)常在擔(dān)心：“代碼是否正確,？”“辛苦編寫的代碼還有沒有嚴(yán)重bug,？”“修改的新代碼對(duì)其他部分有沒有影響？”,。這種擔(dān)心甚至導(dǎo)致某些代碼應(yīng)該修改卻不敢修改的地步,。測試驅(qū)動(dòng)開發(fā)提供的測試集就可以作為你信心的來源。

當(dāng)然測試驅(qū)動(dòng)開發(fā)最重要的功能還在于保障代碼的正確性,，能夠迅速發(fā)現(xiàn),、定位bug。而迅速發(fā)現(xiàn),、定位bug是很多開發(fā)人員的夢想,。針對(duì)關(guān)鍵代碼的測試集，以及不斷完善的測試用例,，為迅速發(fā)現(xiàn),、定位bug提供了條件。

我的一段功能非常復(fù)雜的代碼使用TDD開發(fā)完成,，真實(shí)環(huán)境應(yīng)用中只發(fā)現(xiàn)幾個(gè)bug,，而且很快被定位解決。您在應(yīng)用后,，也一定會(huì)為那種自信的開發(fā)過程,，功能不斷增加、完善的感覺,，迅速發(fā)現(xiàn),、定位bug的能力所感染,，喜歡這個(gè)技術(shù)的。

那么是什么樣的原理,、方法提供上面說的這些好處哪,？下面我們就看看TDD的原理。

回頁首

2. 原理

測試驅(qū)動(dòng)開發(fā)的基本思想就是在開發(fā)功能代碼之前,，先編寫測試代碼,。也就是說在明確要開發(fā)某個(gè)功能后，首先思考如何對(duì)這個(gè)功能進(jìn)行測試,，并完成測試代碼的編寫,，然后編寫相關(guān)的代碼滿足這些測試用例。然后循環(huán)進(jìn)行添加其他功能,，直到完全部功能的開發(fā)。

我們這里把這個(gè)技術(shù)的應(yīng)用領(lǐng)域從代碼編寫擴(kuò)展到整個(gè)開發(fā)過程,。應(yīng)該對(duì)整個(gè)開發(fā)過程的各個(gè)階段進(jìn)行測試驅(qū)動(dòng),，首先思考如何對(duì)這個(gè)階段進(jìn)行測試、驗(yàn)證,、考核,，并編寫相關(guān)的測試文檔，然后開始下一步工作,，最后再驗(yàn)證相關(guān)的工作,。下圖是一個(gè)比較流行的測試模型：V測試模型。

【圖 V測試模型】

在開發(fā)的各個(gè)階段,，包括需求分析,、概要設(shè)計(jì)、詳細(xì)設(shè)計(jì),、編碼過程中都應(yīng)該考慮相對(duì)應(yīng)的測試工作,，完成相關(guān)的測試用例的設(shè)計(jì)、測試方案,、測試計(jì)劃的編寫,。這里提到的開發(fā)階段只是舉例，根據(jù)實(shí)際的開發(fā)活動(dòng)進(jìn)行調(diào)整,。相關(guān)的測試文檔也不一定是非常詳細(xì)復(fù)雜的文檔,，或者什么形式，但應(yīng)該養(yǎng)成測試驅(qū)動(dòng)的習(xí)慣,。

關(guān)于測試模型,，還有X測試模型。這個(gè)測試模型,，我認(rèn)為,，是對(duì)詳細(xì)階段和編碼階段進(jìn)行建模,，應(yīng)該說更詳細(xì)的描述了詳細(xì)設(shè)計(jì)和編碼階段的開發(fā)行為。及針對(duì)某個(gè)功能進(jìn)行對(duì)應(yīng)的測試驅(qū)動(dòng)開發(fā),。

【圖 X測試模型】

基本原理應(yīng)該說非常簡單,，那么如何進(jìn)行實(shí)際操作哪，下面對(duì)開發(fā)過程進(jìn)行詳細(xì)的介紹,。

回頁首

3. 過程

軟件開發(fā)其他階段的測試驅(qū)動(dòng)開發(fā),，根據(jù)測試驅(qū)動(dòng)開發(fā)的思想完成對(duì)應(yīng)的測試文檔即可。下面針對(duì)詳細(xì)設(shè)計(jì)和編碼階段進(jìn)行介紹,。

測試驅(qū)動(dòng)開發(fā)的基本過程如下：

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

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

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

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

5） 測試通過,。

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

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

為了保證整個(gè)測試過程比較快捷、方便,，通?？梢允褂脺y試框架組織所有的測試用例。一個(gè)免費(fèi)的,、優(yōu)秀的測試框架是 Xunit 系列,，幾乎所有的語言都有對(duì)應(yīng)的測試框架。我曾經(jīng)寫過一篇文章介紹CppUnit的文章（ http://www.ibm.com/developerworks/cn/linux/l-cppunit/index.html）,。

開發(fā)過程中,，通常把測試代碼和功能代碼分開存放，這里提供一個(gè)簡單的測試框架使用例子,，您可以通過它了解測試框架的使用,。下面是文件列表。

	project/				項(xiàng)目主目錄
	project/test			測試項(xiàng)目主目錄
	project/test/testSeq.cpp		測試seq_t 的測試文件,，對(duì)其他功能文件的測試文件復(fù)制后修改即可
	project/test/testSeq.h
	project/test/Makefile			測試項(xiàng)目的 Makefile 
	project/test/main.cpp			測試項(xiàng)目的主文件,，不需要修改
	project/main.cpp		           項(xiàng)目的主文件
	project/seq_t.h			功能代碼，被測試文件
	project/Makefile		           項(xiàng)目的 Makefile

主要流程基本如此,，但要讓你的代碼很容易的進(jìn)行測試,，全面又不繁瑣的進(jìn)行測試，還是有很多測試原則和技術(shù)需要考慮。

回頁首

4. 原則

測試隔離,。不同代碼的測試應(yīng)該相互隔離,。對(duì)一塊代碼的測試只考慮此代碼的測試，不要考慮其實(shí)現(xiàn)細(xì)節(jié)（比如它使用了其他類的邊界條件）,。

一頂帽子,。開發(fā)人員開發(fā)過程中要做不同的工作，比如：編寫測試代碼,、開發(fā)功能代碼,、對(duì)代碼重構(gòu)等。做不同的事,，承擔(dān)不同的角色,。開發(fā)人員完成對(duì)應(yīng)的工作時(shí)應(yīng)該保持注意力集中在當(dāng)前工作上，而不要過多的考慮其他方面的細(xì)節(jié),，保證頭上只有一頂帽子,。避免考慮無關(guān)細(xì)節(jié)過多，無謂地增加復(fù)雜度,。

測試列表,。需要測試的功能點(diǎn)很多。應(yīng)該在任何階段想添加功能需求問題時(shí),，把相關(guān)功能點(diǎn)加到測試列表中，然后繼續(xù)手頭工作,。然后不斷的完成對(duì)應(yīng)的測試用例,、功能代碼、重構(gòu),。一是避免疏漏,，也避免干擾當(dāng)前進(jìn)行的工作。

測試驅(qū)動(dòng),。這個(gè)比較核心,。完成某個(gè)功能，某個(gè)類,，首先編寫測試代碼,，考慮其如何使用、如何測試,。然后在對(duì)其進(jìn)行設(shè)計(jì),、編碼。

先寫斷言,。測試代碼編寫時(shí),，應(yīng)該首先編寫對(duì)功能代碼的判斷用的斷言語句，然后編寫相應(yīng)的輔助語句。

可測試性,。功能代碼設(shè)計(jì),、開發(fā)時(shí)應(yīng)該具有較強(qiáng)的可測試性。其實(shí)遵循比較好的設(shè)計(jì)原則的代碼都具備較好的測試性,。比如比較高的內(nèi)聚性,，盡量依賴于接口等。

及時(shí)重構(gòu),。無論是功能代碼還是測試代碼,，對(duì)結(jié)構(gòu)不合理，重復(fù)的代碼等情況,，在測試通過后,，及時(shí)進(jìn)行重構(gòu)。關(guān)于重構(gòu),，我會(huì)另撰文詳細(xì)分析,。

小步前進(jìn)。軟件開發(fā)是個(gè)復(fù)雜性非常高的工作,，開發(fā)過程中要考慮很多東西,，包括代碼的正確性、可擴(kuò)展性,、性能等等,，很多問題都是因?yàn)閺?fù)雜性太大導(dǎo)致的。極限編程提出了一個(gè)非常好的思路就是小步前進(jìn),。把所有的規(guī)模大,、復(fù)雜性高的工作，分解成小的任務(wù)來完成,。對(duì)于一個(gè)類來說,，一個(gè)功能一個(gè)功能的完成，如果太困難就再分解,。每個(gè)功能的完成就走測試代碼－功能代碼－測試－重構(gòu)的循環(huán),。通過分解降低整個(gè)系統(tǒng)開發(fā)的復(fù)雜性。這樣的效果非常明顯,。幾個(gè)小的功能代碼完成后,，大的功能代碼幾乎是不用調(diào)試就可以通過。一個(gè)個(gè)類方法的實(shí)現(xiàn),，很快就看到整個(gè)類很快就完成啦,。本來感覺很多特性需要增加，很快就會(huì)看到?jīng)]有幾個(gè)啦,。你甚至?xí)檫@個(gè)速度感到震驚,。（我理解，是大幅度減少調(diào)試、出錯(cuò)的時(shí)間產(chǎn)生的這種速度感）

回頁首

5. 測試技術(shù)

5.1. 測試范圍,、粒度

對(duì)哪些功能進(jìn)行測試,？會(huì)不會(huì)太繁瑣？什么時(shí)候可以停止測試,？這些問題比較常見,。按大師 Kent Benk 的話，對(duì)那些你認(rèn)為應(yīng)該測試的代碼進(jìn)行測試,。就是說,，要相信自己的感覺，自己的經(jīng)驗(yàn),。那些重要的功能,、核心的代碼就應(yīng)該重點(diǎn)測試。感到疲勞就應(yīng)該停下來休息一下,。感覺沒有必要更詳細(xì)的測試,，就停止本輪測試。

測試驅(qū)動(dòng)開發(fā)強(qiáng)調(diào)測試并不應(yīng)該是負(fù)擔(dān),，而應(yīng)該是幫助我們減輕工作量的方法,。而對(duì)于何時(shí)停止編寫測試用例，也是應(yīng)該根據(jù)你的經(jīng)驗(yàn),，功能復(fù)雜,、核心功能的代碼就應(yīng)該編寫更全面、細(xì)致的測試用例,，否則測試流程即可,。

測試范圍沒有靜態(tài)的標(biāo)準(zhǔn)，同時(shí)也應(yīng)該可以隨著時(shí)間改變,。對(duì)于開始沒有編寫足夠的測試的功能代碼，隨著bug的出現(xiàn),，根據(jù)bug補(bǔ)齊相關(guān)的測試用例即可,。

小步前進(jìn)的原則，要求我們對(duì)大的功能塊測試時(shí),，應(yīng)該先分拆成更小的功能塊進(jìn)行測試,，比如一個(gè)類A使用了類B、C,，就應(yīng)該編寫到A使用B,、C功能的測試代碼前，完成對(duì)B,、C的測試和開發(fā),。那么是不是每個(gè)小類或者小函數(shù)都應(yīng)該測試哪？我認(rèn)為沒有必要。你應(yīng)該運(yùn)用你的經(jīng)驗(yàn),，對(duì)那些可能出問題的地方重點(diǎn)測試,，感覺不可能出問題的地方就等它真正出問題的時(shí)候再補(bǔ)測試吧。

5.2. 怎么編寫測試用例

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

• 操作過程盡量模擬正常使用的過程,。
• 全面的測試用例應(yīng)該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋,。
• 測試數(shù)據(jù)盡量包括：真實(shí)數(shù)據(jù),、邊界數(shù)據(jù)。
• 測試語句和測試數(shù)據(jù)應(yīng)該盡量簡單,，容易理解,。
• 為了避免對(duì)其他代碼過多的依賴，可以實(shí)現(xiàn)簡單的樁函數(shù)或樁類（Mock Object）,。
• 如果內(nèi)部狀態(tài)非常復(fù)雜或者應(yīng)該判斷流程而不是狀態(tài),，可以通過記錄日志字符串的方式進(jìn)行驗(yàn)證。

回頁首

6. Tips

很多朋友有疑問,，“測試代碼的正確性如何保障,？是寫測試代碼還是寫測試文檔？”這樣是不是會(huì)陷入“雞生蛋,，蛋生雞”的循環(huán),。其實(shí)是不會(huì)的。通常測試代碼通常是非常簡單的,，通常圍繞著某個(gè)情況的正確性判斷的幾個(gè)語句,，如果太復(fù)雜，就應(yīng)該繼續(xù)分解啦,。而傳統(tǒng)的開發(fā)過程通常強(qiáng)調(diào)測試文檔,。但隨著開發(fā)節(jié)奏的加快，用戶需求的不斷變化,，維護(hù)高層（需求,、概要設(shè)計(jì)）的測試文檔可以，更低層的測試文檔的成本的確太大了,。而且可實(shí)時(shí)驗(yàn)證功能正確性的測試代碼就是對(duì)代碼最好的文檔,。

軟件開發(fā)過程中，除了遵守上面提到的測試驅(qū)動(dòng)開發(fā)的幾個(gè)原則外,，一個(gè)需要注意的問題就是,，謹(jǐn)防過度設(shè)計(jì)。編寫功能代碼時(shí)應(yīng)該關(guān)注于完成當(dāng)前功能點(diǎn),，通過測試,，使用最簡單,、直接的方式來編碼。過多的考慮后期的擴(kuò)展,，其他功能的添加,，無疑增加了過多的復(fù)雜性，容易產(chǎn)生問題,。應(yīng)該等到要添加這些特性時(shí)在進(jìn)行詳細(xì)的測試驅(qū)動(dòng)開發(fā),。到時(shí)候，有整套測試用例做基礎(chǔ),，通過不斷重構(gòu)很容易添加相關(guān)特性,。