白盒測試技術-單元測試理論篇

白盒測試技術-單元測試理論篇

作者：張元禮
http://blog.csdn.net/vincetest

 

2.1 單元測試概念

• 單元測試：單元測試又稱模組測試，屬於白盒測試，是最小單位的測試。模組分為程式模組和功能模組。功能模組指實現了一個完整功能的模組（單元），一個完整的程式單元具備輸入、加工和輸出三個環節。而且每個程式單元都應該有正規的規格說明，使之對其輸入、加工和輸出的關係做出明確的描述。
• 測試驅動：驅動被測試模組正常運行起來的實體
• 測試樁：代替被測模組調用的子模組的實體，該實體一般為樁函數。
• 測試覆蓋：評測測試過程中已經執行的代碼的多少。
• 覆蓋率：代碼的覆蓋程度，一種度量方式。針對代碼的測試覆蓋率有許多種度量方式，定義如下：

1、語句覆蓋（StatementCoverage）:它度量每一個可執行語句是否被執行到了。
void  DoWork(int x,int y,int z)
{  【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】
   int  k=0,j=0;
   if((x>3)&&(z<10))
   {      
       k=x*y-1;     //語句塊1
       j=sqrt(k);
   }
   if((x= =4)||(y>5))
   {      
       j=x*y+10;   //語句塊2
   }
       j=j%3;      //語句塊3
}

2、判定覆蓋（DecisionCoverage）：它度量是否每個BOOL型的運算式取值true和false在控制結構中都被測試到了。

if(a)   //當a取true和false
{
    ...
}
else
{
    ...
}

 

3、條件覆蓋（ConDItionCoverage）：它獨立的度量每一個子運算式，報告每一個子運算式的結果的true或false。這個度量和判定覆蓋（decisioncoverage）相似，但是對控制流程更敏感。不過，完全的條件覆蓋並不能保證完全的判定覆蓋。

if(a>b&&c>d) 【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】
{
    ...
} 
例子中a>b和c>d為2個不同的條件運算式，與if()判斷獨立。

 

4、路徑覆蓋（PathCoverage）：它度量了是否函數的每一個可能的分支都被執行了。路徑覆蓋的一個好處是：需要徹底的測試。但有兩個缺點：一是，路徑是以分支的指數層級增加的，例如：一個函數包含10個IF語句，就有1024個路徑要測試。如果加入一個IF語句，路徑數就達到2048；二是，許多重路徑不可能與執行的資料無關。

如具有的路徑有：abd、abe、acd、ace

 

5、迴圈覆蓋（LOOPCoverage）：這個度量報告你是否執行了每個迴圈體零次、只有一次還是多餘一次（連續地）。對於do-while迴圈，迴圈覆蓋報告你是否執行了每個迴圈體只有一次還是多餘一次（連續地）。這個度量的有價值的方面是確定是否對於while迴圈和for迴圈執行了多於一次，這個資訊在其它的覆蓋率報告中是沒有的。

for（i=0;i>Max;i++）
{
    ...
}

while（a）
{
    ...
}

do
{
    ...
}
while(a)

• 測試環境構成

1、驅動模組（Driver）：所測模組的主程式。它接收測試資料，把這些資料傳遞給所測試模組，最後再輸出測試結果。當被測試模組能完成一定功能時，也可以不要驅動模組。【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

2、樁模組（Stub）：用來代替所測模組調用的子模組。

 

2.2 單元測試內容

• 單元測試的對象是軟體設計的最小單位——模組或函數;
• 單元測試的依據是詳細設計描述,測試者要根據詳細設計說明書和來源程式清單，瞭解模組的I/O條件和模組的邏輯結構。
• 主要採用白盒測試的測試案例，輔之以黑箱測試的測試案例，使之對任何合理和不合理的輸入都能鑒別和響應。要求對所有的局部和全域的資料結構、外部介面和程式碼的關鍵區段進行案頭檢查和代碼審查。
• 在單元測試中，需要對下面5個方面的內容進行測試，也是構造測試案例的基礎,如：

