詳解設計測試驅動開發(fā)TDD技術總體流程
我們談到的TDD技術主要是從設計的角度談起，對于測試的全過程進行分析與總結，希望通過本文能對大家有所幫助。
測試驅動開發(fā)(TDD)是極限編程的重要特點，它以不斷的測試推動代碼的開發(fā)，既簡化了代碼，又保證了軟件質量。本文從開發(fā)人員使用的角度，介紹了TDD技術優(yōu)勢、原理、過程、原則、測試技術、Tips 等方面。
背景
一個高效的軟件開發(fā)過程對軟件開發(fā)人員來說是至關重要的，決定著開發(fā)是痛苦的掙扎，還是不斷進步的喜悅。國人對軟件藍領的不屑，對繁瑣冗長的傳統(tǒng)開發(fā)過程的不耐，使大多數(shù)開發(fā)人員無所適從。最近興起的一些軟件開發(fā)過程相關的技術，提供一些比較高效、實用的軟件過程開發(fā)方法。其中比較基礎、關鍵的一個技術就是測試驅動開發(fā)（Test-Driven Development）。雖然TDD光大于極限編程，但測試驅動開發(fā)完全可以單獨應用。下面就從開發(fā)人員使用的角度進行介紹，使開發(fā)人員用最少的代價盡快理解、掌握、應用這種技術。下面分優(yōu)勢，原理，過程，原則，測試技術，Tips等方面進行討論。
1. 優(yōu)勢
TDD技術的基本思路就是通過測試來推動整個開發(fā)的進行。而測試驅動開發(fā)技術并不只是單純的測試工作。
需求向來就是軟件開發(fā)過程中感覺最不好明確描述、易變的東西。這里說的需求不只是指用戶的需求，還包括對代碼的使用需求。很多開發(fā)人員最害怕的就是后期還要修改某個類或者函數(shù)的接口進行修改或者擴展，為什么會發(fā)生這樣的事情就是因為這部分代碼的使用需求沒有很好的描述。測試驅動開發(fā)就是通過編寫測試用例，先考慮代碼的使用需求（包括功能、過程、接口等），而且這個描述是無二義的，可執(zhí)行驗證的。
通過編寫這部分代碼的測試用例，對其功能的分解、使用過程、接口都進行了設計。而且這種從使用角度對代碼的設計通常更符合后期開發(fā)的需求?？蓽y試的要求，對代碼的內聚性的提高和復用都非常有益。因此測試驅動開發(fā)也是一種代碼設計的過程。
開發(fā)人員通常對編寫文檔非常厭煩，但要使用、理解別人的代碼時通常又希望能有文檔進行指導。而測試驅動開發(fā)過程中產(chǎn)生的測試用例代碼就是對代碼的最好的解釋。
快樂工作的基礎就是對自己有信心，對自己的工作成果有信心。當前很多開發(fā)人員卻經(jīng)常在擔心：“代碼是否正確？”“辛苦編寫的代碼還有沒有嚴重bug？”“修改的新代碼對其他部分有沒有影響？”。這種擔心甚至導致某些代碼應該修改卻不敢修改的地步。測試驅動開發(fā)提供的測試集就可以作為你信心的來源。
當然測試驅動開發(fā)最重要的功能還在于保障代碼的正確性，能夠迅速發(fā)現(xiàn)、定位bug。而迅速發(fā)現(xiàn)、定位bug是很多開發(fā)人員的夢想。針對關鍵代碼的測試集，以及不斷完善的測試用例，為迅速發(fā)現(xiàn)、定位bug提供了條件。
我的一段功能非常復雜的代碼使用TDD開發(fā)完成，真實環(huán)境應用中只發(fā)現(xiàn)幾個bug，而且很快被定位解決。您在應用后，也一定會為那種自信的開發(fā)過程，功能不斷增加、完善的感覺，迅速發(fā)現(xiàn)、定位bug的能力所感染，喜歡這個技術的。
那么是什么樣的原理、方法提供上面說的這些好處哪？下面我們就看看TDD的原理。
2. 原理
測試驅動開發(fā)的基本思想就是在開發(fā)功能代碼之前，先編寫測試代碼。也就是說在明確要開發(fā)某個功能后，首先思考如何對這個功能進行測試，并完成測試代碼的編寫，然后編寫相關的代碼滿足這些測試用例。然后循環(huán)進行添加其他功能，直到完全部功能的開發(fā)。
我們這里把這個技術的應用領域從代碼編寫擴展到整個開發(fā)過程。應該對整個開發(fā)過程的各個階段進行測試驅動，首先思考如何對這個階段進行測試、驗證、考核，并編寫相關的測試文檔，然后開始下一步工作，最后再驗證相關的工作。下圖是一個比較流行的測試模型：V測試模型。
【圖 V測試模型】
在開發(fā)的各個階段，包括需求分析、概要設計、詳細設計、編碼過程中都應該考慮相對應的測試工作，完成相關的測試用例的設計、測試方案、測試計劃的編寫。這里提到的開發(fā)階段只是舉例，根據(jù)實際的開發(fā)活動進行調整。相關的測試文檔也不一定是非常詳細復雜的文檔，或者什么形式，但應該養(yǎng)成測試驅動的習慣。
關于測試模型，還有X測試模型。這個測試模型，我認為，是對詳細階段和編碼階段進行建模，應該說更詳細的描述了詳細設計和編碼階段的開發(fā)行為。及針對某個功能進行對應的測試驅動開發(fā)。
【圖 X測試模型】
基本原理應該說非常簡單，那么如何進行實際操作哪，下面對開發(fā)過程進行詳細的介紹。
軟件開發(fā)其他階段的測試驅動開發(fā)，根據(jù)測試驅動開發(fā)的思想完成對應的測試文檔即可。下面針對詳細設計和編碼階段進行介紹。
測試驅動開發(fā)的基本過程如下：
1） 明確當前要完成的功能。可以記錄成一個 TODO 列表。
2） 快速完成針對此功能的測試用例編寫。
3） 測試代碼編譯不通過。
4） 編寫對應的功能代碼。
5） 測試通過。
6） 對代碼進行重構，并保證測試通過。
7） 循環(huán)完成所有功能的開發(fā)。
為了保證整個測試過程比較快捷、方便，通?？梢允褂脺y試框架組織所有的測試用例。一個免費的、優(yōu)秀的測試框架是 Xunit 系列，幾乎所有的語言都有對應的測試框架。我曾經(jīng)寫過一篇文章介紹CppUnit的文章（ http://www.ibm.com/developerworks/cn/linux/l-cppunit/index.html）。
開發(fā)過程中，通常把測試代碼和功能代碼分開存放，這里提供一個簡單的測試框架使用例子，您可以通過它了解測試框架的使用。下面是文件列表。
- project/ 項目主目錄
- project/test 測試項目主目錄
- project/test/testSeq.cpp 測試seq_t 的測試文件，對其他功能文件的測試文件復制后修改即可
- project/test/testSeq.h
- project/test/Makefile 測試項目的 Makefile
- project/test/main.cpp 測試項目的主文件，不需要修改
- project/main.cpp 項目的主文件
- project/seq_t.h 功能代碼，被測試文件
- project/Makefile 項目的 Makefile
主要流程基本如此，但要讓你的代碼很容易的進行測試，全面又不繁瑣的進行測試，還是有很多測試原則和技術需要考慮。
4. 原則
測試隔離。不同代碼的測試應該相互隔離。對一塊代碼的測試只考慮此代碼的測試，不要考慮其實現(xiàn)細節(jié)（比如它使用了其他類的邊界條件）。
一頂帽子。開發(fā)人員開發(fā)過程中要做不同的工作，比如：編寫測試代碼、開發(fā)功能代碼、對代碼重構等。做不同的事，承擔不同的角色。開發(fā)人員完成對應的工作時應該保持注意力集中在當前工作上，而不要過多的考慮其他方面的細節(jié)，保證頭上只有一頂帽子。避免考慮無關細節(jié)過多，無謂地增加復雜度。
測試列表。需要測試的功能點很多。應該在任何階段想添加功能需求問題時，把相關功能點加到測試列表中，然后繼續(xù)手頭工作。然后不斷的完成對應的測試用例、功能代碼、重構。一是避免疏漏，也避免干擾當前進行的工作。
測試驅動。這個比較核心。完成某個功能，某個類，首先編寫測試代碼，考慮其如何使用、如何測試。然后在對其進行設計、編碼。
先寫斷言。測試代碼編寫時，應該首先編寫對功能代碼的判斷用的斷言語句，然后編寫相應的輔助語句。
可測試性。功能代碼設計、開發(fā)時應該具有較強的可測試性。其實遵循比較好的設計原則的代碼都具備較好的測試性。比如比較高的內聚性，盡量依賴于接口等。
及時重構。無論是功能代碼還是測試代碼，對結構不合理，重復的代碼等情況，在測試通過后，及時進行重構。關于重構，我會另撰文詳細分析。
小步前進。軟件開發(fā)是個復雜性非常高的工作，開發(fā)過程中要考慮很多東西，包括代碼的正確性、可擴展性、性能等等，很多問題都是因為復雜性太大導致的。極限編程提出了一個非常好的思路就是小步前進。把所有的規(guī)模大、復雜性高的工作，分解成小的任務來完成。對于一個類來說，一個功能一個功能的完成，如果太困難就再分解。每個功能的完成就走測試代碼－功能代碼－測試－重構的循環(huán)。通過分解降低整個系統(tǒng)開發(fā)的復雜性。這樣的效果非常明顯。幾個小的功能代碼完成后，大的功能代碼幾乎是不用調試就可以通過。一個個類方法的實現(xiàn)，很快就看到整個類很快就完成啦。本來感覺很多特性需要增加，很快就會看到?jīng)]有幾個啦。你甚至會為這個速度感到震驚。（我理解，是大幅度減少調試、出錯的時間產(chǎn)生的這種速度感）
5. 測試技術
5.1. 測試范圍、粒度
對哪些功能進行測試？會不會太繁瑣？什么時候可以停止測試？這些問題比較常見。按大師 Kent Benk 的話，對那些你認為應該測試的代碼進行測試。就是說，要相信自己的感覺，自己的經(jīng)驗。那些重要的功能、核心的代碼就應該重點測試。感到疲勞就應該停下來休息一下。感覺沒有必要更詳細的測試，就停止本輪測試。
測試驅動開發(fā)強調測試并不應該是負擔，而應該是幫助我們減輕工作量的方法。而對于何時停止編寫測試用例，也是應該根據(jù)你的經(jīng)驗，功能復雜、核心功能的代碼就應該編寫更全面、細致的測試用例，否則測試流程即可。
測試范圍沒有靜態(tài)的標準，同時也應該可以隨著時間改變。對于開始沒有編寫足夠的測試的功能代碼，隨著bug的出現(xiàn)，根據(jù)bug補齊相關的測試用例即可。
小步前進的原則，要求我們對大的功能塊測試時，應該先分拆成更小的功能塊進行測試，比如一個類A使用了類B、C，就應該編寫到A使用B、C功能的測試代碼前，完成對B、C的測試和開發(fā)。那么是不是每個小類或者小函數(shù)都應該測試哪？我認為沒有必要。你應該運用你的經(jīng)驗，對那些可能出問題的地方重點測試，感覺不可能出問題的地方就等它真正出問題的時候再補測試吧。
5.2. 怎么編寫測試用例
測試用例的編寫就用上了傳統(tǒng)的測試技術。
◆操作過程盡量模擬正常使用的過程。
◆全面的測試用例應該盡量做到分支覆蓋，核心代碼盡量做到路徑覆蓋。
◆測試數(shù)據(jù)盡量包括：真實數(shù)據(jù)、邊界數(shù)據(jù)。
◆測試語句和測試數(shù)據(jù)應該盡量簡單，容易理解。
◆為了避免對其他代碼過多的依賴，可以實現(xiàn)簡單的樁函數(shù)或樁類（Mock Object）。
◆如果內部狀態(tài)非常復雜或者應該判斷流程而不是狀態(tài)，可以通過記錄日志字符串的方式進行驗證。
6. Tips
很多朋友有疑問，“測試代碼的正確性如何保障？是寫測試代碼還是寫測試文檔？”這樣是不是會陷入“雞生蛋，蛋生雞”的循環(huán)。其實是不會的。通常測試代碼通常是非常簡單的，通常圍繞著某個情況的正確性判斷的幾個語句，如果太復雜，就應該繼續(xù)分解啦。而傳統(tǒng)的開發(fā)過程通常強調測試文檔。但隨著開發(fā)節(jié)奏的加快，用戶需求的不斷變化，維護高層（需求、概要設計）的測試文檔可以，更低層的測試文檔的成本的確太大了。而且可實時驗證功能正確性的測試代碼就是對代碼最好的文檔。
軟件開發(fā)過程中，除了遵守上面提到的測試驅動開發(fā)的幾個原則外，一個需要注意的問題就是，謹防過度設計。編寫功能代碼時應該關注于完成當前功能點，通過測試，使用最簡單、直接的方式來編碼。過多的考慮后期的擴展，其他功能的添加，無疑增加了過多的復雜性，容易產(chǎn)生問題。應該等到要添加這些特性時在進行詳細的測試驅動開發(fā)。到時候，有整套測試用例做基礎，通過不斷重構很容易添加相關特性。
參考資料
◆推薦 Kent Beck 的書 Test-Driven Development: By Example ，中文版是《測試驅動開發(fā)》 http://www.china-pub.com/computers/common/info.asp?id=14701
◆免費、優(yōu)秀的測試框架 *unit 系列，包括： Junit http://www.junit.org CppUnit http://cppunit.sourceforge.net/
◆我曾經(jīng)寫的一篇介紹 CppUnit 使用的文章 《便利的開發(fā)工具CppUnit 快速使用指南》 http://www.ibm.com/developerworks/cn/linux/l-cppunit/index.html
◆介紹測試模型的文章 《This or That, V or X? 》 http://www.sdbestpractices.com/documents/s=8815/sdm0208e/ 中文翻譯見 《軟件測試：不可忽略的階段》 http://developer.ccidnet.com/pub/disp/Article?columnID=291&articleID=37924&pageNO=1 《軟件測試：V模型，還是X模型？》 http://developer.ccidnet.com/pub/disp/Article?columnID=291&articleID=37975&pageNO=1
◆《Unit Test 研究報告》 http://blog.aspcool.com/tim/posts/349.aspx
◆這里搜集了一些相關的文章 http://www.ihere.org/modules/newbb/viewforum.php?forum=10
原文標題：淺談測試驅動開發(fā)TDD技術
鏈接：http://www.cnblogs.com/yangguang82425/archive/2009/10/09/1579429.html
【編輯推薦】
