對測試驅動開發的感悟[1] 軟件測試工具
最近聽到了很多關于軟件質量的話題，自己前段時間也參加個PMP(項目管理)的培訓，所以一時對于質量控制特別感興趣，在這里想和大家共同討論下!
軟件質量，是所有人都很關心的東西。我們在開發過程中為了保證質量，從中引進了軟件測試。它在整個的過程中起到的作用不言而預，但是它也存在一些問題:
1、在軟件測試中要保證軟件的高質量就必須增加項目的成本，從而需要增加測試人員，延長項目時間，購買或學習測試工具的成本。
2、因為這種測試是依賴與開發完后才提交給測試人員的，所以如果測試中出現BUG，就會出現BUG打回，再次提交測試...，這中間還需要測試人員和開發人員的溝通，這也是一個成本的增加
3、這種方式會使得開發人員對測試人員產生依賴，從而降低代碼的質量，減少自己的測試.....
我們為什么不能把測試前移呢!讓開發人員自己對軟件的業務就做個完整的測試，然后把代碼提交給測試人員，這樣就可以減少BUG的數量，同時可以讓測試人員不只關注與功能性的問題，可以關注更深層次的問題(性能，用戶體驗...)，這種方式就是做單元測試。其實這個東西很早就有了，每個人都知道它，只是如何做的問題，我相信其實很多公司都做到，有些做的很好，但也有些是失敗的!我自己經歷過失敗，體會過它的麻煩和迷惑，也經歷了成功，體會到了它的好處。所以把這些寫出來分享下!
軟件就是由代碼組成的，所以軟件的質量就是代碼的質量，我們出了BUG就從代碼開始入手找問題，然后修改代碼。但是當你的軟件從小慢慢變大時候，代碼越來越多，彼此之間的關聯越來越緊密，這樣就帶來了一個問題"修改一部分代碼后會影響多少?"，如果你拿這個問題去問那些項目中沒有單元測試的開發人員，他們給出的答案都是通過"拍腦袋"來的，這樣絕對會給你的項目帶來風險。為了降低風險，項目開始要求開發人員做單元測試，但是做過后得出，這真的可以降低成本嗎!花了太多的時間去寫測試代碼(甚至比開發時間還要多)，對于質量的保證也沒有達到預期的效果...，項目做完后，發現做單元測試的和沒有做成本多很多，所以接著就放棄了!..... 這種現象我想是我們都想做它但又不做它的最大因素。
其實我想大家對它的理解有點誤差，我認為他最大的用處不是用來測試代碼，而是測試設計!!代碼從是設計來的，保證了設計的正確性不也保證了代碼嘛!軟件中的未知風險太多了，其實很多出于設計，對于設計很難去評價好，還是壞，很難找到一個衡量的標準，但是我想TDD，給了我們一個標準，雖然不能去完整的評價，但至少可以是一部分，可以降低它的風險。
這里慢慢開始引入了本文的主題，測試驅動開發(TDD)。我的理解上，單元測試如果不是TDD這種模式，就沒有太多的必要去做，因為那樣投入做單元測試的成本和收益之間找不到平衡點。
"測試驅動開發"的經歷
測試驅動開發簡稱TTD，全名Test-Driven Developmentd。它是敏捷開發的一個重要組成部分，來源與"極限編程"。我接觸它是從一年前的那天(具體時間不記得了~ 呵呵!)開始的.....
接觸
記得兩年前的某天，我正在公司偷偷地看電視劇"奮斗"，這時看到郵箱中的一封郵件: 部門下了一個確定"要求每個項目開發過程中加入單元測試"。當我聽到"單元測試"的時候，滿頭的問號，"它是什么東西，做什么用的....?"(當時還很菜，居然還聽過單元測試...!)，接著不停的開始找資料，足足花了一個星期才把它了解，然后做了一個簡單的DEMO，寫些簡單的測試代碼，把它放到 Nunit上，看著都是通過的提示，興奮呀!
這時就和項目中的一個"大牛"開始討論它了，忽然"大牛"的口中蹦出了三個英文單詞"TDD"，然后和我講了一大堆，我根本就不知道他說什么(水平有限，當時理解不了)，只是重復著三個字"明白了"。接著他說，項目的這個版本你設計的時候，加入單元測試吧，如果可以的話，也試下TDD.....
我是一個喜歡挑戰的人，所以一開始就玩先寫測試代碼，結果呢!大家都明白，菜鳥嘛!一定失敗咯，其中的原因是：根本就沒有"測試驅動開發"的思想，完全不知道如何開始先寫測試代碼，而且還沒有理解MOCK!下面只有乖乖地和別人一樣，等代碼寫完后再寫測試代碼。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
