什麼是驗收測試驅動開發

在準備實施一個功能或特性之前，首先團隊需要定義出期望的質量標準和驗收細則，以明確而且達成共識的驗收測試計劃（包含一系列測試場景）來驅動開發人員的TDD實踐和測試人員的測試指令碼開發。

   注意：測試人員必須是團隊的一部分，並在ATDD的過程中扮演關鍵和掌控性的角色。

   典型的ATDD開發過程是：

    Step 1：產品負責人向測試人員和開發人員講解使用者故事，澄清他們提出的問題；

    Step 2：
     a.測試人員列出驗收該功能所需要驗證的所有測試場景，每個測試場景通常是概要，清晰的一句話；
     b.同時，開發人員查詢和分析現有的相關設計，程式碼和單元測試，明確開發策略；

    Step 3：測試人員和開發人員共同評審和調整測試場景列表，達成共識；必要時尋求產品負責人的參與和確認；並且明確那些場景應該有單元測試；

    Step 4：
     a.基於通過評審和認可的測試場景列表，測試人員開始為每個測試場景建立詳細的驗收測試用例，準備測試指令碼和測試資料；
     b.同時，基於同樣的的測試場景列表，開發人員開始新增單元測試用例，並以TDD方式驅動業務實現；

    Step 5：在開發人員將完成的功能部署並交付測試人員執行測試之前，進行程式碼評審和根據測試場景列表快速驗證自己完成的功能，甚至邀請測試人員來觀摩；

    Step 6：一旦完成的功能通過構建並部署到測試環境，測試人員立刻開始執行測試指令碼；

    Step 7：任何測試人員的測試中發現的缺陷都要紀錄到工具，並跟蹤，立刻反饋給開發人員解決，或進行其它恰當處理；

    Step 8：最後，在迭代結束，團隊成員向產品負責人和客戶演示完成的功能。具體演示那些場景，可以在Step 3的階段就確定。

   由此可見，ATDD和基於單元測試的TDD一樣，也充分體現了敏捷開發“業務驅動”的特點，始終從使用者的業務價值出發；對開發團隊來說，ATDD是由外向內，多方介入的，基於拉動策略的，並行開發測試方法；確保所有交付的產品都經過了充分的測試。

    ATDD的好處：

    1.提高交付產品的質量－因為測試人員早期介入所發揮的驅動作用，確保所有交付的功能都經過了測試，並且提高了測試的覆蓋和準確性；
    2.提高TDD質量－測試人員和開發人員共同定義測試場景列表，並且經過評審和修訂，可以幫助開發人員書寫高質量的，覆蓋完整的單元測試用例。有助於解決上面提到的TDD方法的第一個侷限性；
    3.迴歸測試－良好定義和覆蓋完整的單元測試和驗收測試指令碼有助於未來進行迴歸測試；
    4.消除浪費－以ATDD的方式，滿足和通過所有的驗收測試場景是開發的首要目標，可以避免團隊進行一些對客戶沒有價值的工作，減少浪費

   在ATDD的實施中，最主要的變化和挑戰在於測試人員的工作方式和流程，對測試人員提出了這些挑戰：

   *角色轉變－傳統的很多專案中，測試人員通常都是一個獨立的QA團隊，與開發團隊彼此協作較少，測試人員的工作以開發人員完成開發和部署為起點；在敏捷開發中，尤其是ATDD的團隊中，測試人員必然是開發團隊的成員，而且是處於支配作用的重要成員。測試人員不能繼續是被動的，而是以自己的成果來帶動開發實現；

   *溝通能力－傳統專案的測試通常基於完備詳細的需求文件；然而在敏捷開發中，需求都是以使用者故事的簡化形式定義的，測試人員要列出準確完備的測試場景，他需要更多地和產品負責人，開發人員溝通，每天緊密工作在一起，有任何問題或變化都能立刻反饋到團隊其他成員；

   *探索性測試－由於敏捷使用者故事地簡單性，而ATDD基於預定義的測試場景列表開發測試指令碼，並且部分測試場景有了自動化的單元測試，不再需要重複的手動測試指令碼，因此ATDD中的測試指令碼不一定能覆蓋到所有的邏輯和質量標準，於是“探索性測試”成為一個新的熱門話題。即在既定的測試指令碼以外，對當前和相關功能進行探索性的測試，嘗試去發現一些隱藏的，未知的錯誤，或者一些不完美的地方。這應該成為測試人員的一種工作習慣。探索性測試看似隨意，也有一些可遵循的方法，比如賣點測試、破壞測試、極限測試、深巷測試等。