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

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

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

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

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

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

作為旁觀者，你肯定也會覺得工匠1的方法要科學一些，的確如此。在軟件項目中，在“砌磚”時以“水平線”為標準，是不是會降低開發與需求理解的偏差、降低開發過程中的缺陷率、並還會提高bug定位速度呢？答案當然是肯定的。

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

一、需求分解階段

需求是軟件開發的源頭，無論是新開發項目還是持續叠代更新的項目，開發人員在開發功能和測試人員在進行測試的時候，都需要最先確定需求。

在需求發布到需求分析、需求理解及需求確認這一過程中，往往會出現以下現象：

（1）需求經常變更，在正在開發過程中突然需求又變了；

（2）需求理解偏差，開發或測試對需求理解的角度不同，會出現各種理解偏差；

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

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

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

試想，如果能盡可能的避免上述現象的發生，那不就打響了測試驅動開發的“第一炮”了麽？我認為從以下幾個方面來進行，或許有些效果：

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

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

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

二、單元測試階段

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

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

由圖可以看出，W模型的主要特點是測試伴隨著整個開發的生命周期，但其缺點就是把軟件的開發視為需求、設計、編碼等一系列串行的活動，無法支持叠代、自發性以及變更調整。

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

那通過什麽方式可以替代概要設計和詳細設計兩階段？

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

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

測試計劃主要內容包括：

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

* 測試時間、人員分配

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

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

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

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

前提：

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

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

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

單元測試檢查點：

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

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

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

三、集成測試階段

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

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

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

所以測試人員在進行集成測試階段，以下幾方面我認為有利於測試驅動開發：

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

（2）對部分難模擬場景，測試人員可以自己通過更改代碼或配置，模擬相應測

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

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

引起原因，對開發更改bug減少跟蹤時間；

四、系統測試階段

系統測試，即是通過所有功能模塊的相互連接，對整個系統進行連調測試。

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

因為在前幾個階段，測試人員逐步參與需求理解、開發環境搭建、單元測試、集成測試，所有在系統測試階段，測試人員有以下幾個優勢：

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

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

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

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

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

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

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

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