溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

測試驅(qū)動開發(fā)(Test-Driven Development)

發(fā)布時間:2020-07-26 17:43:27 來源:網(wǎng)絡 閱讀:492 作者:lj5635906 欄目:軟件技術(shù)

1背景

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

 

 

2優(yōu)勢

2.1 先編寫測試代碼

測試驅(qū)動開發(fā)的基本思想就是在開發(fā)功能代碼之前,先編寫測試代碼。

2.2 先考慮代碼的使用需求

測試驅(qū)動開發(fā)就是通過編寫測試用例,先考慮代碼的使用需求(包括功能、過程、接口等),而且這個描述是無二義的,可執(zhí)行驗證的。

2.3 分解功能

通過編寫這部分代碼的測試用例,對其功能的分解、使用過程、接口都進行了設計。

2.4 測試代碼即是文檔

要使用、理解別人的代碼時通常又希望能有文檔進行指導,而測試驅(qū)動開發(fā)過程中產(chǎn)生的測試用例代碼就是對代碼的最好的解釋。

2.5 正確性->信心

代碼是否正確?”“辛苦編寫的代碼還有沒有嚴重bug”“修改的新代碼對其他部分有沒有影響?測試驅(qū)動開發(fā)提供的測試集就可以作為你信心的來源。

2.6 迅速定位bug

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

 

 

 

3 . 原理

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

 

3.1 V測試模型

測試驅(qū)動開發(fā)(Test-Driven Development)

3.2 X測試模型

測試驅(qū)動開發(fā)(Test-Driven Development)

4 . 過程

軟件開發(fā)其他階段的測試驅(qū)動開發(fā),根據(jù)測試驅(qū)動開發(fā)的思想完成對應的測試文檔即可。

1明確當前要完成的功能??梢杂涗洺梢粋€ TODO 列表。

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

3測試代碼編譯不通過。

4編寫對應的功能代碼。

5測試通過。

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

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

 

 

5 . 原則

5.1 測試隔離

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

5.2 一頂帽子

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

5.3 測試列表

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

5.4 測試驅(qū)動

這個比較核心。完成某個功能,某個類,首先編寫測試代碼,考慮其如何使用、如何測試。然后在對其進行設計、編碼。

5.5 先寫斷言

測試代碼編寫時,應該首先編寫對功能代碼的判斷用的斷言語句,然后編寫相應的輔助語句。

5.6 可測試性

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

5.7 及時重構(gòu)

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

5.8 小步前進

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

 

6 . 測試技術(shù)

6.1 測試范圍、粒度

對那些你認為應該測試的代碼進行測試。就是說,要相信自己的感覺,自己的經(jīng)驗。那些重要的功能、核心的代碼就應該重點測試。感到疲勞就應該停下來休息一下。感覺沒有必要更詳細的測試,就停止本輪測試。

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

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

小步前進的原則,要求我們對大的功能塊測試時,應該先分拆成更小的功能塊進行測試,比如一個類A使用了類B、C,就應該編寫到A使用B、C功能的測試代碼前,完成對BC的測試和開發(fā)。

 

6.2 怎么編寫測試用例

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

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

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

4)測試語句和測試數(shù)據(jù)應該盡量簡單,容易理解。

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

6)如果內(nèi)部狀態(tài)非常復雜或者應該判斷流程而不是狀態(tài),可以通過記錄日志字符串的方式進行驗證。

 

7 . Tips

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

 


向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI