如何進行單元測試(2)

　　第七、 檢查常量或全局變量使用的正確性;確定所使用的常量或全局變量的取值和數值、數據類型;保證常量每次引用同它的取值、數值和類型的一致性。

　　第八、 表示符定義的規范一致性;保證變量命名能夠見名知意，并且簡潔但不宜過長或過短、規范、容易記憶、最好能夠拼讀。并盡量保證用相同的表示符代表相同功能，不要將不同的功能用相同的表示符表示;更不要用相同的表示符代表不同的功能意義。

　　第九、程序風格的一致性、規范性;代碼必須能保證符合企業規范，保證所有成員的代碼風格一致、規范、工整。例如對數組做循環，不要一會兒采用下標變量從下到上的方式(如: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)的注釋，應該注釋結果集中包含那些字段及字段類型、字段順序等。

　　4 動態執行跟蹤

　　動態執行測試通常分為黑盒測試與白盒測試。黑盒測試指已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。白盒測試指已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格的要求，所有內部成分是否已經經過檢查。

　　對于單元測試來說主要應該采用白盒測試法對每個模塊的內部作跟蹤檢查測試。對于單元白盒測試，應該對程序模塊進行如下檢查：

　　1. 對模塊內所有獨立的執行路徑至少測試一次;

　　2. 對所有的邏輯判定，取“真”與“假”的兩種情況都至少執行一次;

　　3. 在循環的邊界和運行界限內執行循環體;

　　4. 測試內部數據的有效性等等。

　　單元白盒跟蹤測試，通常需要做如下三項工作:

　　1. 設計測試用例;

　　2. 設計測試類模塊;

　　3. 跟蹤調試。

　　4.1 測試用例設計

　　通常動態執行跟蹤調試是在編碼階段進行的。在對源程序作靜態人工檢查之后就可以開始進行單元測試的測試用例設計。利用設計文檔，設計可以驗證程序功能、找出程序錯誤的多個測試用例。

　　4.1.1 測試用例的設計基本原則

　　設計測試用例基本的原則是：

　　1. 一個好的測試用例在于能夠發現至今沒有發現的錯誤;

　　2. 測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成;

　　3. 在測試用例設計時，應當包含合理的輸入條件和不合理的輸入條件。

　　4.1.2 白盒測試的測試用例設計

　　白盒測試測試用例一般采用邏輯覆蓋法和基本路徑法進行設計。

　　一、邏輯覆蓋法

　　邏輯覆蓋是以程序內部的邏輯結構為基礎的測試用例設計技術，這一方法要求測試人員對程序的邏輯結構有清楚的了解。邏輯覆蓋可分為：語句覆蓋、判定覆蓋、條件覆蓋、判定-條件覆蓋、條件組合覆蓋與路徑覆蓋。

原文轉自：http://www.anti-gravitydesign.com