我們經常聽到人們宣揚說，在開發軟件時寫測試代碼(單元測試，功能測試等)能有效的減少產品中的bug。如何驗證這樣的言論？通常，這些人都是已經在使用驅動測試開發(TDD)或行為驅動開發(BDD)，而且，他們所在的公司在誕生第一天起就有著很強的測試文化。然而，如何能測量不寫測試程序造成的影響？如何能驗證實踐TDD能真正的減少bug的存在？我們能否在一段時間里停止寫測試程序，看看這對軟件缺陷數有多大的影響？這方法看起來不太現實。

這篇文章里，我將通過分析當前我工作中的真實數據來回答這個問題。以前我們的系統沒有測試代碼，可一旦開始進行測試驅動開發，我就成為了這種開發方法的強力倡導者。

測試驅動開發前的背景情況

我做Web開發已經有10年了，從2009年起就開始耳聞驅動測試開發(TDD)。從那時開始我就打算要多學學這方面的知識。我在當時的公司里已經干了兩年，現在已經是2012年，在這個公司總共工作了5年，從后3年開始實施測試驅動開發方法。

這個過程非常有趣，因為如今我可以瀏覽我們的bug跟蹤系統，匯總這段時間的缺陷統計數據，看看TDD對我們的程序代碼質量有多大的影響。

簡單的說一下我們的軟件技術構成：我開發基于PHP和Javascript的系統UI部分。我是UI部分的主要開發人員，這就是說，如果UI上有bug，我基本上要對此負責。UI跟后臺的C++服務交互，這服務運行在Oracle數據庫上，通過PLSQL代碼處理數據。

UI部分的PHP代碼是唯一實施了測試驅動開發的地方。我們的Javascript代碼沒有測試程序。遺憾的是，公司里的程序員都沒有測試驅動開發的實踐經驗。系統其它層面的代碼都沒有實施單元測試或功能性測試(公司有專門的QA團隊在開發完成之后進行測試)。

這使得我們的統計分析數據看起來非常的明顯。我可以看到，隨著時間的推移，我們的整個產品和UI模塊的缺陷數字的變化。這使得我有辦法來回答最初的問題，這個問題在此可以用這樣的問題復述：使用測試驅動開發能使我負責的UI模塊的缺陷數下降嗎？

測試驅動開發真的有效嗎？

下面這個圖表是由我們的bug跟蹤系統生成的。它向我們展示了UI部分的bug和整個產品的bug的對比比率。

我們可以從中看出一些有趣的事情：

• 首先，我可以回答這個問題：在UI中發現的bug的數量(下面綠顏色的)減少了50%(起初UI部分相關的bug數量占整個產品的35%，如今它已經降到了15%)。
• 在歷史遺留的程序庫上實施測試驅動開發并不會很快的顯現出效果。我于2009年第三季度開始TDD。你可以看到，到了2010年第三季度時bug數才開始下降，而到了2011年第三季度開始大幅度下降。將近用來2年的時間實現了50%的降低。
• 圖表上顯示，在2010年第二季度和2011年第二季度時，數據上下跳動。看一下我們產品的發布歷程，這應該歸結于這段時間系統里增加了嚴重依賴于Javascript的第三方地圖API功能。我之前也說過，我們并沒有寫Javascript上的測試代碼。這也證實了不寫測試代碼會導致更多的 bug。

下一步的計劃？

之前我說過，我只是在PHP代碼上實施了測試驅動開發。觀察如今產生的bug，我注意到它們通常可以歸為這樣兩類：

• Javascript代碼中的bug（這些是沒有自動化測試程序的）
• 系統集成時產生的bug(例如，獨立的PHP組件通過了單元測試，但組合起來運行時卻出了問題)

這很自然的將我引入了下一步的測試探險：我要在Javascript代碼里加入測試套件代碼，并最終加入集成測試套件代碼。

今年整個夏天我都在做這項工作。對于Javascript代碼，開發了基于Jasmine BDD框架的測試套件。對于端對端的測試，我使用Cucumber。在這兩種情況中，我使用Selenium Web Driver在真實的瀏覽器中運行測試代碼，或胡亂的使用強大的Phantom.js。

我們即將開始下一個開發周期，我期望通過這些新的措施，我們能開發出更有質量的軟件。我希望明年還能寫出這樣的一篇文章來分析這些測試開發工具的效果。很有可能它們會進一步的降低我們的bug數量。

還有，把這些數據分享給我的同事，這讓一些開發人員也開始相信測試驅動開發的好處。我們產品中另外一些服務上的開發人員對TDD表現出了興趣，準備研究如何在他們的程序庫上實施測試驅動開發。觀察他們的在實踐中能獲得什么樣的成果將會是一件有趣的事情。

結束語

你呢？測試驅動開發(TDD)和行為驅動開發(BDD)是如何影響你們的代碼質量的？你是否也有類似的統計數據可以分享？請在下面的評論里寫出來。

原文鏈接：http://www.aqee.net/test-driven-development-actually-works/