iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 29
0
Software Development

如何一步步實踐TDD (測試驅動開發)系列 第 29

BDD 行為驅動開發

TDD 幫助工程師的開發,但在軟體的生命週期中,不是只有工程師一個角色單打獨鬥。

一個軟體的成功有賴於整個團隊,內部可能包含了PM、QA 測試人員...等等,外部則有客戶與(潛在)使用者。

如果工程師開發出來的軟體成果,並不符合客戶或市場需求,那即使開發過程再好也不會帶來成功。

因此在 TDD 之後,衍生出了新的名詞:ATDDBDD


Acceptance Testing 驗收測試

軟體開發的測試階段,其中一環叫做 驗收測試,客戶對開發的系統進行驗收,決定是否已達可接受的規格、品質等等。

客戶會用接近真實的情況去操作系統,確認目前的系統符合他們的需求。

ATDD 驗收測試驅動開發

ATDD (Acceptance test-driven development),則是基於驗收測試去延伸了 TDD。

原本的 TDD 是從單元測試開始進行,ATDD 則是從軟體需求的角度開始,要求先寫驗收測試,先定義軟體要開發的內容、要達到的品質等。

驗收測試的書寫方式,通常是非軟體工程師也能閱讀的文件,可以是可執行的自動化測試,但也可以不是,這點與 TDD 不太相同。

ATDD 的目的在於讓工程師與團隊其他角色,能夠互助合作,並對產品需求達成共識,互相了解要完成什麼內容。

ATDD 的步驟:

  1. 討論需求
  2. 訂定驗收測試
  3. 才開始根據規格寫軟體

BDD 行為驅動開發

繼 ATDD 之後,BDD (Behavior-driven development) 出現了。

BDD 其實跟 ATDD 相當接近,目的都是要產出符合需求的產品,就我目前看來,BDD 就像是 ATDD 的細節實作版本。

行為 (Behavior) 代表的是產品一個個的功能或操作方式,定義了產品應該要如何運作,同時這個「行為」會轉換成可執行的測試,這與 TDD 的概念相近。

有軟體套件能夠輔助 BDD,利用自然語言 (e.g. 英文、中文) 來編寫行為,能作為工程師可執行的驗收測試,且 PM、測試人員、業務等也能看懂這份自然語言所寫的規格,幫助了需求的溝通。


與 TDD 的關係

我認為 ATDD、BDD 與 TDD 的本質其實是相同的設計思維,先從要做什麼開始思考,接著是如何驗證,最後才是寫內容達成驗證。

最初的 TDD 從單元測試出發,而 ATDD 與 BDD 則是從需求面切入,基於 TDD 擴展了測試的層面,讓 TDD 的應用更加寬廣。


參考資料

  1. Ian Sommerville - Software Engineering (10th Edition)
  2. Acceptance Test Driven Development (ATDD)
  3. Behavior Driven Development (BDD)

上一篇
TDD 過往的論戰
下一篇
總結:TDD 的實踐步伐
系列文
如何一步步實踐TDD (測試驅動開發)30

尚未有邦友留言

立即登入留言