單元測試
出自 MBA智库百科(https://wiki.mbalib.com/)
目錄 |
單元測試是指對軟體中的最小可測試單元進行檢查和驗證。對於單元測試中單元的含義，一般來說，要根據實際情況去判定其具體含義，如C語言中單元指一個函數，Java里單元指一個類，圖形化的軟體中可以指一個視窗或一個菜單等。總的來說，單元就是人為規定的最小的被測功能模塊。單元測試是在軟體開發過程中要進行的最低級別的測試活動，軟體的獨立單元將在與程式的其他部分相隔離的情況下進行測試。
在一種傳統的結構化編程語言中，比如C，要進行測試的單元一般是函數或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函數，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言（4GL)的開發中，在這裡基本單元被典型地劃分為一個菜單或顯示界面。
經常與單元測試聯繫起來的另外一些開發活動包括代碼走讀（Code review)，靜態分析（Static analysis)和動態分析（Dynamic analysis)。靜態分析就是對軟體的源代碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟體運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。
編寫代碼時，一定會反覆調試保證它能夠編譯通過。代碼通過編譯，只是說明瞭它的語法正確，無法保證它的語義也一定正確，編寫單元測試就是用來驗證這段代碼的行為。
單元測試越早越好。先編寫產品函數的框架，然後編寫測試函數，針對產品函數的功能編寫測試用例，然後編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的直接返回一個合適值，編譯通過後再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以後需修改的可能性比較小。
單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程式員完成，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。
在實踐工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，開發人員能夠進行更高效的系統集成工作。使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。
相比後階段的測試，單元測試的創建更簡單，維護更容易，並且可以更方便的進行重覆。從全程的費用來考慮， 相比起那些複雜且曠日持久的集成測試，或是不穩定的軟體系統來說，單元測試所需的費用是很低的。
1、它是一種驗證行為。
程式中的每一項功能都是測試來驗證它的正確性。它為以後的開發提供支援。就算是開發後期，我們也可以輕鬆的增加功能或更改程式結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程式進行改進。
2、它是一種設計行為。
編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試（test-first），迫使我們把程式設計成易於調用和可測試的，即迫使我們解除軟體中的耦合。
3、它是一種編寫文檔的行為。
單元測試是一種無價的文檔，它是展示函數或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，並且它保持最新，永遠與代碼同步。
4、它具有回歸性。
自動化的單元測試避免了代碼出現回歸，編寫完成之後，可以隨時隨地的快速運行測試。
