深入淺出單元測試

一　單元測試概述

　　工廠在組裝一台電視機之前，會對每個元件都進行測試，這，就是單元測試。

　　其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些資料，如彈出資訊視窗什麼的，這，也是單元測試，老納把這種單元測試稱為臨時單元測試。隻進行了臨時單元測試的軟體，針對代碼的測試很不完整，代碼覆寫率要超過70%都很困難，未覆寫的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高後期測試和維護成本，也降低了開發商的競争力。可以說，進行充分的單元測試，是提高軟體品質，降低開發成本的必由之路。

　　對于程式員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高品質的代碼，而且還能提高程式設計水準。

　　多數講述單元測試的文章都是以Java為例，本文以C++為例，後半部分所介紹的單元測試工具也隻介紹C++單元測試工具。

　　要進行充分的單元測試，應專門編寫測試代碼，并與産品代碼隔離。老納認為，比較簡單的辦法是為産品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談老納的看法。

　　一般認為，在結構化程式時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試的所說的單元是指類。老納認為，以類作為測試機關，複雜度高，可操作性較差，是以仍然應以函數作為單元測試的測試機關，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

　　有一種看法是，隻測試類的接口(公有函數)，不測試其他函數，從面向對象角度來看，似乎有些道理。老納認為，測試的目的是找錯并最終排錯，是以，隻要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如資料讀寫函數的實作在頭檔案中編寫(inline函數)，所有在源檔案編寫實作的函數都要進行測試(構造函數和析構函數除外)。

　　什麼時候測試？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。老納認為，不必過分強調先什麼後什麼，重要的是高效和感覺舒适。從老納的經驗來看，先編寫産品函數的架構，然後編寫測試函數，針對産品函數的功能編寫測試用例，然後編寫産品函數的代碼，每寫一個功能點都運作測試，随時補充測試用例。所謂先編寫産品函數的架構，是指先編寫函數空的實作，有傳回值的随便傳回一個值，編譯通後再編寫測試代碼，這時，函數名、參數表、傳回類型都應該确定下來了，所編寫的測試代碼以後需修改的可能性比較小。

　　由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程式員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，送出産品代碼時也要同時送出測試代碼。測試部門可以作一定程度的稽核。

　　關于樁代碼，老納認為，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，産品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用于實作測試隔離。采用由底向上的開發方式進行開發，先開發的代碼先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，通過回歸測試可以确認修改是否導緻上層函數産生錯誤。

二　測試代碼編寫

　　下面該說說如果編寫測試代碼了，以一個例子來說明，開發環境是VC6.0。

産品類：

class CMyClass 

{

public:

int Add(int i, int j);

CMyClass();

virtual ~CMyClass();

private:

int mAge; //年齡

CString mPhase; //年齡階段，如"少年"，"青年"

};

建立對應的測試類CMyClassTester，為了節約編幅，隻列出源檔案的代碼：

void CMyClassTester::CaseBegin()

//pObj是CMyClassTester類的成員變量，是被測試類的對象的指針，

//為求簡單，所有的測試類都可以用pObj命名被測試對象的指針。

pObj = new CMyClass();

}

void CMyClassTester::CaseEnd()

delete pObj;

測試類的函數CaseBegin()和CaseEnd()建立和銷毀被測試對象，每個測試用例的開頭都要調用CaseBegin()，結尾都要調用CaseEnd()。

接下來，我們建立示例的産品函數：

int CMyClass::Add(int i, int j)

return i+j;

和對應的測試函數：

void CMyClassTester::Add_int_int()

把參數表作為函數名的一部分，這樣當出現重載的被測試函數時，測試函數不會産生命名沖突。下面添加測試用例：

//第一個測試用例

CaseBegin();{ //1

int i = 0; //2

int j = 0; //3

int ret = pObj->Add(i, j); //4

ASSERT(ret == 0); //5

}CaseEnd(); //6

第1和第6行建立和銷毀被測試對象，所加的{}是為了讓每個測試用例的代碼有一個獨立的域，以便多個測試用例使用相同的變量名。

第2和第3行是定義輸入資料，第4行是調用被測試函數，這些容易了解，不作進一步解釋。第5行是預期輸出，它的特點是當實際輸出與預期輸出不同時自動報錯，ASSERT是VC的斷言宏，也可以使用其他類似功能的宏，使用測試工具進行單元測試時，可以使用該工具定義的斷言宏。

　　示例中的格式顯得很不簡潔，2、３、4、5行可以合寫為一行：ASSERT(pObj->Add(0, 0) == 0);但這種不簡潔的格式卻是老納極力推薦的，因為它一目了然，易于建立多個測試用例，并且具有很好的适應性，同時，也是極佳的代碼文檔，總之，老納建議：輸入資料和預期輸出要自成一塊。

　　建立了第一個測試用例後，應編譯并運作測試，以排除文法錯誤，然後，使用拷貝已有的測試用例并進行修改的辦法建立其他測試用例。由于各個測試用例之間的差别往往很小，通常隻需修改一兩個資料，拷貝修改是最快的建立多個測試用例的辦法。

