iT邦幫忙

7

TDD(Test-Driven Development,測試驅動開發)的幾個想法

swift 2011-11-03 09:01:2531994 瀏覽

原先我對TDD並沒有太多的了解。原因之一,這是Aglie(敏捷開發)方法論的一環,而目前我所經歷的專案與團隊並沒有使用敏捷開發;之二,對於TDD,我一直以為就等於是Unit Testing,只是把寫Unit Testing Code的時間從寫程式本文後提前至寫程式本文前,就這麼簡單。事實上不然,TDD不單單指的是Unit Testing,事實上也可以用來進行後端的模組測試、整合測試等等。但TDD強調的不是"測試"這件事情,而是"開發"這件事情。為了要做好開發,所以先寫好測試程式,這對於某些想改變軟體品質的主管或是專案經理來說,看起來好像是個不小的誘惑,但真的做起來,這那麼簡單嗎?
最近幾天看了一些講TDD觀念與執行心得的文章,歸納了幾個想法,順便整理一下跟大家分享:

一、要導入TDD,軟體的需求必須明確,才有辦法讓測試程式碼開發先行,事實上Agile開發方法論強調的是應變需求的速度加快,但無法應付變化頻率太高或是變化幅度太大的軟體需求(以Scrum來說,一個衝刺周期建議是一個月,當然還是要看個別專案而定,但原則上不會偏離太大)。測試就是在測程式的"功能",這可能小到是一支程式裡面的其中一個Function,抑或是大到系統中使用者會使用到的所有功能,若是軟體需求一直變更,變更幅度又非常大,連開發原來功能都來不及了,怎麼還會有時間來修改測試程式碼呢?

二、網路上看到有人說使用TDD,軟體開發的時間被拉長為原來的1.5~1.8倍,聽起來主管及PM的心臟要夠強,尤其在初期導入TDD的時候,往往會因為專案時程的壓力,把TDD三定律先拋在腦後,那TDD的導入註定要失敗。

(TDD三定律:(1)沒有測試之前不要寫任何功能代碼;(2)只編寫恰好能夠體現一個失敗情況的測試代碼;(3)只編寫恰好能通過測試的功能代碼)

三、在軟體開發工作中,我們常常會碰到,卻很少在文章討論中提到的,是所謂"工作交接"的問題。開發人員來來去去,人員異動,調動專案配合人員,常常在發生,一個交接不好,往往就變成了"歷史的懸案",功能原來是好的,某天突然不能用,維護的工程師搞不清楚動了哪裡變成這樣。如果TDD有落實,可以避免類似的情形發生。當然,前提是要有落實。

四、TDD代表的另一層含義,叫做"自動化測試"。這又是一塊誘人的大餅,的確可以軟體開發在測試的成本上面大大地降低。不過,TDD本質上是屬於白箱測試,一般站在軟體品保的立場,還是會建議進行黑箱測試來找出原本未預期的問題。尤其當需要進行使用者介面的測試,如GUI,Web-Based操作等等系統測試,就不合適以TDD的方式來進行。就如同我前面所說的,TDD主要目的是協助開發,而非協助測試。

五、有人說施行了TDD,測試人員就不需要了,我倒不這麼認為,理由有下列三點:
1.測試人員在專案組織中多半也負責了軟體品保的其他工作,追蹤Defect/Issue處理進度,收集、協調、討論溝通問題,同時扮演第三方的角色來客觀監督審查專案的品質,甚至還可以幫忙PM檢查開發人員是否有落實TDD三定律,這部分是開發人員無法取代的。

2.對於測試的設計(Test Design),如Test Cases情境的撰寫,測試環境的準備與使用,測試人員還是比開發人員會多一些經驗與關注。簡單講一點,像"等價分割法"對於Test Cases的設計有效度是有幫助的,但這是測試方法論,不是開發方法論。太過於要求開發人員執行TDD的時候要懂得Test Cases Design,反而會分散了開發人員的專注力。

3.TDD是功能測試,非功能測試的部分(如安全性測試、效能測試等等)是TDD無法取代的,還是要有人進行這些測試。

看完TDD的一些討論,我越來越覺得,當整體組織的觀念尚未到位的時候,要推動一些新的軟體開發或是品保的方法論,是非常痛苦,而且是不容易成功的事情。即使觀念到位了,同時還要其他的條件配合(例如客戶,專案時程等)。有人說可以不要全面推動敏捷開發,只推TDD,我則認為這樣失敗的機率很高。


2 則留言

0
pqr0007
iT邦研究生 1 級 ‧ 2011-11-14 22:41:29

看有沒有善心人士可借用趨動程式??...

0
就是91
iT邦研究生 4 級 ‧ 2012-11-07 13:01:37

不經意的看到去年這一則分享,剛好小弟今年的鐵人賽,就是在寫TDD。

在這邊也分享一下連結,供大家參考一下:[30天快速上手TDD]目錄與附錄

swift iT邦新手 2 級 ‧ 2012-11-07 17:11:42 檢舉

讚!

我要留言

立即登入留言