問題：
1沒有數據構造和清理的過程
用戶數據，業務數據
2．沒有對業務數據返回和業務邏輯做判斷的一個過程
3. 對於一個業務測試用例單一
4. 方法名比較亂
5.測試方法前沒有註釋
6.重複代碼要重構
單元測試用例目的：
提供覆蓋率：
測試的覆蓋種類
1.語句覆蓋：語句覆蓋就是設計若干個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。
2.判定覆蓋（也叫分支覆蓋）：設計若干個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
3.條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。
4.判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少執行一次。
5.條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。
6.路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。
用例的設計方案主要的有下面幾種：條件測試，基本路徑測試，循環測試。通過上面的方法可以實現測試用例對程序的邏輯覆蓋，和路徑覆蓋。
在開始測試時，要先聲明一下，無論你設計多少測試用例，無論你的測試方案多麼完美，都不可能完全100%的發現所有BUG，我們所需要做的是用最少的資源，做最多測試檢查，
最終目的：通過不通的用例輸入來測試代碼的業務邏輯問題，在版本發佈前提早發現問題。
方式：
所有用例執行後，能覆蓋每行代碼。
如何設計測試用例：
1、瞭解軟件的原始需求(測試目的)
在編寫一個軟件或者模塊的測試用例時候，一定要明白這個功能的原始需求，也就是軟件的使用者(客戶)的需求。理解原始需求後，編寫的測試用例才更有目的性。
2、熟悉軟件的功能需求(測試點)
這個功能需求是指軟件的細化需求點，這個一般在需求文檔裏面都會體現。這裏要做的是把需求穩定的“粗略”的需求，細化成一個個小需求點。
熟悉功能需求後，要知道軟件是怎麼使用的，這也才能覆蓋到各種操作。
總之，測試用例一定要全部覆蓋所以的需求點，這是最基本的一點。
3、熟悉軟件的實現原理(測試點)
在理解原始需求和軟件的功能需求後，軟件有什麼功能，如何使用就基本上都知道啦。這時候在根據需求編寫測試用例，基本上都能覆蓋的比較全面。
在此基礎上，熟悉軟件的實現原理，理解軟件的內部處理。
(1)熟悉原理的過程是進一步深入熟悉軟件的過程。如果單單是從需求點上面覆蓋案例，測試用例只能覆蓋“表面”的一層。一些內部的處理流程也許沒有覆蓋到，
而這些沒有覆蓋到的代碼很可能就是一個風險點。
(2)熟悉模塊原理後，還有一點就是易於分析軟件模塊的關聯性。一個大型的軟件，都是一些小模塊的組合而成。軟件越是大型，耦合就越大。“互相影響”就會越多，
設計用例單單是從模塊本身考慮的話，很可能就會對其他模塊造成風險。
4、用戶場景和網上問題(測試點)
從用戶的使用場景考慮，這些在一些網絡設備比較重要。比如軟件後期在一些真實的使用環境中使用。
還要就是從一些網上問題總結出來的，那些地方容易出錯。在設計案例的時候需要考慮進去
寫好單元測試的建議：
· 一次只測試一個代碼單元
當你試圖測試一個代碼單元，而這個單元有多個用例。
· 不要做無謂的斷言
· 讓每個單元測試保持獨立
· 模擬所有的外部服務和狀態
· 不要使用測試單元配置
· 命名單元測試要清晰一致
· 先爲那些有最少依賴的方法寫單元測試
· 不光是對外暴露的方法，所有方法都應該寫單元測試
· 每個單元測試方法只用一個斷言
· 爲例外和異常創建單元測試
· 使用最合適的斷言方式
· 斷言的參數順序要合適
· 確保測試代碼獨立於生產代碼之外
· 單元測試內不要有任何打印輸出
· 測試類中不要有靜態變量
· 不要寫自己的catch代碼塊，只有test失敗的情況，不存在catch情況
· 不要依賴間接測試
· 使用build腳本整合測試用例
· 不要跳過單元測試
· 使用XML格式化工具捕獲結果
