單元測試基礎知識（二）

6 單元測試設計原則和任務

6.1 三原則

爲了提升開發人員的代碼質量，編寫高質量的單元測試，要遵照3R（Responsible, Reliable, Repeative）原則，具體含義以下：

 

Responsible: 誰開發誰負責測試，在哪裏開發就在哪裏測試。

 

Reliable: 測試case要可靠，而且是值得信賴的，對於底層的任何改動都要可以及時感知。

 

Repeative: 全部單元測試用例都要可以重複運行。可以重複運行就可以進行迴歸測試、覆蓋率統計等等。

 

6.2 單元測試任務

通常來講，單元測試任務包括：

 

一、接口功能測試：用來保證接口功能的正確性。

 

二、局部數據結構測試（不經常使用）：用來保證接口中的數據結構是正確的

 

（1）好比變量有無初始值

 

（2）變量是否溢出

 

三、邊界條件測試

 

（1）變量沒有賦值（即爲NULL）

 

（2）變量是數值（或字符)

 

a.主要邊界：最小值，最大值，無窮大（對於DOUBLE等）

 

b.溢出邊界（指望異常或拒絕服務）：最小值-1，最大值+1

 

c.臨近邊界：最小值+1，最大值-1

 

（3）變量是字符串

 

a.引用"字符變量"的邊界

 

b.空字符串

 

c.對字符串長度應用"數值變量"的邊界

 

（4）變量是集合

 

a.空集合

 

b.對集合的大小應用"數值變量"的邊界

 

c.調整次序：升序、降序

 

（5）變量有規律

 

a.好比對於Math.sqrt，給出n^2-1，和n^2+1的邊界

 

四、全部獨立執行通路測試：保證每一條代碼，每一個分支都通過測試

 

（1）代碼覆蓋率

 

a.語句覆蓋：保證每個語句都執行到了

 

b.斷定覆蓋（分支覆蓋）：保證每個分支都執行到

 

c.條件覆蓋：保證每個條件都覆蓋到true和false（即if、while中的條件語句）

 

d.路徑覆蓋：保證每個路徑都覆蓋到

 

（2）相關軟件

 

a.Cobertura：語句覆蓋

 

b.Emma: Eclipse插件Eclemma

 

五、各條錯誤處理通路測試：保證每個異常都通過測試

 

 

 

7 單測用例設計注意事項

7.1獨立性

單元測試用例在設計和數據準備的過程當中，須要保持良好的獨立性，確保本測試的數據是不須要依賴其餘輸出的，這樣減小相互影響。

 

7.2儘可能脫離被測代碼的束縛

在測試用例設計的過程當中，尤爲是測試用例編寫在代碼編寫完成後進行的，必定當心被代碼實現功能所影響，多考慮異常分支和異常數據。

 

7.3面向對象的語言單元測試特色

面向對象的語言進行單元測試還有必定的特色，對於每個類，可能他出如今程序中的狀況各不相同，在進行測試的時候，能夠結合上面介紹的方法，根據內部方法相互調用邏輯，完成測試設計。

 

大致劃分兩個方向，一個是功能性的，就是相似黑盒的方法，僅僅關注實現的功能點是否正確；另外一個就是結構性測試，須要分析類中的方法相互實現邏輯，進行相似白盒測試，確保每一個分支覆蓋。

 

 

 

8 單元測試用例編寫技巧

8.1使用斷言

使用斷言而不是Print語句許多新手開發人員習慣於在每行代碼以後編寫System.out.println語句來驗證代碼是否正確執行。這種作法經常擴展到單元測試，從而致使測試代碼變得雜亂。除了混亂，這須要開發人員手動干預去驗證控制檯上打印的輸出，以檢查測試是否成功運行。更好的方法是使用自動指示測試結果的斷言。

8.2 考慮負面場景

除了正面情景，還要測試負面情景和邊緣狀況一般，開發人員會花費大量的時間和精力編寫測試用例，以確保應用程序按預期工做。然而，測試負面測試用例也很重要。負面測試用例指的是測試系統是否能夠處理無效數據的測試用例。

 

8.3 測試結果的預知性

構建具備肯定性結果的測試，一些方法不具備肯定性結果，即該方法的輸出不是預先知道的，而且每一次均可以改變，爲該方法編寫測試用例不會有任何用處。