如何进行单元测试
單元測試是針對軟件設計的最小單位——程序模塊，進行正確性檢驗的測試工作。其目的在于發現每個程序模塊內部可能存在的差錯。
單元測試也是程序員的一項基本職責，程序員必須對自己所編寫的代碼保持認真負責的態度，這是也程序員的基本職業素質之一。同時單元測試能力也是程序員的一項基本能力，能力的高低直接影響到程序員的工作效率與軟件的質量。
在編碼的過程中作單元測試，其花費是最小的，而回報卻特別優厚的。在編碼的過程中考慮測試問題，得到的將是更優質的代碼，因為在這時您對代碼應該做些什么 了解得最清楚。如果不這樣做，而是一直等到某個模塊崩潰了，到那時您可能已經忘記了代碼是怎樣工作的。即使是在強大的工作壓力下，您也還必須重新把它弄清 楚，這又要花費許多時間。進一步說，這樣做出的更正往往不會那么徹底，可能更脆弱，因為您喚回的理解可能不那么完全。
通常合格的代碼應該具備以下性質：正確性、清晰性、規范性、一致性、高效性等（根據優先級別排序）。
1. 正確性是指代碼邏輯必須正確，能夠實現預期的功能。
2. 清晰性是指代碼必須簡明、易懂，注釋準確沒有歧義。
3. 規范性是指代碼必須符合企業或部門所定義的共同規范包括命名規則，代碼風格等等。
4. 一致性是指代碼必須在命名上（如：相同功能的變量盡量采用相同的標示符）、風格上都保持統一。
5. 高效性是指代碼不但要滿足以上性質，而且需要盡可能降低代碼的執行時間。
2 單元測試步驟
在代碼編寫完成后的單元測試工作主要分為兩個步驟人工靜態檢查和動態執行跟蹤。
人工靜態檢查是測試的第一步，這個階段工作主要是保證代碼算法的邏輯正確性（盡量通過人工檢查發現代碼的邏輯錯誤）、清晰性、規范性、一致性、算法高效性。并盡可能的發現程序中沒有發現的錯誤。
第二步是通過設計測試用例，執行待測程序來跟蹤比較實際結果與預期結果來發現錯誤。經驗表明，使用人工靜態檢查法能夠有效的發現30%到70%的邏輯設計 和編碼錯誤。但是代碼中仍會有大量的隱性錯誤無法通過視覺檢查發現，必須通過跟蹤調試法細心分析才能夠捕捉到。所以，動態跟蹤調試方法也成了單元測試的重 點與難點。
3 人工檢查
通常在人工檢查階段必須執行以下項目的活動：
第一、 檢查算法的邏輯正確性；確定所編寫的代碼算法、數據結構定義（如：隊列、堆棧等）是否實現了模塊或方法所要求的功能。
第二、 模塊接口的正確性檢查；確定形式參數個數、數據類型、順序是否正確；確定返回值類型及返回值的正確性。
第三、 輸入參數有沒有作正確性檢查；如果沒有作正確性檢查，確定該參數是否的確無需做參數正確性檢查，否則請添加上參數的正確性檢查。經驗表明，缺少參數正確性檢查的代碼是造成軟件系統不穩定的主要原因之一。
第四、 調用其他方法接口的正確性；檢查實參類型正確與否、傳入的參數值正確與否、個數正確與否，特別是具有多態的方法。返回值正確與否，有沒有誤解返回值所表示 的意思。最好對每個被調用的方法的返回值用顯濕代碼作正確性檢查，如果被調用方法出現異常或錯誤程序應該給予反饋，并添加適當的出錯處理代碼。
第五、 出錯處理；模塊代碼要求能預見出錯的條件，并設置適當的出錯處理，以便在一旦程序出錯時，能對出錯程序重做安排，保證其邏輯的正確性，這種出錯處理應當是 模塊功能的一部分。若出現下列情況之一，則表明模塊的錯誤處理功能包含有錯誤或缺陷：出錯的描述難以理解；出錯的描述不足以對錯誤定位，不足以確定出錯的 原因；顯示的錯誤信息與實際的錯誤原因不符；對錯誤條件的處理不正確；在對錯誤進行處理之前，錯誤條件已經引起系統的干預等。
第六、 保證表達式、SQL語句的正確性；檢查所編寫的SQL語句的語法、邏輯的正確性。對表達式應該保證不含二義性，對于容易產生歧義的表達式或運算符優先級 （如：《 、=、 》、 &&、||、++、 --等）可以采用擴號“（）”運算符避免二義性，這樣一方面能夠保證代碼的正確可靠，同時也能夠提高代碼的可讀性。
第七、 檢查常量或全局變量使用的正確性；確定所使用的常量或全局變量的取值和數值、數據類型；保證常量每次引用同它的取值、數值和類型的一致性。
第八、 表示符定義的規范一致性；保證變量命名能夠見名知意，并且簡潔但不宜過長或過短、規范、容易記憶、最好能夠拼讀。并盡量保證用相同的表示符代表相同功能，不要將不同的功能用相同的表示符表示；更不要用相同的表示符代表不同的功能意義。
第九、 程序風格的一致性、規范性；代碼必須能保證符合企業規范，保證所有成員的代碼風格一致、規范、工整。例如對數組做循環，不要一會兒采用下標變量從下到上的 方式（如：for（I=0；I++；I<10）），一會兒又采用從上到下的方式（如：for（I=10；I--；I>0））；應該盡量采用統 一的方式，或則統一從下到上，或則統一從上到下。建議采用for循環和While循環，不要采用do{}while循環等。
第十、 檢查程序中使用到的神秘數字是否采用了表示符定義。神秘的數字包括各種常數、數組的大小、字符位置、變換因子以及程序中出現的其他以文字形式寫出的數值。 在程序源代碼里，一個具有原本形式的數對其本身的重要性或作用沒提供任何指示性信息，它們也導致程序難以理解和修改。對于這類神秘數字必須采用相應的標量 來表示；如果該數字在整個系統中都可能使用到務必將它定義為全局常量；如果該神秘數字在一個類中使用可將其定義為類的屬性（Attribute），如果該 神秘數字只在一個方法中出現務必將其定義為局部變量或常量。
第十一、 檢查代碼是否可以優化、算法效率是否最高。如：SQL語句是否可以優化，是否可以用1條SQL語句代替程序中的多條SQL語句的功能，循環是否必要，循環中的語句是否可以抽出到循環之外等。
第十二、 檢查您的程序是否清晰簡潔容易理解。注意：冗長的程序并不一定不是清晰的。
第十三、 檢查方法內部注釋是否完整；是否清晰簡潔；是否正確的反映了代碼的功能，錯誤的注釋比沒有注釋更糟；是否做了多余的注釋；對于簡單的一看就懂的代碼沒有必要注釋。
第十四、 檢查注釋文檔是否完整；對包、類、屬性、方法功能、參數、返回值的注釋是否正確且容易理解；是否會落了或多了某個參數的注釋，參數類型是否正確，參數的限 定值是否正確。特別是對于形式參數與返回值中關于神秘數值的注釋，如：類型參數 應該指出 1.代表什么，2.代表什么，3.代表什么等。對于返回結果集（Result Set）的注釋，應該注釋結果集中包含那些字段及字段類型、字段順序等。
?
二、基本路徑法
基本路徑測試法是在程序控制流圖的基礎上，通過分析控制構造的環路復雜性，導出基本可執行路徑集合，從而設計測試用例的方法。設計出的測試用例要保證在測試中程序的每個可執行語句至少執行一次。基本路徑測試法包括以下5個方面：
1. 程序的控制流圖：描述程序控制流的一種圖示方法。
2. 程序環境復雜性：McCabe復雜性度量；從程序的環路復雜性可導出程序基本路徑集合中的獨立路徑條數，這是確定程序中每個可執行語句至少執行依次所必須的測試用例數目的上界。
3. 導出測試用例。
4. 準備測試用例，確保基本路徑集中的每一條路徑的執行。
5. 圖形矩陣：是在基本路徑測試中起輔助作用的軟件工具，利用它可以實現自動地確定一個基本路徑集。
另外，對于測試用例的選擇除了滿足所選擇的覆蓋程度（或覆蓋標準）外還需要盡可能的采用邊界值分析法、錯誤推測法等常用地設計方法。采用邊界值分析法設計 合理的輸入條件與不合理的輸入條件；條件邊界測試用例應該包括輸入參數的邊界與條件邊界（if，while，for，switch ，SQL Where子句等）。錯誤推測法，列舉出程序中所有可能的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例；在編碼、單元測試階段可以發現很多常見的 錯誤和疑似錯誤，對于這些錯誤應該作重點測試，并設計相應的測試用例。
4.1.3 單元測試計劃表格
在設計測試用例時可以參考如下表格，擬定對每個類（或模塊或包）的測試計劃。表1，是對每個類（或模塊或包）作測試計劃的表頭，它指明本測試計劃是針對那個模塊及相關文件的。表2是針對表1指定模塊測試用例而對應的子表，每個測試用例可以擁有一個子表；單元測試結果子表留作執行測試用例時根據實際結果填寫。
子系統名. PackageName. JavaClassName
| 單元測試計劃 | |
| 標識 | 格式： “子系統名. jsp_filename（含目錄中間用\分開即可）” 或者 “子系統名. PackageName. JavaClassName” |
| 組件功能項 | 如：組件完成 “新增貼子”的功能 |
| 針對概要/詳細設計文件名 | 如：1.1版本公告部分詳細設計說明書 |
| 物理文件名 | jsp_filename（含目錄）； packageName. JavaClassName |
表1
單元測試子項001
下面表格為針對上面表格“子系統名. PackageName. JavaClassName”而對應的子表，每個測試用例用一張子表：
| 編號 | .001 注：“. 編號” 部分要從001編號開始一直到999，個人自行編號 |
| 程序設計人員 | 如：XXX |
| 測試人員 | 如：XXX |
| 測試目的 | 如：對錯誤邏輯輸入檢驗 |
| 測試內容描述 | 如：對于public int fun3（String p1, int p2 ）的輸入檢驗，如果 p1 == null，程序中檢驗到，應該記錄到系統 logfile, return –1; |
| 輸入期望 | P1 == null |
| 功能處理期望描述 | Logfile 多一條歷史記錄，方法return -1； |
| 輸出期望 | Return –1 |
| 單元測試結果 | |
| 實際輸入數據 | P1 = null |
| 實際處理情況描述 | 程序沒有進行p1 == null 的驗證，沒有及時return –1，而是運行到 p1.aaa( ) 方法時出現 null pointer 異常。 |
| 實際輸出 | 沒有寫 logfile 文件； |
| 測試結論 | 正常 / 異常 |
表2
?
轉載于:https://www.cnblogs.com/zzp28/articles/1610620.html
總結
- 上一篇： Linq to xml API中 XNa
- 下一篇： jsp_servlet时序图