三　測試用例

　　下面說說測試用例、輸入資料及預期輸出。輸入資料是測試用例的核心，老納對輸入資料的定義是：被測試函數所讀取的外部資料及這些資料的初始值。外部資料是對于被測試函數來說的，實際上就是除了局部變量以外的其他資料，老納把這些資料分為幾類：參數、成員變量、全局變量、IO媒體。IO媒體是指檔案、資料庫或其他儲存或傳輸資料的媒體，例如，被測試函數要從檔案讀取資料，那麼，檔案中的原始資料也屬于輸入資料。一個函數無論多複雜，都無非是對這幾類資料的讀取、計算和寫入。預期輸出是指：傳回值及被測試函數所寫入的外部資料的結果值。傳回值就不用說了，被測試函數進行了寫操作的參數(輸出參數)、成員變量、全局變量、IO媒體，它們的預期的結果值都是預期輸出。一個測試用例，就是設定輸入資料，運作被測試函數，然後判斷實際輸出是否符合預期。下面舉一個與成員變量有關的例子：

産品函數：

void CMyClass::Grow(int years)

mAge += years;

if(mAge < 10)

mPhase = "兒童";

else if(mAge <20)

mPhase = "少年";

else if(mAge <45)

mPhase = "青年";

else if(mAge <60)

mPhase = "中年";

else

mPhase = "老年";

測試函數中的一個測試用例：

CaseBegin();{

int years = 1;

pObj->mAge = 8;

pObj->Grow(years);

ASSERT( pObj->mAge == 9 );

ASSERT( pObj->mPhase == "兒童" );

}CaseEnd();

在輸入資料中對被測試類的成員變量mAge進行指派，在預期輸出中斷言成員變量的值。現在可以看到老納所推薦的格式的好處了吧，這種格式可以适應很複雜的測試。在輸入資料部分還可以調用其他成員函數，例如：執行被測試函數前可能需要讀取檔案中的資料儲存到成員變量，或需要連接配接資料庫，老納把這些操作稱為初始化操作。例如，上例中 ASSERT( ...)之前可以加pObj->OpenFile();。為了通路私有的成員變量或成員函數，可以将測試類定義為産品類的友元類。例如，定義一個宏：

#define UNIT_TEST(cls) friend class cls##Tester;

然後在産品類聲明中加一行代碼：UNIT_TEST(ClassName)。

　　下面談談測試用例設計。前面已經說了，測試用例的核心是輸入資料。預期輸出是依據輸入資料和程式功能來确定的，也就是說，對于某一程式，輸入資料确定了，預期輸出也就可以确定了，至于生成/銷毀被測試對象和運作測試的語句，是所有測試用例都大同小異的，是以，我們讨論測試用例時，隻讨論輸入資料。

　　前面說過，輸入資料包括四類：參數、成員變量、全局變量、IO媒體，這四類資料中，隻要所測試的程式需要執行讀操作的，就要設定其初始值，其中，前兩類比較常用，後兩類較少用。顯然，把輸入資料的所有可能取值都進行測試，是不可能也是無意義的，我們應該用一定的規則選擇有代表性的資料作為輸入資料，主要有三種：正常輸入，邊界輸入，非法輸入，每種輸入還可以分類，也就是平常說的等價類法，每類取一個資料作為輸入資料，如果測試通過，可以肯定同類的其他輸入也是可以通過的。下面舉例說明： 

　　正常輸入

　　例如字元串的Trim函數，功能是将字元串前後的空格去除，那麼正常的輸入可以有四類：前面有空格；後面有空格；前後均有空格；前後均無空格。

　　邊界輸入

　　上例中空字元串可以看作是邊界輸入。

　　再如一個表示年齡的參數，它的有效範圍是0-100，那麼邊界輸入有兩個：0和100。

　　非法輸入

　　非法輸入是正常取值範圍以外的資料，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數，小于0或大于100都是非法輸入，再如一個進行檔案操作的函數，非法輸入有這麼幾類：檔案不存在；目錄不存在；檔案正在被其他程式打開；權限錯誤。

　　如果函數使用了外部資料，則正常輸入是肯定會有的，而邊界輸入和非法輸入不是所有函數都有。一般情況下，即使沒有設計文檔，考慮以上三種輸入也可以找出函數的基本功能點。實際上，單元測試與代碼編寫是“一體兩面”的關系，編碼時對上述三種輸入都是必須考慮的，否則代碼的鍵壯性就會成問題。

四　白盒覆寫

