建立單元測試標準
陳能技2007-10-14
原文：establishing unit test criteria – alan s.koch
是時候出新版本了。那麼應該把什麼包括進來？顯然，它應該包括每個模組的最新的最好的版本。對吧？
「最新的和最好的」基於乙個假設：最新的版本就是最好的版本。最新的版本新增了特性，糾正了問題，簡而言之，改進了之前的版本。怎麼會不是最好的呢？
但是，實際上，事情並不是你想象的那麼簡單。那些新的特性可能與其它現有的功能不相容。使用者依賴的東西可能消失了。新的特性可能削弱了可用性（尤其是對新使用者來說）。還有，那些bug總是在這些新的改變的**中出現。
因此，我們如何才能判定最新的就是最好的？我們如何知道**真的準備好了被包括到下乙個build中？很多開發組通過建立公升級標準來解決這個問題。公升級標準是關於某個模組是否準備好包括在乙個build版本中的判定策略。
單元測試標準
雖然可以把很多別的東西包括到你的公升級標準中來，但是單元測試是所有這些標準的基礎。幾乎每個組織都假設軟體開發人員在做適當的單元測試。但是不幸的是，不同的人對「適當」的測試傾向於採用非常不一樣的理解。
好的實踐要求開發人員文件化它們的測試，並且對那些測試進行同行評審以確保有適當的覆蓋率。如果使用自動化測試，那麼開發人員能簡單地為開發工具建立測試指令碼，並且提交那些指令碼用於評審。
當然，對於什麼應該包括在單元測試中必須建立乙個小組的標準。作為乙個開發組，關於應該做什麼測試要達成一致的共識需要花費一些時間和做出一些權衡，但是花在這裡的時間會從正確的構建過程中得到加倍的回報！讓我們看看一些單元測試期望的例子。
功能
當然，每個模組必須被測試以確保它滿足設計的要求，並且確保它做了真正應該做的正確的事情。它應該處理什麼樣的輸入？必須完成什麼工作？會提供什麼服務？它應該產生怎樣的輸出？它必須管理什麼資料,應該怎樣使用那些資料？我們必須確保這個模組真正做了它需要做的事情。
負面測試
然後是錯誤處理。當出現錯誤時這個模組會做「正確」的事情嗎？當它處理某些特殊的輸入時會出現什麼情況？缺乏資料組成或資料輸入的順序被打亂的時候會怎樣？當需要輸入數值資料時給它非數值資料會怎樣？資料溢位？如果它接收到乙個從資料庫或網路介面返回的錯誤狀態時會怎樣？它會如何處理？乙個模組在被認為完成之前，必須正確地處理所有錯誤條件。
覆蓋
我們都知道完全的測試不是軟體測試的乙個合理目標。太多的輸入組合，事件的發生有太多的可能順序，太多不同的出錯方式，因此完整地測試所有東西，即使是乙個很小的程式，也是不可能的。
但是**和路徑覆蓋是單元測試可達到的乙個目標。事實上，單元測試階段是把完整覆蓋**和路徑作為乙個合理的目標的唯一時間。
- **覆蓋
在單元測試過程中，要求**的每一行都被執行到，這一點都不過分（並且有很多分析工具可以幫助我們確保這點）。一些**（尤其是錯誤處理）是不能被測試到的，除非採用額外的步驟（例如編寫乙個傳遞壞資料的函式，或者把錯誤**注入到記憶體中），但是這些不僅僅是適合做的，而且對於確保程式可以處理各種應該處理的情況來說非常關鍵的！
- 路徑覆蓋
除了**行覆蓋，測試**的每乙個路徑也是非常合理的。例如，我們可以確保每乙個「if」的分支都經過了，並且確保每乙個「case」的所有分支都得到了執行。我們還可以確保每乙個迴圈路徑的初始化和終止條件都是正確的。
回歸測試
這些都是「新鮮出爐」的**應該測試的內容，但是如果改變了一點點的**模組應該做多少測試呢？在單元級別，應該做多少回歸測試呢？這是很容易誤解的地方：因為只是很小的改變，所以不值得花費很多的時間去測試它。
確實，對於每次一小行的**的改變我們不能進行完整的測試。但是，同時，這些「很小」的改動通常帶來潛在的、重大的、非預期的影響。最好的方法是恰當地評估回歸測試：結合基於風險的測試和區域影響測試。
基於風險的測試
基於風險的測試指基於缺陷的風險來選擇測試。對於風險有兩個方面：可能性和影響程度。
可能性是判斷更改會造成某些問題的機會。我們應該測試那些可能出現問題的地方。評估**改變的地方是其中乙個判斷的方式，另外乙個是尋找曾經出現的類似改變。
影響程度是關於程式出現錯誤時造成的損失程度（不管出現的可能性）。那些高影響程度的地方應該被重現測試。例如，程式經常被使用到的核心功能、影響安全的地方。
區域影響測試
區域影響測試是指專注於發生改變的**區域的測試。例如：
- 乙個開發人員應該完全覆蓋測試增加的或改變的**模組。
- 相應地，他應該測試所有受改變影響的路徑。
- 並且，開發人員應該對那些與所修改的**關聯的地方做一些相對沒有那麼嚴格的測試。例如，如果**改變的是引數的集合，那麼應該測試那些引數被用到的地方。
單元測試的客觀證據
計畫所有這些測試都是好的，但是也需要一些客觀的方式來驗證測試被真正執行了。應該收集和儲存什麼證據來表明開發人員已經執行了那些測試？並且測試得到期待的結果？我們如何知道所有我們決定要做的這些測試已經做了並且做對了呢?
很明顯，我們加給開發人員的驗證檢查的負擔應該合理，並且要考慮測試被無意忽略的風險。我們不想強加不必要的作業；我們只是想確保當開發人員說乙個模組已經準備好提交了，我們都知道這意味著什麼。
單元測試（三） 建立多執行緒單元測試
junit本是不支援多執行緒的，乙個單元測試case主程序跑完，其他new出來的執行緒都會gg思密達。此篇mark乙份在junit中執行多執行緒的方法。net.sourceforge.groboutils groboutils core 5test slf4j public class device...
單元測試 vs2008建立單元測試
vs2008中建立單元測試 有多種途徑 1.開啟乙個類,在編輯視窗內右鍵 建立單元測試 方法選擇框 建立新的測試專案 如果沒有測試專案 選擇測試專案 2.建立測試專案,然後在解決方案管理器中 在該專案名上點選右鍵 新增 單元測試 選擇程式集.類.方法 3.選單 測試 新建測試 編寫測試類.執行測試 ...
vs建立單元測試
using system using system.collections.generic using system.linq using system.text namespace ceshishijian static int sub int a,int b static void main s...