從事多年自動化測試框架的開發，並協助大中型企業建立自動化測試開發部門，提供可行的整體測試框架和測試方案，根據這些年在國外的工作經驗，大體上我們通常使用TDD或者BDD兩種形式，對一些大型軟體，並不侷限於這兩種方案的理論，不論採用什麼樣的測試理論，目的只有一個，也就是保證釋出的產品的質量，降低軟體在釋出後進行的維護或修復的成本，這也是作為QA這部門的職能所在。

這篇文章和大家分享的主題是: 行為驅動開發測試中何時使用Cucumber，以及使用Cucumer的先決條件和優點缺點

1. 為什麼使用Cucumber

     a.  拋棄傳統的類似QC的測試用例工具，將測試用例描述和測試用例執行整合在一起，即自然語言描述出來的測試用例可以直接被執行，而不需要人工的將自然語言轉化為可執行的測試用例

     b.  Gherkin語言規則編寫的測試用例，對於編寫測試用例的人員沒有技術要求，即測試人員可能精通業務邏輯，但不精通程式開發，或產品經理可以直接編寫和管理測試用例，通常產品經理並不懂得開發技術

     c.  測試用例 + 測試執行 + 測試報告將高度整合，並且通過可持續整合的方法，易於開發人員瞭解測試人員測試點，根據測試用例，開發人員可以直接回測，並不需要了解測試框架的設計

2. 什麼情況可以使用Cucumber

   a.  在實際操作中，Cucumber只可以使用在單純的功能測試中(非UI)，在通過UI進行的測試中，需要根據軟體的複雜度來判斷是否Cucumber,  當然Cucumber絕對不能使用在單元測試。當UI中有過多複雜的功能時，例如為了完成一項功能，通過UI可以有不同的實現方法的時候， Cucumber最大的缺陷就是很難管理你的step definition ， 當你的測試專案中，有100條以上的step definitions的時候，你的測試框架將很難被別人接受，因為學習這套step definitions是一個非常費時的工作，即使你提供了auto completion你的step。

   b. step definition應該越少越好，通過regex豐富你的step definitions

   c. 產品已經有豐富的單元測試

3. Cucumber應該用什麼版本

    Cucumber支援很多種語言，推薦給大家使用Ruby 版本，首先他在github是非常活躍的，其次在最新的cucumber中，已經支援了cucumber-wire 協議，也就是說您的step definitions不僅可以通過ruby編寫，您還可以使用.net 等語言編寫(例如嫁接white框架) 

4. Cucumber擴充套件

 這裡不是指擴充套件Cucumber的庫，而是如何將cucumber打包成一個測試IDE，您可以使用eclipse，進行RCP開發一個專門適合您公司的測試IDE，當然您也可以使用intellij擴充套件。 這裡不再進行過多的介紹，當然打個小廣告。。。 如果您的公司真的需要一套適合自己的自動化測試框架或者CI，可以郵件聯絡我