單元測試(3)

　　(術語域測試(Field test)意思是在軟件投入使用以后，針對某個領域所作的所有測試活動)

　　這個圖表并不表示開發人員不應該進行后階段的測試活動，這次測試活動仍然是必須的。它的真正意思是盡可能早的排除盡可能多的Bug可以減少后階段測試的費用。

　　其他的一些圖表顯示高達50%的維護工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發階段被排除掉的話，這些工作量就可以節省下來。當考慮到軟件維護費用可能會比最初的開發費用高出數倍的時候，這種潛在的對50%軟件維護費用的節省將對整個軟件生命周期費用產生重大的影響。

　　結論

　　經驗表明一個盡責的單元測試方法將會在軟件開發的某個階段發現很多的Bug，并且修改它們的成本也很低。在軟件開發的后期階段，Bug的發現并修改將會變得更加困難，并要消耗大量的時間和開發費用。無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產品進行測試將使效率和質量得到最好的保證。 在提供了經過測試的單元的情況下，系統集成過程將會大大地簡化。開發人員可以將精力集中在單元之間的交互作用和全局的功能實現上，而不是陷入充滿很多Bug的單元之中不能自拔。

　　使測試工作的效力發揮到最大化的關鍵在于選擇正確的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有適當地使用象AdaTEST和Cantata這樣的工具來支持測試過程。這些活動可以產生這樣的結果：在花費更低的開發費用的情況下得到更穩定的軟件。更進一步的好處是簡化了維護過程并降低了生命周期的費用。有效的單元測試是推行全局質量文化的一部分，而這種質量文化將會為軟件開發者帶來無限的商機。

　　單元測試的優點

　　1、它是一種驗證行為。

　　程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發提供支緩。就算是開發后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。

　　2、它是一種設計行為。

　　編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試(test-first)，迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。

　　3、它是一種編寫文檔的行為。

　　單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。

　　4、它具有回歸性。

　　自動化的單元測試避免了代碼出現回歸，編寫完成之后，可以隨時隨地的快速運行測試。

　　單元測試的范疇

　　如果要給單元測試定義一個明確的范疇，指出哪些功能是屬于單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的范疇，單元測試所要做的工作。

　　1、 它的行為和我期望的一致嗎?

　　這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。

　　2、 它的行為一直和我期望的一致嗎?

　　編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致;譬如參數很可疑、硬盤沒有剩余空間、緩沖區溢出、網絡掉線的時候。

　　3、 我可以依賴單元測試嗎?

　　不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。

　　4、 單元測試說明我的意圖了嗎?

　　單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。

　　不寫測試的借口

　　到這里，我們已經列舉了使用單元測試的種種理由。也許，每個人都同意，是的，該做更多的測試。這種人人同意的事情還多著呢，是的，該多吃蔬菜，該戒煙，該多休息，該多鍛煉……這并不意味著我們中的所有人都會這么去做，不是嗎?

　　1、 編寫單元測試太花時間了。

　　我們知道，在開發時越早發現BUG，就能節省更多的時間，降低更多的風險。

　　下圖表摘自<<實用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準備測試，執行測試，和修改缺陷所花費的時間(以一個功能點為基準)，這些數據顯示單元測試的成本效率大約是集成測試的兩倍，是系統測試的三倍(參見條形圖)。

　　術語：域測試(Field test)意思是在軟件投入使用以后，針對某個領域所作的所有測試活動。

　　如果你仍然認為在編寫產品代碼的時候，還是沒有時間編寫測試代碼，那么請先考慮下面這些問題：

　　1)、對于所編寫的代碼，你在調試上面花了多少時間。

　　2)、對于以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新確認這些代碼上面。

　　3)、對于一個別人報告的bug，你花了多少時間才找出導致這個bug 的源碼位置。

　　回答完這些問題，你一定不再以“太花時間”作為拒絕單元測試的借口。

　　2、 運行測試的時間太長了。

　　合適的測試是不會讓這種情況發生的。實際上，大多數測試的執行都是非?？斓?，因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時，需要把這些耗時的測試和其他測試分開。通?？梢悦刻爝\行這種測試一次，或者幾天一次。

　　3、 測試代碼并不是我的工作。

　　你的工作就是保證代碼能夠正確的完成你的行為，恰恰相反，測試代碼正是你不可缺少的工作。

　　4、 我并不清楚代碼的行為，所以也就無從測試。

　　如果你實在不清楚代碼的行為，那么估計現在并不是編碼的時候。如果你并不知道代碼的行為，那么你又如何知道你編寫的代碼是正確的呢?

　　5、 但是這些代碼都能夠編譯通過。

原文轉自：http://blog.csdn.net/xuyubotest/article/details/4681999