一、模組介面：測試模組的資料流。如果資料不能正確地輸入和輸出，就談不上進行其他測試。因此，對於模組介面需要如下的測試專案：
1、調用所測模組時的輸入參數與模組的形式參數在個數、屬性、順序上是否匹配；

2、所測模組調用子模組時，它輸入各子模組的參數與子模組的形式參數在個數、屬性、順序上是否匹配；

3、是否修改了只做輸入用的形式參數；

4、輸出給標準函數的參數在個數、屬性、順序上是否匹配；

5、全域變數的定義在各模組中是否一致；

6、限制是否通過形式參數來傳送。

二、局部資料結構測試：模組的局部資料結構是最常見的錯誤來源，應設計測試案例以檢查以下各種錯誤：
1、檢查不正確或不一致的資料類型說明；

2、使用尚未賦值或尚未初始化的變數；

3、錯誤的初始值或錯誤的預設值；

4、變數名拼字錯誤或書寫錯誤；

5、不一致的資料類型。

三、路徑測試：對基本執行路徑和迴圈進行測試會發現大量的錯誤。根據白盒測試和黑箱測試用例設計方法設計測試案例。設計測試案例尋找由於錯誤的計算、不正確的比較或不正常的控制流程而導致的錯誤。

1、常見的不正確的計算有：
1）運算的優先次序不正確或誤解了運算的優先次序；
2）運算的方式錯誤（運算的對象彼此在類型上不相容）；
3）演算法錯誤；【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】
4）初始化不正確；
5）運算精度不夠；
6）運算式的符號表示不正確等。

 

一個案例：火箭爆炸

1996年6月4日歐洲阿麗亞娜系列火箭Ariane-5 發射後僅僅37秒，火箭偏離它的飛行路徑，解體並爆炸。火箭上傳有價值5億美元的通訊衛星，6億美元付之一炬。【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

原因：將一個64位浮點數轉換成16位有符號整數時，產生了溢出。

 

2、常見的比較和控制流程錯誤有：
1）不同資料類型的比較；
2）不正確的邏輯運算子或優先次序；
3）因浮點運算精度問題而造成的兩值比較不等；
4）關聯運算式中不正確的變數和比較符；
5）“差1錯”，即不正確地多迴圈或少迴圈一次；
6）錯誤的或不可能的迴圈終止條件；
7）當遇到發散的迭代時不能終止迴圈；
8）不適當地修改了迴圈變數等。

 

四、錯誤處理測試：比較完善的模組設計要求能預見出錯的條件，並設定適當的出錯處理對策，以便在程式出錯時，能對出錯程式重新做安排，保證其邏輯上的正確性。這種出錯處理也是模組功能的一部分。表明出錯處理模組有錯誤或缺陷的情況有：
1、出錯的描述難以理解；
2、出錯的描述不足以對錯誤定位和確定出錯的原因；
3、顯示的錯誤與實際的錯誤不符；
4、對錯誤條件的處理不正確；
5、在對錯誤進行處理之前，錯誤條件已經引起系統的幹預；
6、如果出錯情況不予考慮，那麼檢查恢複正常後模組可否正常工作。

 

五、邊界測試：邊界上出現錯誤上常見的。設計測試案例檢查：
1、在n次迴圈的第0次、1次、n次是否有錯誤；
2、運算或判斷中取最大最小值時是否有錯誤；
3、資料流、控制流程中剛好等於、大於、小於確定的比較值時是否出現錯誤。
 

2.3 走出測試誤區【文章來源：張元禮的部落格 http://blog.csdn.net/vincetest】

誤區一：完全依賴於測試載入器
誤區二：追求測試環境的真實性
誤區三：盲目提高覆蓋率
誤區四：單元測試太耗時間，不值得一做
誤區五：個人能力強的不必做白盒測試
誤區六：單元測試僅證明該怎麼跑的代碼是這樣跑了
你有這些想法嗎？

 

相關文章：

白盒測試技術-白盒測試理論篇

白盒測試技術-方法與實踐篇

歡迎轉載此文，轉載時請註明文章來源：張元禮的部落格 http://blog.csdn.net/vincetest