模組測試是對系統賦有明顯功能的最小粒度的測試，是對一個模組進行測試，根據模組的功能說明，檢驗模組是否有錯誤。這種測試在各模組編程後進行。模組測試一般由編程人員自己進行。
模組測試很多人員認為是單元測試，其實還是有區別的，單元測試主要為，代碼塊，單元接口，類，方法，函式等，而模組測試更強調的是一個或者一塊功能是完整的，可以獨立的功能區域進行測試，這可能有幾個單元代碼組成。
基本介紹
- 中文名：模組測試
- 外文名：Module Testing
- 定義：每個模組作為一個單元能正確運行
- 缺點：成本效率不高
定義,單元測試,結構化程式時代,單元測試與使用,單元測試的誤解,單元測試過程,成本效率不高,一些圖表,結論,單元測試的優點,工作範疇,不寫測試的藉口,測試代碼編寫,測試用例,產品函式,白盒覆蓋,設計測試用例,單元測試工具,
定義
單元測試（模組測試）是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函式的行為。例如，你可能把一個很大的值放入一個有序list 中去，然後確認該值出現在list 的尾部。或者，你可能會從字元串中刪除匹配某種模式的字元，然後確認字元串確實不再包含這些字元了。
單元測試（模組測試）是由程式設計師自己來完成，最終受益的也是程式設計師自己。可以這么說，程式設計師有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
工廠在組裝一台電視機之前，會對每個元件都進行測試，這，就是單元測試。
其實我們每天都在做單元測試。你寫了一個函式，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息視窗什麼的，這，也是單元測試，把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟體，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難於調試，大幅度提高后期測試和維護成本，也降低了開發商的競爭力。可以說，進行充分的單元測試，是提高軟體質量，降低開發成本的必由之路。
對於程式設計師來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。
單元測試
結構化程式時代
單元測試與使用
我們編寫代碼時，一定會反覆調試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會願意交付給自己的老闆。但代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。
幸運，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的後顧之憂。
- 什麼時候測試？
單元測試越早越好，早到什麼程度？XP開發理論講究TDD，即測試驅動開發，先編寫測試代碼，再進行開發。在實際的工作中，可以不必過分強調先什麼後什麼，重要的是高效和感覺舒適。先編寫產品函式的框架，然後編寫測試函式，針對產品函式的功能編寫測試用例，然後編寫產品函式的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產品函式的框架，是指先編寫函式空的實現，有返回值的隨便返回一個值，編譯通過後再編寫測試代碼，這時，函式名、參數表、返回類型都應該確定下來了，所編寫的測試代碼以後需修改的可能性比較小。
- 由誰測試？
單元測試與其他測試不同，單元測試可看作是編碼??過了單元測試的代碼才是已完成的代碼，提交產品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。
關於樁代碼，單元測試應避免編寫樁代碼。樁代碼就是用來代替某些代碼的代碼，例如，產品函式或測試函式調用了一個未編寫的函式，可以編寫樁函式來代替該被調用的函式，樁代碼也用於實現測試隔離。採用由底向上的方式進行開發，底層的代碼先開發並先測試，可以避免編寫樁代碼，這樣做的好處有：減少了工作量；測試上層函式時，也是對下層函式的間接測試；當下層函式修改時，通過回歸測試可以確認修改是否導致上層函式產生錯誤。
在一種傳統的結構化程式語言中，比如C，要進行測試的單元一般是函式或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發人員可以選擇是在獨立的過程和函式，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發中，在這裡基本單元被典型地劃分為一個選單或顯示界面。
單元測試不僅僅是作為無錯編碼一種輔助手段在一次性的開發過程中使用，單元測試必須是可重複的，無論是在軟體修改，或是移植到新的運行環境的過程中。因此，所有的測試都必須在整個軟體系統的生命周期中進行維護。
經常與單元測試聯繫起來的另外一些開發活動包括代碼走讀(Code review)，靜態分析(Static analysis)和動態分析(Dynamic analysis)。靜態分析就是對軟體的原始碼進行研讀，查找錯誤或收集一些度量數據，並不需要對代碼進行編譯和執行。動態分析就是通過觀察軟體運行時的動作，來提供執行跟蹤，時間分析，以及測試覆蓋度方面的信息。
單元測試的誤解
一旦編碼完成，開發人員總是會迫切希望進行軟體的集成工作，這樣他們就能夠看到實際的系統開始啟動工作了。 這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統進行聯調這種真正有意思的工作啟動的時間。
在這種開發步驟中，真實意義上的進步被外表上的進步取代了。系統能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實踐中，這樣一種開發步驟常常會導致這樣的結果：軟體甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導致在軟體集成為一個系統時增加額外的工期， 而且當這個系統投入使用時也無法確保它能夠可靠運行。
在實踐工作中，進行了完整計畫的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩定可靠的部件的情況下，開發人員能夠進行更高效的系統集成工作。這才是真實意義上的進步，所以說完整計畫下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。
使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。
它僅僅是證明這些代碼做了什麼
這是那些沒有首先為每個單元編寫一個詳細的規格說明而直接跳到編碼階段的開發人員提出的一條普遍的抱怨， 當編碼完成以後並且面臨代碼測試任務的時候，他們就閱讀這些代碼並找出它實際上做了什麼，把他們的測試工作基於已經寫好的代碼的基礎上。當然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓住(希望能夠)罕見的編譯器Bug，但是他們能夠做的僅僅是這些。
如果他們首先寫好一個詳細的規格說明，測試能夠以規格說明為基礎。代碼就能夠針對它的規格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規格說明中的錯誤。好的規格說明可以使測試的質量更高，所以最後的結論是高質量的測試需要高質量的規格說明。
在實踐中會出現這樣的情況： 一個開發人員要面對測試一個單元時只給出單元的代碼而沒有規格說明這樣吃力不討好的任務。你怎樣做才會有更多的收穫，而不僅僅是發現編譯器的Bug？第一步是理解這個單元原本要做什麼， --- 不是它實際上做了什麼。 比較有效的方法是倒推出一個概要的規格說明。這個過程的主要輸入條件是要閱讀那些程式代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。 可以組織對這個概要規格說明的走讀(Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設計單元測試了。
我是個很棒的程式設計師， 我是不是可以不進行單元測試？
在每個開發組織中都至少有一個這樣的開發人員，他非常擅長於編程，他們開發的軟體總是在第一時間就可以正常運行，因此不需要進行測試。你是否經常聽到這樣的藉口？
在真實世界裡，每個人都會犯錯誤。即使某個開發人員可以抱著這種態度在很少的一些簡單的程式中應付過去。 但真正的軟體系統是非常複雜的。真正的軟體系統不可以寄希望於沒有進行廣泛的測試和Bug修改過程就可以正常工作。
編碼不是一個可以一次性通過的過程。在真實世界中，軟體產品必須進行維護以對操作需求的改變作出反應， 並且要對最初的開發工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎？ 這些製造出這些未經測試的原始代碼的資深專家們還會繼續在其他地方製造這樣的代碼。在開發人員做出修改後進行可重複的單元測試可以避免產生那些令人不快的負作用。
不管怎樣，集成測試將會抓住所有的Bug 我們已經在前面的討論中從一個側面對這個問題進行了部分的闡述。這個論點不成立的原因在於規模越大的代碼集成意味著複雜性就越高。如果軟體的單元沒有事先進行測試，開發人員很可能會花費大量的時間僅僅是為了使軟體能夠運行，而任何實際的測試方案都無法執行。
單元測試過程
一旦軟體可以運行了，開發人員又要面對每個單元進行全面的測試。 這是一件非常困難的事情，甚至在創造一種單元調用的測試條件的時候，要全面的考慮單元的被調用時的各種入口參數。在軟體集成階段，對單元功能全面測試的複雜程度遠遠的超過獨立進行的單元測試過程。
最後的結果是測試將無法達到它所應該有的全面性。一些缺陷將被遺漏，並且很多Bug將被忽略過去。
讓我們類比一下，假設我們要清洗一台已經完全裝配好的食物加工機器!無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機器的死角位置，只有任其腐爛並等待以後再想辦法。但我們換個角度想想，如果這台機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，並且每一部分都可以毫不費力的進行清洗。
成本效率不高
一個特定的開發組織或軟體套用系統的測試水平取決於對那些未發現的Bug的潛在後果的重視程度。這種後果的嚴重程度可以從一個Bug引起的小小的不便到發生多次的當機的情況。這種後果可能常常會被軟體的開發人員所忽視(但是用戶可不會這樣)，這種情況會長期的損害這些向用戶提交帶有Bug的軟體的開發組織的信譽，並且會導致對未來的市場產生負面的影響。相反地，一個可靠的軟體系統的良好的聲譽將有助於一個開發組織獲取未來的市場。
Bug發現的越晚，修改它所需的費用就越高，因此從經濟角度來看， 應該儘可能早的查找和修改Bug。在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。
相比後階段的測試，單元測試的創建更簡單，維護更容易，並且可以更方便的進行重複。從全程的費用來考慮， 相比起那些複雜且曠日持久的集成測試，或是不穩定的軟體系統來說，單元測試所需的費用是很低的。
一些圖表
這些圖表摘自<<實用軟體度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準備測試，執行測試，和修改缺陷所花費的時間(以一個功能點為基準)，這些數據顯示單元測試的成本效率大約是集成測試的兩倍系統測試的三倍(參見條形圖)。(術語域測試(Field test)意思是在軟體投入使用以後，針對某個領域所作的所有測試活動)
條形圖
條形圖這個圖表並不表示開發人員不應該進行後階段的測試活動，這次測試活動仍然是必須的。它的真正意思是儘可能早的排除儘可能多的Bug可以減少後階段測試的費用。
其他的一些圖表顯示高達50%的維護工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發階段被排除掉的話，這些工作量就可以節省下來。當考慮到軟體維護費用可能會比最初的開發費用高出數倍的時候，這種潛在的對50%軟體維護費用的節省將對整個軟體生命周期費用產生重大的影響。
結論
經驗表明一個盡責的單元測試方法將會在軟體開發的某個階段發現很多的Bug，並且修改它們的成本也很低。在軟體開發的後期階段，Bug的發現並修改將會變得更加困難，並要消耗大量的時間和開發費用。在提供了經過測試的單元的情況下，系統集成過程將會大大地簡化。開發人員可以將精力集中在單元之間的互動作用和全局的功能實現上，而不是陷入充滿很多Bug的單元之中不能自拔。
使測試工作的效力發揮到最大化的關鍵在於選擇正確的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有適當地使用象AdaTEST和Cantata這樣的工具來支持測試過程。這些活動可以產生這樣的結果：在花費更低的開發費用的情況下得到更穩定的軟體。更進一步的好處是簡化了維護過程並降低了生命周期的費用。有效的單元測試是推行全局質量文化的一部分，而這種質量文化將會為軟體開發者帶來無限的商機。
單元測試的優點
- 驗證行為
程式中的每一項功能都是測試來驗證它的正確性。它為以後的開發提供支緩。就算是開發後期，我們也可以輕鬆的增加功能或更改程式結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程式進行改進。
- 設計行為
- 編寫文檔行為
單元測試是一種無價的文檔，它是展示函式或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，並且它保持最新，永遠與代碼同步。
- 具有回歸性
自動化的單元測試避免了代碼出現回歸，編寫完成之後，可以隨時隨地的快速運行測試。
- 單元測試的範疇
工作範疇
如果要給單元測試定義一個明確的範疇，指出哪些功能是屬於單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的範疇，單元測試所要做的工作。1、 它的行為和我期望的一致嗎？
這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。
- 它的行為一直和我期望的一致嗎？
編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，並不算是真正的完成。軟體開發是一個項複雜的工程，在測試某段代碼的行為是否和你的期望一致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致；譬如參數很可疑、硬碟沒有剩餘空間、緩衝區溢出、網路掉線的時候。
- 我可以依賴單元測試嗎？
不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。
- 單元測試說明我的意圖了嗎？
單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。
不寫測試的藉口
到這裡，我們已經列舉了使用單元測試的種種理由。也許，每個人都同意，是的，該做更多的測試。這種人人同意的事情還多著呢，是的，該多吃蔬菜，該戒菸，該多休息，該多鍛鍊……這並不意味著我們中的所有人都會這么去做，不是嗎bsp; 我們知道，在開發時越早發現BUG，就能節省更多的時間，降低更多的風險。
術語：域測試(Field test)意思是在軟體投入使用以後，針對某個領域所作的所有測試活動。
如果你仍然認為在編寫產品代碼的時候，還是沒有時間編寫測試代碼，那么請先考慮下面這些問題：
1）、對於所編寫的代碼，你在調試上面花了多少時間。
2）、對於以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新確認這些代碼上面。
3）、對於一個別人報告的bug，你花了多少時間才找出導致這個bug 的源碼位置。
回答完這些問題，你一定不再以“太花時間”作為拒絕單元測試的藉口。
2、 運行測試的時間太長了。
合適的測試是不會讓這種情況發生的。實際上，大多數測試的執行都是非常快的，因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時，需要把這些耗時的測試和其他測試分開。通常可以每天運行這種測試一次，或者幾天一次。
3、 測試代碼並不是我的工作。
你的工作就是保證代碼能夠正確的完成你的行為，恰恰相反，測試代碼正是你不可缺少的工作。
4、 我並不清楚代碼的行為，所以也就無從測試。
如果你實在不清楚代碼的行為，那么並不是編碼的時候。如果你並不知道代碼的行為，那么你又如何知道你編寫的代碼是正確的呢?
5、 但是這些代碼都能夠編譯通過。
我們前面已經說過，代碼通過編譯只是驗證它的語法通過。但並不能保證它的行為就一定正確。
6、 公司請我來是為了寫代碼，而不是寫測試。
7、 如果我讓測試員或者QA（Quality Assurance）人員沒有工作，那么我會覺得很內疚。
你並不需要擔心這些。請記住，我們在此只是談論單元測試，而它只是一種針對源碼的、低層次的，為程式設計師而設計的測試。在整個項目中，還有其他的很多測試需要這些人來完成，如：功能測試、驗收測試、性能測試、環境測試、有效性測試、正確性測試、正規分析等等。
8、 我的公司並不會讓我在真實系統中運行單元測試。
我們所討論的只是針對開發者的單元測試。也就是說，如果你可以在其他的環境下（例如在正式的產品系統中）運行這些測試的話，那么它們就不再是單元測試，而是其他類型的測試了。實際上，你可以在你的本機運行單元測試，使用你自己的資料庫，或者使用mock對象。
測試代碼編寫
產品類：
classCMyClass
{
int Add(int i, int j);
CMyClass();
virtual ~CMyClass();
private:
int mAge; //年齡
CString mPhase; //年齡階段，如"少年"，"青年"
};
建立對應的測試類CMyClassTester，為了節約編幅，只列出源檔案的代碼：
void CMyClassTester::CaseBegin()
{
//為求簡單，所有的測試類都可以用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、3、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)。
正常輸入
例如字元串的Trim函式，功能是將字元串前後的空格去除，那么正常的輸入可以有四類：前面有空格；後面有空格；前後均有空格；前後均無空格。
邊界輸入
上例中空字元串可以看作是邊界輸入。
再如一個表示年齡的參數，它的有效範圍是0-100，那么邊界輸入有兩個：0和100。
非法輸入
非法輸入是正常取值範圍以外的數據，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數，小於0或大於100都是非法輸入，再如一個進行檔案操作的函式，非法輸入有這么幾類：檔案不存在；目錄不存在；檔案正在被其他程式打開；許可權錯誤。
如果函式使用了外部數據，則正常輸入是肯定會有的，而邊界輸入和非法輸入不是所有函式都有。一般情況下，即使沒有設計文檔，考慮以上三種輸入也可以找出函式的基本功能點。實際上，單元測試與代碼編寫是“一體兩面”的關係，編碼時對上述三種輸入都是必須考慮的，否則代碼的健壯性就會成問題。
白盒覆蓋
上面所說的測試數據都是針對程式的功能來設計的，就是所謂的黑盒測試。單元測試還需要從另一個角度來設計測試數據，即針對程式的邏輯結構來設計測試用例，就是所謂的白盒測試。如果黑盒測試是足夠充分的，那么白盒測試就沒有必要，可惜“足夠充分”只是一種理想狀態，例如：真的是所有功能點都測試了嗎？程式的功能點是人為的定義，常常是不全面的；各個輸入數據之間，有些組合可能會產生問題，怎樣保證這些組合都經過了測試？難於衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易於衡量測試完整性的優點，兩者之間具有極好的互補性，例如：完成功能測試後統計語句覆蓋率，如果語句覆蓋未完成，很可能是未覆蓋的語句所對應的功能點未測試。
設計測試用例
白盒測試針對程式的邏輯結構設計測試用例，用邏輯覆蓋率來衡量測試的完整性。邏輯單位主要有：語句、分支、條件、條件值、條件值組合，路徑。語句覆蓋就是覆蓋所有的語句，其他類推。另外還有一種判定條件覆蓋，其實是分支覆蓋與條件覆蓋的組合，在此不作討論。跟條件有關的覆蓋就有三種，解釋一下：條件覆蓋是指覆蓋所有的條件表達式，即所有的條件表達式都至少計算一次，不考慮計算結果；條件值覆蓋是指覆蓋條件的所有可能取值，即每個條件的取真值和取假值都要至少計算一次；條件值組合覆蓋是指覆蓋所有條件取值的所有可能組合。做過一些粗淺的研究，發現與條件直接有關的錯誤主要是邏輯操作符錯誤，例如：||寫成&&，漏了寫!什麼的，採用分支覆蓋與條件覆蓋的組合，基本上可以發現這些錯誤，另一方面，條件值覆蓋與條件值組合覆蓋往往需要大量的測試用例，因此，條件值覆蓋和條件值組合覆蓋的效費比偏低。效費比較高且完整性也足夠的測試要求是這樣的：完成功能測試，完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋。做過單元測試的朋友恐怕會對測試要求給予一個字的評價：暈！因為這似乎是不可能的要求，要達到這種測試完整性?所以提出這種測試要求，是因為利用一些工具，可以在較低的成本下達到這種測試要求，後面將會作進一步介紹。
單元測試工具
首先是CppUnit，這是C++單元測試工具的鼻祖，免費的開源的單元測試框架。由於已有一眾高人寫了不少關於CppUnit的很好的文章，想了解CppUnit的朋友，建議讀一下Cpluser 所作的《CppUnit測試框架入門》，該文也提供了CppUnit的下載地址。
然後介紹C++Test，這是Parasoft公司的產品。[C++Test是一個功能強大的自動化C/C++單元級測試工具，可以自動測試任何C/C++函式、類，自動生成測試用例、測試驅動函式或樁函式，在自動化的環境下極其容易快速的將單元級的測試覆蓋率達到100%]。[]內的文字引自，這是華唐公司的網頁。想要購買或索取報價、試用版，建議訪問該公司的網站。
最後介紹Visual Unit，簡稱VU，這是國產的單元測試工具，據說申請了多項專利，擁有一批創新的技術。[自動生成測試代碼 快速建立功能測試用例程式行為一目了然 極高的測試完整性 高效完成白盒覆蓋 快速排錯 高效調試 詳盡的測試報告]。[]內的文字是VU開發商的網頁上摘錄的。前面所述測試要求：完成功能測試，完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋，用VU可以輕鬆實現，還有一點值得一提：使用VU還能提高編碼的效率，總體來說，在完成單元測試的同時，編碼調試的時間還能大幅度縮短。介紹工具索然無味，畢竟工具好不好用，合不合用，要試過才知道，還是自己去開發商的網站看吧，可以下載演示版，還有演示課件。
