摘要： 敏捷開發的蓬勃發展、遍地開花，TDD（Test Drive Development測試驅動開發）的概念已經深入軟件研發從業者的心中。TDD講究的是：“測試在先、編碼在后”。有別于以...

敏捷開發的蓬勃發展、遍地開花，TDD（Test Drive Development測試驅動開發）的概念已經深入軟件研發從業者的心中。

TDD講究的是：“測試在先、編碼在后”。有別于以往的“先編碼、后測試”的開發過程，而是在編程之前，先寫測試腳本或設計測試用例。

“測試先行”，使得開發人員對所做的設計或所寫的代碼有足夠的信心，同時也有勇氣進行設計或代碼的快速重構，有利于快速迭代、持續交付。

嚴格來說，TDD是一種開發實踐。

從軟件開發角度來看，TDD是很棒的！

然而，把需求分析整理，軟件開發，到產品化，再到用戶使用，這樣整個流程來看，單純的TDD還是有一定瑕疵的。

TDD只涉及到Developer（開發者），只能算是開發工程師個人工作方式的改變。而現代軟件開發，往往都是“產品經理（或業務）、測試人員（QA）、開發人員”三者合作的成果，如果開發人員對業務需求理解的不正確，那么寫出的測試用例也是錯的，這個問題是TDD解決不了的。

在不脫離敏捷開發的大前提下：業務層次，也可以采用類似TDD方法論。

換言之，需求分析時就確定需求（如：用戶故事）的驗收標準。畢竟軟件最終是要給用戶使用的，要滿足用戶需求，解決用戶的痛點。否則就會變成程序員的自high！

上面的業務層次的敏捷測試，升華到方法論的高度，就是驗收測試驅動開發（Acceptance Test Driven Development，ATDD）。

ATDD的執行邏輯，如下圖所示：

ATDD是一種在編碼開始之前將客戶帶入測試設計過程的技術實踐。

同時，ATDD也是一個協作實踐：用戶，測試人員和開發人員，共同定義了自動驗收標準。

ATDD有助于確保所有項目成員準確理解需要完成和實施的內容。

如果系統未通過測試可提供快速反饋，說明未滿足要求。

驗收測試以業務領域術語進行指定。每個功能都必須提供真實且可衡量的業務價值，事實上。

ATDD這樣的做法，其實對應著《成功人士的“七個習慣”》之一的“以終為始”。

產品經理、研發人員、測試人員，三個角色的人首先坐到一起，澄清細化最終客戶的目標，并把自始至終都基于這個目標工作，這不就是以終為始嗎？

ATDD帶來的好處也顯而易見

? 大家對業務需求的統一理解

? 通過自然語言來描述需求

? 是可以運行的需求或實例

? 是活著的文檔

說了這么多，相信大家已經可以明白ATDD絕對不是TDD多了一個“A”。

還沒懂？一句話對比法來說明區別：

TDD的目的是：Do the right development；

ATDD的目的是：Do the development right！

具體到測試人員的工作實踐中，筆者推薦Python和JAVA的兩個框架，基本可以滿足工作需求了。

Python背景的測試人員，推薦使用Robot Framework。

官網：
https://robotframework.org/

RF的 “keyword-driven” 方式，用來編寫測試案例，是一個非常適合用來實踐ATDD的工具。

JAVA背景的測試人員，推薦使用FitNess框架。

官網：www.fitnesse.org

TDD，最終還是程序員自己的事情；ATDD，讓測試人員更多地參與到產品、研發、交付中。

是時候擁抱ATDD了！

作 者：Testfan Arthur

出 處：微信公眾號：自動化軟件測試平臺

版權說明：歡迎轉載，但必須注明出處，并在文章頁面明顯位置給出文章鏈接