所有正面測試
這組測試可以確保所有的東西都如我們期望的一樣工作。
所有負面測試
逐一使用這些測試，從而確保每個失效或異常情況都被測試到了。
正面序列測試
這組測試可以確保按照正確順序的調用可以像我們期望的一樣工作。
負面序列測試
這組測試可以確保當不按正確順序進行調用時就會失敗。
負載測試
在適當情況下，可以執行一小組測試來確定這些測試的性能在我們期望的范圍之內。例如，2,000 次調用應該在 2 秒之內完成。
資源測試
這些測試確保應用編程接口(API)可以正確地分配并釋放資源 —— 例如，連續幾次調用打開、寫入以及關閉基于文件的 API，從而確保沒有文件依然是被打開的。
回調測試
對于具有回調方法的 API 來說，這些測試可以確保如果沒有定義回調函數，代碼可以正常運行。另外，這些測試還可以確保在定義了回調函數但是這些回調函數操作有誤或產生異常時，代碼依然可以正常運行。
這是有關單元測試的幾點想法。有關如何編寫單元測試，我也有幾點建議：
不要使用隨機數據
盡管在一個界面中產生隨機數據看起來貌似一個好主意，但是我們要避免這樣做，因為這些數據會變得非常難以調試。如果數據是在每次調用時隨機生成的，那么就可能產生一次測試時出現了錯誤而另外一次測試卻沒有出現錯誤的情況。如果測試需要隨機數據，可以在一個文件中生成這些數據，然后每次運行時都使用這個文件。采用這種方法，我們就獲得了一些 “噪音” 數據，但是仍然可以對錯誤進行調試。
分組測試
我們很容易累積起數千個測試，需要幾個小時才能執行完。這沒什么問題，但是對這些測試進行分組使我們可以快速運行某組測試并對主要關注的問題進行檢查，然后晚上運行完整的測試。
編寫穩健的 API 和穩健的測試
編寫 API 和測試時要注意它們不能在增加新功能或修改現有功能時很容易就會崩潰，這一點非常重要。這里沒有通用的絕招，但是有一條準則是那些 “振蕩的” 測試(一會兒失敗，一會兒成功，反復不停的測試)應該很快地丟棄。
結束語
單元測試對于工程師來說意義重大。它們是敏捷開發過程(這個過程非常強調編碼的作用，因為文檔需要一些證據證明代碼是按照規范進行工作的)的一個基礎。單元測試就提供了這種證據。這個過程從單元測試開始入手，這定義了代碼應該 實現但目前尚未 實現的功能。因此，所有的測試最初都會失敗。然后當代碼接近完成時，測試就通過了。當所有測試全部通過時，代碼也就變得非常完善了。
我從來沒有在不使用單元測試的情況下編寫大型代碼或修改大型或復雜的代碼塊。我通常都是在修改代碼之前就為現有代碼編寫了單元測試，這樣可以確保自己清楚在修改代碼時破壞了什么(或者沒有破壞什么)。這為我對自己提供給客戶的代碼提供了很大的信心，相信它們正在正確運行 —— 即便是在凌晨 3 點。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
