-路徑覆蓋
除了代碼行覆蓋，測試代碼的每一個路徑也是非常合理的。例如，我們可以確保每一個“if”的分支都經過了，并且確保每一個“case”的所有分支都得到了執行。我們還可以確保每一個循環路徑的初始化和終止條件都是正確的。
回歸測試
這些都是“新鮮出爐”的代碼應該測試的內容，但是如果改變了一點點的代碼模塊應該做多少測試呢？在單元級別，應該做多少回歸測試呢？這是很容易誤解的地方：因為只是很小的改變，所以不值得花費很多的時間去測試它。
確實，對于每次一小行的代碼的改變我們不能進行完整的測試。但是，同時，這些“很小”的改動通常帶來潛在的、重大的、非預期的影響。最好的方法是恰當地評估回歸測試：結合基于風險的測試和區域影響測試。
基于風險的測試
基于風險的測試指基于缺陷的風險來選擇測試。對于風險有兩個方面：可能性和影響程度。
可能性是判斷更改會造成某些問題的機會。我們應該測試那些可能出現問題的地方。評估代碼改變的地方是其中一個判斷的方式，另外一個是尋找曾經出現的類似改變。
影響程度是關于程序出現錯誤時造成的損失程度（不管出現的可能性）。那些高影響程度的地方應該被重現測試。例如，程序經常被使用到的核心功能、影響安全的地方。
區域影響測試
區域影響測試是指專注于發生改變的代碼區域的測試。例如：
-一個開發人員應該完全覆蓋測試增加的或改變的代碼模塊。
-相應地，他應該測試所有受改變影響的路徑。
-并且，開發人員應該對那些與所修改的代碼關聯的地方做一些相對沒有那么嚴格的測試。例如，如果代碼改變的是參數的集合，那么應該測試那些參數被用到的地方。
單元測試的客觀證據
計劃所有這些測試都是好的，但是也需要一些客觀的方式來驗證測試被真正執行了。應該收集和保存什么證據來表明開發人員已經執行了那些測試？并且測試得到期待的結果？我們如何知道所有我們決定要做的這些測試已經做了并且做對了呢?
很明顯，我們加給開發人員的驗證檢查的負擔應該合理，并且要考慮測試被無意忽略的風險。我們不想強加不必要的作業；我們只是想確保當開發人員說一個模塊已經準備好提交了，我們都知道這意味著什么。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
