單元測試用例編寫總結

1 背景

測試是開發的一個非常重要的方面，可以在很大程度上決定一個應用程序的命運。良好的測試可以在早期捕獲導致應用程序崩潰的問題，但較差的測試往往總是導致故障和停機。

單元測試用于測試各個代碼組件，并確保代碼按照預期的方式工作。單元測試由開發人員編寫和執行。大多數情況下，使用JUnit或TestNG之類的測試框架。測試用例通常是在方法級別寫入并通過自動化執行。

單元測試不僅僅用來保證當前代碼的正確性，更重要的是用來保證代碼修復、改進或重構之后的正確性。

2 單元測試用例相關概念

2.1正面測試（Positive Testing）

測試被測對象的正確功能實現無誤，即正常流程功能。往往需要根據設計說明進行用例導出，嚴格按照設計說明編寫即可，用例劃分注意等價類區分等方法。

2.2負面測試（Negative Testing）

測試被測對象的異常功能實現無誤，多在異常流程，異常數據中體現。該部分測試需要對被測對象進行錯誤發散，常依賴于邊界值區分等方法。

2.3分支測試

使用流程圖，明確可能出現的每條分支，制造響應的數據進行覆蓋，實現對被測對象的測試。這個過程對于分支可以進行響應的簡化，可以穿插等價類等方法去除同類分支。

2.4 邊界值分析法

這種方法更偏向于黑盒測試用例設計中使用，對被測輸入進行邊界分析，從各個角度都會有邊界值，例如程序內部依賴之間，已經有一些邊界存在，在程序集成展示后，也會有新的邊界出現，在設計的時候，需要注意這些細節。例如我們可輸入范圍是3-6，和輸入類型為浮點數。那么邊界值為7-8之間

7 8

| |

?

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

3.1 三原則

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

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

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

Repeative: 所有單元測試用例都要能夠重復運行。能夠重復運行就能夠進行回歸測試、覆蓋率統計等等。

3.2 單元測試任務

一般來說，單元測試任務包括：

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

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

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

（2）變量是否溢出

3、邊界條件測試

（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的邊界

4、所有獨立執行通路測試：保證每一條代碼，每個分支都經過測試

（1）代碼覆蓋率

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

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

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

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

（2）相關軟件

a.Cobertura：語句覆蓋

b.Emma: Eclipse插件Eclemma

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

?

4 注意事項

4.1獨立性

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

4.2盡量脫離被測代碼的束縛

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

4.3面向對象的語言單元測試特點

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

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

?

5 單元測試用例編寫技巧

5.1使用斷言

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

5.2 考慮負面場景

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

5.3 測試結果的預知性

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

1	1	1	1
2	2	2	2

總結

以上是生活随笔為你收集整理的单元测试用例编写总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。