模板
教程
環境
性能
功能
管理
單元測試細節
對于一個代碼單元，首先要測試它的基本功能。功能就是在某種輸入時應該產生某種確定的輸出。對于一個代碼單元，它的可能輸入通常是無窮的，顯然，把輸入的 所有可能取值都進行測試，是不可能也是無意義的，我們應該用一定的規則選擇有代表性的數據來建立測試用例。要考慮的輸入主要有三種：正常輸入，邊界輸入， 非法輸入，每種輸入還可以分類，也就是平常說的等價類法，每類取一個數據作為輸入數據建立測試用例，如果測試通過，可以肯定同類的其他輸入也是可以通過 的。如果等價類的劃分是準確且完整的，并且每一個等價類都進行了測試，那么，可以說這個代碼單元經過了充分的測試。下面舉例說明：
正常輸入
例如字符串的Trim函數，功能是將字符串前后的空格去除，那么正常的輸入可以有四類：前面有空格;后面有空格;前后均有空格;前后均無空格。
邊界輸入
上例中空字符串可以看作是邊界輸入。
再如一個表示年齡的參數，它的有效范圍是0-100，那么邊界輸入有兩個：0和100。
非法輸入
非法輸入是正常取值范圍以外的數據，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數，小于0或大于100都是非法輸入，再如一個進行文件操作的函數，非法輸入有這么幾類：文件不存在;目錄不存在;權限錯誤。
如果輸入有多個數據，還要考慮這些數據之間的關系，即等價類還要包括數據的組合。
要人工找出所有的等價類通常是很困難的，但使用VU，通常不需要這樣做，只要為容易想到的、比較典型的等價類建立測試用例就行了，后文會有進一步的論述。
從上述可以看出，測試用例編輯器可以適應很復雜的測試用例的編輯。只要一個測試用例已編輯完畢，第二個及更多的測試用例就很簡單了：選定一個現有的測 試用例，由系統自動拷貝，用戶再對部分數值進行修改就行了。由于各個測試用例之間的差別通常很小，這種方式可以很快建立測試用例集。
測試用例編輯器還具有代碼模式，很特殊的情況下，可以切換到代碼模式下直接編輯代碼。
這里所說的白盒測試，是指針對程序的邏輯結構來設計測試用例進行測試。白盒測試用邏輯覆蓋率來衡量測試的完整性。邏輯單位主要有：語句、分支、條件、條件 值、條件值組合，路徑。語句覆蓋就是覆蓋所有的語句，其他類推。另外還有一種判定條件覆蓋，其實是分支覆蓋與條件覆蓋的組合，在此不作討論。跟條件有關的 覆蓋就有三種，容易混淆，解釋一下：條件覆蓋是指覆蓋所有的條件表達式，即所有的條件表達式都至少計算一次，不考慮計算結果;條件值覆蓋是指覆蓋條件的所 有可能取值，即每個條件的取真值和取假值都要至少計算一次;條件值組合覆蓋是指覆蓋所有條件取值的所有可能組合。循環結構一般不考慮循環的次數，而只考慮 至少執行循環體一次和不進入循環體兩種情況，即把循環結構看作具有進入循環和不進入循環兩個會支的分支結構。由于不同的覆蓋率具有不同的側重點，為了保證 充分的測試，最好是完成幾種覆蓋率的組合。VU選擇了四種覆蓋的組合作為白盒測試指標：語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋。如果這四種覆蓋都達到了 100%，那么，測試的完整性是非常高的，讀者可以比較一下，在使用VU之前，您的項目要求達到什么樣的白盒覆蓋?實際上又能完成到什么程度?
白盒測試與功能測試有什么關系呢?可以說，如果功能測試是足夠充分的，那么白盒測試就沒有必要，從等價類的角度來看，足夠充分是指，等價類的劃分是完 全正確的，并且所有的等價類都測試到了。如何衡量功能測試的完整性呢?人工審核是一個方法，不過這種方式代價較高，并且仍然不能保證結果的準確性。難于衡 量測試的完整性是功能測試的主要缺陷，而白盒測試恰恰具有易于衡量測試完整性的優點，兩者之間具有極好的互補性。
在單元測試中，功能測試和白盒測試通常具有這樣的關系：如果功能測試足夠充分，那么，所有可以覆蓋的白盒邏輯單位都已經覆蓋，剩下的是不可覆蓋的;反 過來說，如果有一些邏輯單位未覆蓋，并且不能證明該邏輯單位是不可覆蓋的，那么，可以認為功能測試不完整：或者等價類的劃分不夠準確完整，或者有些等價類 未測試到。也就是說，白盒覆蓋指標可以衡量功能測試的完整性，依據某個未覆蓋的邏輯目標，可以發現遺漏的等價類。運行測試后，VU會自動統計白盒覆蓋狀 況，標示出未覆蓋的代碼、條件、分支及路徑，并且提供測試用例設計器來幫助設計可以覆蓋遺漏的邏輯單位的測試用例。只要有了第一個測試用例，測試用例設計 器就能很好地工作。
前面說過，使用VU，能達到100%語句、條件、分支、路徑覆蓋。很多讀者會問，對于稍為復雜一點的程序，路徑就可能幾百上千條，100%覆蓋可能嗎?那要耗費多少資源?
任何程序，不管它有多復雜，都不可能脫離客觀規律和客觀實際。路徑是什么?路徑是代碼的組合，就是程序可能的運行路線。對于一個函數來說，只要輸入確 定了，程序的運行路線就確定了(局部靜態變量是一個特例，它實質上是全局變量，只不過是局部可見而已，因此，也應該看作是一個輸入)。從等價類的角度來 看，一個等價類里所有可能取值，一般來說覆蓋的路徑是一樣的。我們可以大體上認為：程序的可覆蓋路徑的數量與等價類的數量基本相等。例如，一個程序，功能 是輸入人民幣小寫數值，輸出大寫字符串，它的路徑可能有幾百條，但是，我們簡單的想一下，就會發現等價類不會超過十個，因此，大體上可以說，可以覆蓋的路 徑不會超過10條。
至于語句、條件、分支，也可能有一些是不能覆蓋的，這些邏輯目標的處理要比路徑簡單得多。我們說達到100%語句、條件、分支、路徑覆蓋，是指覆蓋可以覆蓋的部分，并把不能覆蓋的部分識別出來并作適當的處理。
VU的測試用例設計器具有兩方面的功能：識別不可覆蓋的邏輯目標，為可覆蓋的邏輯目標設計測試用例。測試用例設計器的工作原理是：從現有的測試用例中 計算出一個最接近于可覆蓋預期邏輯目標的用例作為近似用例，并生成修改提示，依據修改提示對近似測試用例的一個或多個輸入數據(通常是一個)進行修改，并 視需要修改預期輸出，即可獲得可以覆蓋預期邏輯目標的測試用例。修改提示的主要內容是已滿足條件和待滿足條件，已滿足條件是近似測試用例已經滿足的條件， 修改近似測試用例時要保證不破壞已滿足條件，待滿足條件是新的測試用例必須滿足的條件。如果待滿足條件與已滿足條件不沖突，則依據待滿足條件修改近似測試 用例獲得新的測試用例，如果沖突，則該邏輯目標是不可覆蓋的，如果條件提示難于理解，可以切換到代碼模式下，查看程序邏輯。