　　上面所說的測試資料都是針對程式的功能來設計的，就是所謂的黑盒測試，另外，單元測試還需要從另一個角度來設計測試資料，即針對程式的邏輯結構來設計測試用例，就是所謂的白盒測試。在老納看來，如果黑盒測試是足夠充分的，那麼白盒測試就沒有必要，可惜“足夠充分”隻是一種理想狀态，例如：真的是所有功能點都測試了嗎？程式的功能點是人為的定義，常常是不全面的；各個輸入資料之間，有些組合可能會産生問題，怎樣保證這些組合都經過了測試？難于衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易于衡量測試完整性的優點，兩者之間具有極好的互補性，例如：完成功能測試後統計語句覆寫率，如果語句覆寫未完成，很可能是未覆寫的語句所對應的功能點未測試。

　　白盒測試針對程式的邏輯結構設計測試用例，用邏輯覆寫率來衡量測試的完整性。邏輯機關主要有：語句、分支、條件、條件值、條件值組合，路徑。語句覆寫就是覆寫所有的語句，其他類推。另外還有一種判定條件覆寫，其實是分支覆寫與條件覆寫的組合，在此不作讨論。跟條件有關的覆寫就有三種，解釋一下：條件覆寫是指覆寫所有的條件表達式，即所有的條件表達式都計算了，不考慮計算結果；條件值覆寫是指覆寫條件的所有可能取值，即每個條件的取真值和取假值都要計算一次；條件值組合覆寫是指覆寫所有條件取值的所有可能組合。老納做過一些粗淺的研究，發現與條件直接有關的錯誤主要是邏輯操作符錯誤，例如：||寫成&&，漏了寫!什麼的，采用分支覆寫與條件覆寫的組合，基本上可以發現這些錯誤，另一方面，條件值覆寫與條件值組合覆寫往往需要大量的測試用例，是以，在老納看來，條件值覆寫和條件值組合覆寫的效費比偏低。老納認為效費比較高且完整性也足夠的測試要求是這樣的：完成功能測試，完成語句覆寫、條件覆寫、分支覆寫、路徑覆寫。做過單元測試的朋友恐怕會對老納提出的測試要求給予一個字的評價：暈！或者兩個字的評價：狂暈！因為這似乎是不可能的要求，要達到這種測試完整性，其測試成本是不可想象的，不過，出家人不打逛語，老納之是以提出這種測試要求，是因為利用一些工具，可以在較低的成本下達到這種測試要求，後面将會作進一步介紹。

　　關于白盒測試用例的設計，程式測試領域的書籍一般都有講述，普通方法是畫出程式的邏輯結構圖如程式流程圖或控制流圖，根據邏輯結構圖設計測試用例，這些是純粹的白盒測試，不是老納想推薦的方式。老納所推薦的方法是：先完成黑盒測試，然後統計白盒覆寫率，針對未覆寫的邏輯機關設計測試用例覆寫它，例如，先檢查是否有語句未覆寫，有的話設計測試用例覆寫它，然後用同樣方法完成條件覆寫、分支覆寫和路徑覆寫，這樣的話，既檢驗了黑盒測試的完整性，又避免了重複的工作，達到非常高的測試完整性。不過，這些工作可不是手工能完成的，必須借助于工具，後面會介紹可以完成這些工作的測試工具。

五　單元測試工具

　　現在開始介紹單元測試工具，老納隻介紹三種，都是用于C++語言的。

　　然後介紹C++Test，這是Parasoft公司的産品。［C++Test是一個功能強大的自動化C/C++單元級測試工具，可以自動測試任何C/C++函數、類，自動生成測試用例、測試驅動函數或樁函數，在自動化的環境下極其容易快速的将單元級的測試覆寫率達到100%］。［］内的文字引自http://www.superst.com.cn/softwares_testing_c_cpptest.htm，這是華唐公司的網頁。老納想寫些介紹C++Test的文字，但發現無法超越華唐公司的網頁上的介紹，是以也就省點事了，想了解C++Test的朋友，建議通路該公司的網站。華唐公司代理C++Test，想要購買或索取報價、試用版都可以找他們。老納幫華唐公司做廣告，不知道會不會得點什麼好處？

　　最後介紹Visual Unit，簡稱VU，這是國産的單元測試工具，據說申請了多項專利，擁有一批創新的技術，不過老納隻關心是不是有用和好用。［自動生成測試代碼 快速建立功能測試用例 程式行為一目了然 極高的測試完整性 高效完成白盒覆寫 快速排錯 高效調試 詳盡的測試報告］。［］内的文字是VU開發商的網頁上摘錄的，網址是：http://www.unitware.cn。前面所述測試要求：完成功能測試，完成語句覆寫、條件覆寫、分支覆寫、路徑覆寫，用VU可以輕松實作，還有一點值得一提：使用VU還能提高編碼的效率，總體來說，在完成單元測試的同時，編碼調試的時間可能還會縮短。算了，不想再講了，老納顯擺理論、介紹經驗還是有興趣的，因為可以滿足老納好為人師的虛榮心，但介紹工具就覺得索然無味了，畢竟工具好不好用，合不合用，要試過才知道，還是自己去開發商的網站看吧，可以下載下傳示範版，還有示範課件，老納念經去也，阿彌陀佛。