单元测试用例编写总结
單元測試用例編寫總結
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 |
總結
以上是生活随笔為你收集整理的单元测试用例编写总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 《查理·芒格的100个思维模型》
- 下一篇： EvoSuite生成单元测试用例