TDD和BDD

開發人員看測試之TDD和BDD

 

前言：

　　已經數月沒有來園子了，寫博客貴在堅持，一旦鬆懈了，斷掉了，就很難再拾起來。可是往往看到本身博客裏的博文的瀏覽量天天都在增長，都在無形當中給了我繼續寫博客的動力。最近這兩天有聽到Jbehave這個名詞，上網查了一通，原來是和測試相關的，以前一直作開發，沒有作過真正意義上的測試，對於測試的理解更是少之又少。經過這兩天的查閱，現將本身的一些理解以及常見概念羅列出來。

正文：

　　Behavior Driven Development，行爲驅動開發是一種敏捷軟件開發的技術，它鼓勵軟件項目中的開發者、QA和非技術人員或商業參與者之間的協做。
在瞭解Behavior Driven Development以前，先介紹Test-Driven Development(TDD)即測試驅動開發，它是一種測試先於編寫代碼的思想用於指導軟件開發。測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼以前，先編寫單元測試用例代碼，測試代碼肯定須要編寫什麼產品代碼。
它的工做流程以下所示：

TDD方法的一些特色：

• 有利於更加專一軟件設計；
• 清晰地瞭解軟件的需求；
• 很好的詮釋了代碼即文檔。

 

我眼中的測試

　　以前一直對於測試都是一個籠統的認知，以爲測試僅僅是一種驗證，相似於部分企業中一些比較省事的測試方法，一般在代碼寫好以後再實施測試工做，用於驗證developer的代碼是否符合需求。稍微瞭解TDD、BDD以後才發現，測試不單單是一種對於代碼的驗證，找出幾個bug或者一些諸如壓力測試、負載測試，更是一種約束，一種規範，是與項目需求息息相關，還須要溝通協調客戶、開發人員以及QA，從而幫助更加高效的完成軟件設計開發工做。

　　經過下面一幅圖就能夠發現對於測試也有不一樣的層次和流程：

　　從圖中能夠發現，最下面的是單元測試（白盒測試），主要用於測試開發人員編寫的代碼是否正確，這部分工做都是開發人員本身來作的。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。再往上，就是BDD（灰盒測試、黑盒測試），主要用於測試代碼是否符合客戶的需求，這裏的BDD更加側重於代碼的功能邏輯。

　　從左邊的範疇也能夠看出，測試的範圍也是逐層擴大，從單元測試的類到BDD裏面的服務、控制器等，再到最上層的模擬實際操做場景的Selenium（Selenium也是一個用於Web應用程序測試的工具。Selenium測試直接運行在瀏覽器中，就像真正的用戶在操做同樣。支持的瀏覽器包括IE(七、八、9)、Mozilla Firefox、Mozilla Suite等。）對於包括UI界面的測試。以前本身有作過這樣的編碼測試工做，經過寫代碼，能夠打開IE、FF等瀏覽器，模擬用戶點擊、填寫數據等操做，從而完成一整套的流程測試。整個測試從小到大，從函數、方法、類到功能模塊乃至系統有着一系列嚴謹的體系。

 

再說BDD

　　BDD是一種敏捷軟件開發的技術。它對TDD的理念進行了擴展，在TDD中側重點偏向開發，經過測試用例來規範約束開發者編寫出質量更高、bug更少的代碼。而BDD更加側重設計，其要求在設計測試用例的時候對系統進行定義，倡導使用通用的語言將系統的行爲描述出來，將系統設計和測試用例結合起來，從而以此爲驅動進行開發工做。

　　BDD的通用語言是一種近乎天然語言的描述軟件的形式。傳統的開發模式中，客戶很難從技術層面理解問題，開發人員很難從業務需求考慮問題，基於這種通用語言形式能夠儘量的避免客戶和開發者在溝通上的障礙，實現客戶和開發者同時定義系統的需求。避免了由於理解需求不充分而帶來的沒必要必要的工做量。

　　BDD描述的行爲就像一個個的故事(Story)，系統業務專家、開發者、測試人員一塊兒合做，分析軟件的需求，而後將這些需求寫成一個個的故事。開發者負責填充這些故事的內容，測試者負責檢驗這些故事的結果。一般，會使用一個故事的模板來對故事進行描述

　　Story：

1 2 3

As a 角色 I want 特徵 so that 利益

　

　　As a標識出這個系統行爲是爲哪個角色而定義的。

　　I want和so that則指明瞭該角色想作的事， 以及想達到的目的。

　　這三個斷句定義了這個系統行爲的參與者、範圍。

 

　　一樣的一個Story，可能會有不一樣的場景。經過上面的模板描述了故事以後，再經過下面的模板對不一樣場景進行描述

　　Scenario:

1 2 3 4 5

Given [上下文]      And [更多的上下文] When [事件] Then [結果]      And [其餘結果]

　

　　這些場景中的Given…When…Then…實際上就是設定該場景的狀態、適用的事件，以及場景的執行結果。

　　其實經過這樣的Story描述和場景設置，基本就完成了一個完整測試的定義。

 

　　BDD整個測試流程如圖所示：

 

常見的BDD框架：

• C – Cspec
• C++ – CppSpec, Spec-CPP
• .Net – NBehave, NSpecify, SpecFlow
• Groovy – GSpec, easyb, Cuke4Duke
• PHP – PHPSpec
• Python – Specipy
• Ruby – RSpec, Shoulda, Cucumber

與Java相關的BDD測試工具：

• JBehave – Java annotations based, Test frameworks agnostic
• Cuke4duke – Cucumber support for JVM
• JDave – RSpec (Ruby) inspired, Mojo 2 & Hamcrest based
• beanSpec – Java based
• easyb – Java based, Specifications written in Groovy
• instinct – BDD framework for Java, providing annotations for contexts. Inspired by Rspec
• BDoc - Extracts behaviour from unit tests