軟件測試中測試技術：如何建立單元測試標準
是時候出新版本了。那么應該把什么包括進來？顯然，它應該包括每個模塊的最新的最好的版本。對吧？
“最新的和最好的”基于一個假設：最新的版本就是最好的版本。最新的版本添加了特性，糾正了問題，簡而言之，改進了之前的版本。怎么會不是最好的呢？
但是，實際上，事情并不是你想象的那么簡單。那些新的特性可能與其它現有的功能不兼容。用戶依賴的東西可能消失了。新的特性可能削弱了可用性（尤其是對新用戶來說）。還有，那些bug總是在這些新的改變的代碼中出現。
因此，我們如何才能判定最新的就是最好的？我們如何知道代碼真的準備好了被包括到下一個build中？很多開發組通過建立升級標準來解決這個問題。升級標準是關于某個模塊是否準備好包括在一個build版本中的判定策略。
單元測試標準
雖然可以把很多別的東西包括到你的升級標準中來，但是單元測試是所有這些標準的基礎。幾乎每個組織都假設軟件開發人員在做適當的單元測試。但是不幸的是，不同的人對“適當”的測試傾向于采用非常不一樣的理解。
好的實踐要求開發人員文檔化它們的測試，并且對那些測試進行同行評審以確保有適當的覆蓋率。如果使用自動化測試，那么開發人員能簡單地為開發工具創建測試腳本，并且提交那些腳本用于評審。
當然，對于什么應該包括在單元測試中必須建立一個小組的標準。作為一個開發組，關于應該做什么測試要達成一致的共識需要花費一些時間和做出一些權衡，但是花在這里的時間會從正確的構建過程中得到加倍的回報！讓我們看看一些單元測試期望的例子。
功能
當然，每個模塊必須被測試以確保它滿足設計的要求，并且確保它做了真正應該做的正確的事情。它應該處理什么樣的輸入？必須完成什么工作？會提供什么服務？它應該產生怎樣的輸出？它必須管理什么數據,應該怎樣使用那些數據？我們必須確保這個模塊真正做了它需要做的事情。
負面測試
然后是錯誤處理。當出現錯誤時這個模塊會做“正確”的事情嗎？當它處理某些特殊的輸入時會出現什么情況？缺乏數據組成或數據輸入的順序被打亂的時候會怎樣？當需要輸入數值數據時給它非數值數據會怎樣？數據溢出？如果它接收到一個從數據庫或網路接口返回的錯誤狀態時會怎樣？它會如何處理？一個模塊在被認為完成之前，必須正確地處理所有錯誤條件。
覆蓋
我們都知道完全的測試不是軟件測試的一個合理目標。太多的輸入組合，事件的發生有太多的可能順序，太多不同的出錯方式，因此完整地測試所有東西，即使是一個很小的程序，也是不可能的。
但是代碼和路徑覆蓋是單元測試可達到的一個目標。事實上，單元測試階段是把完整覆蓋代碼和路徑作為一個合理的目標的唯一時間。
-代碼覆蓋
在單元測試過程中，要求代碼的每一行都被執行到，這一點都不過分（并且有很多分析工具可以幫助我們確保這點）。一些代碼（尤其是錯誤處理）是不能被測試到的，除非采用額外的步驟（例如編寫一個傳遞壞數據的函數，或者把錯誤代碼注入到內存中），但是這些不僅僅是適合做的，而且對于確保程序可以處理各種應該處理的情況來說非常關鍵的！
文章來源于領測軟件測試網 http://www.kjueaiud.com/