軟件測試深入淺出單元測試
一 單元測試概述
工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。
其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什么的，這，也是單元測試，老納把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高后期測試和維護成本，也降低了開發商的競爭力�？梢哉f，進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。
對于程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。
要進行充分的單元測試，應專門編寫測試代碼，并與產品代碼隔離。老納認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談老納的看法。
一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以老納的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。
有一種看法是，只測試類的接口(公有函數)，不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫(inline函數)，所有在源文件編寫實現的函數都要進行測試(構造函數和析構函數除外)。
什么時候測試？單元測試越早越好，早到什么程度？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什么后什么，重要的是高效和感覺舒適。從老納的經驗來看，先編寫產品函數的框架，然后編寫測試函數，針對產品函數的功能編寫測試用例，然后編寫產品函數的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函數的框架，是指先編寫函數空的實現，有返回值的隨便返回一個值，編譯通過后再編寫測試代碼，這時，函數名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以后需修改的可能性比較小。
由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。
關于樁代碼，老納認為，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函數或測試函數調用了一個未編寫的函數，可以編寫樁函數來代替該被調用的函數，樁代碼也用于實現測試隔離。采用由底向上的方式進行開發，底層的代碼先開發并先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函數時，也是對下層函數的間接測試；當下層函數修改時，通過回歸測試可以確認修改是否導致上層函數產生錯誤。
二 測試代碼編寫
多數講述單元測試的文章都是以Java為例，本文以C++為例，后半部分所介紹的單元測試工具也只介紹C++單元測試工具。下面的示例代碼的開發環境是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()
{
}
把參數表作為函數名的一部分，這樣當出現重載的被測試函數時，測試函數不會產生命名沖突。下面添加測試用例：
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媒體，它們的預期的結果值都是預期輸出。一個測試用例，就是設定輸入數據，運行被測試函數，然后判斷實際輸出是否符合預期。下面舉一個與成員變量有關的例子：
文章來源于領測軟件測試網 http://www.kjueaiud.com/