從測試角度對測試驅動開發的思考【轉】

測試驅動開發(TDD)是極限編程的重要特色，它以不斷的測試推進代碼的開發，既簡化了代碼，又保證了軟件質量。本文主要從測試角度出發，從需求分解等四個階段闡述了測試人員在測試驅動開發中所發揮的促進做用

    你們都知道，軟件生命週期通常分爲六個階段：制定計劃、需求分析、設計、編碼、測試、運行和維護。在軟件工程中，這個複雜的過程用軟件開發模型來描述和表示，常見的軟件開發模型有：瀑布模型、螺旋模型、V模型、W模型等。而這些傳統的開發模型都以開發爲主，測試經常扮演的是一個亡羊補牢的配角，這類開發模型已漸漸的不能知足如今項目組的須要。從而誕生了比較實用的、高效的、以測試爲中心的軟件過程開發方法—測試驅動開發（TDD）。

    測試驅動開發，其基本思路就是經過測試來推進整個開發過程。在整個軟件開發流程中，讓測試先行，如將測試方案設計工做提早、將編寫一小段的測試代碼或產品代碼提早、同時將測試方案看成開發行爲的準繩，而後在軟件後續的開發過程當中實時進行驗證，最終實現軟件開發過程的「小步快走」。

    且看下面兩個泥瓦匠的工做方法：

　　工匠1：先拉上一根水平線，砌每一塊磚時，都與這根水平線進行比較，使得每一塊磚都保持水平；

　　工匠2：先將一排磚都砌完，而後拉上一根水平線，看看哪些磚有問題，再進行調整。

做爲旁觀者，你確定也會以爲工匠1的方法要科學一些，的確如此。在軟件項目中，在「砌磚」時以「水平線」爲標準，是否是會下降開發與需求理解的誤差、下降開發過程當中的缺陷率、並還會提升bug定位速度呢？答案固然是確定的。

在軟件整個過程當中融入測試驅動開發，那到底從哪些階段去驅動呢，從測試角度來看，我我的認爲能夠從需求分解、單元測試、集成測試、系統測試四個階段來進行。

1、需求分解階段

需求是軟件開發的源頭，不管是新開發項目仍是持續迭代更新的項目，開發人員在開發功能和測試人員在進行測試的時候，都須要最早肯定需求。

在需求發佈到需求分析、需求理解及需求確認這一過程當中，每每會出現如下現象：

（1）需求常常變動，在正在開發過程當中忽然需求又變了；

（2）需求理解誤差，開發或測試對需求理解的角度不一樣，會出現各類理解誤差；

（3）需求描述模糊或過於簡單，開發人員和測試人員會分別花費較多時間去找產品人員確認需求；

    （4）測試人員每每對需求的理解只停留在用戶的角度，未深刻從代碼的角度去

思考，如該功能包含的邊界範圍、接口、異常狀況、對其餘函數或類的影響等等；

    試想，若是能儘量的避免上述現象的發生，那不就打響了測試驅動開發的「第一炮」了麼？我認爲從如下幾個方面來進行，或許有些效果：

（1）測試人員、開發人員和產品共同參與需求的評審、更改、確認；

（2）測試人員對較大的需求（非簡單的頁面展現）進行分解成一個個小的功能點，編寫成一個個小的產品代碼（即所謂的測試用例），從而避免由於需求理解不一致致使誤差的問題；

（3）明確需求後，先預估本次需求對系統其餘功能有沒有附做用，把風險降到最低；

 

2、單元測試階段

測試驅動開發的基本思想就是在開發功能代碼以前，先編寫測試代碼。這是一個很是精典的理論，可是在實際項目過程當中，這樣實現可能會有必定的難度。既然有難度，那你還寫這篇文章幹嗎？請不要這樣問我，我會很無奈，由於我只是一個菜鳥，菜鳥所理解的測試驅動開發確定不能和專家的觀點相提並論。

在此，咱們仍是先來回顧下軟件開發模型中的W模型：

   

 

    由圖能夠看出，W模型的主要特色是測試伴隨着整個開發的生命週期，但其缺點就是把軟件的開發視爲需求、設計、編碼等一系列串行的活動，沒法支持迭代、自發性以及變動調整。

這種自上而下的只適合那種比較穩定、需求變動較少的大型項目（如軍工項目、第三方測試機構測試項目），而不適用於需求變動頻繁、迭代較快的航空B2C項目，以海航B2C項目爲例，產品人員提供需求後，就會快速進入編碼實現階段，其中會省略了概要設計和詳細設計兩步。

那經過什麼方式能夠替代概要設計和詳細設計兩階段？

試想一下，測試人員經過下面兩種方式來進行彌補，是否有利於測試驅動開發呢？

步驟1：編寫單元測試計劃，明確測試目標

測試計劃主要內容包括：

* 主要功能模塊，及實現功能定義

* 測試時間、人員分配

* 每一個模塊包含哪些測試類型、測試方法

* 明確每一個功能模塊所屬的類名、函數名和新添加字段（由開發完成）

* 測試用例（需求分解階段的產品代碼）

    步驟2：測試人員在開發編碼完成後進行單元測試

前提：

（1）測試人員與開發人員對接

    （2）測試人員搭建開發環境，並熟悉代碼結構

    （3） 步驟1中的測試計劃，都得測試人員和開發人員共同評審經過，並做爲測試的標準

單元測試檢查點：

    （1）靜態測試：檢查代碼語法、每一個類代碼行數等是否符合研發規範

    （2）動態測試：運用junit測試框架，根據測試用例，檢查每一個函數輸入輸出的

正確性、代碼分支覆蓋率、異常處理等等

 

    3、集成測試階段

    集成測試，便是對代碼進行封裝以後，對每個功能模塊進行的測試。

    對於測試人員來講，在集成測試階段又如何能發揮本身的做用，有效的作到測試驅動開發呢？

先來看下集成測試前提條件：編碼完成—>單元測試經過—>發佈代碼，部署成功—>集成測試。

因此測試人員在進行集成測試階段，如下幾方面我認爲有利於測試驅動開發： 

（1）測試人員熟悉開發環境，熟悉代碼內部結構，能運用測試思惟，提早預估風險，規避部分測試風險；

    （2）對部分難模擬場景，測試人員能夠本身經過更改代碼或配置，模擬相應測

試場景，喊少開發的工做量；

    （3）測試人員在測試過程當中發現bug以後，能快速定位bug，並能初步判斷bug

引發緣由，對開發更改bug減小跟蹤時間；

     

    4、系統測試階段

    系統測試，便是經過全部功能模塊的相互鏈接，對整個系統進行連調測試。

在系統測試階段，測試人員在測試驅動開發中又起到一個什麼樣的促進做用呢？

由於在前幾個階段，測試人員逐步參與需求理解、開發環境搭建、單元測試、集成測試，全部在系統測試階段，測試人員有如下幾個優點：

（1）對整個系統內部結構比較明瞭，對功能也很熟悉，能用較少的時間完成測試

（2）對不一樣功能之間調用的接口比較熟悉，在對系統進行接口方面的測試時有必定的優點

（3）若在測試過程當中出現了環境問題，做爲測試人員也會快速找到問題或解決方案

    （4）測試人員可針對系統特定的功能點，精準的編寫和優化自動化測試框架，

從而在之後的系統測試階段，更加節約了人力成本和發現bug的效率

（5）經過對系統的理解，能在系統須要進行安全測試、壓力測試時快速展開工做

 

    以上幾個測試階段即是我的從測試角度對測試驅動開發的理解，本文所理解的測試驅動開發與Kent Beck所著的《Test-Driven De velopment》中的測試驅動開發有必定區別，僅供參考！