單元測試

服務熱線：400-669-0203 020-29178595 QQ2557064750 2649046091 http://www.simou.net.cn/ http://www.innor.org/

單元測試(unit testing)，是指對軟件中的最小可測試單元進行檢查和驗證。對于單元測試中單元的含義，一般來說，要根據(jù)實際情況去判定其具體含義，如C語言中單元指一個函數(shù)，Java里單元指一個類，圖形化的軟件中可以指一個窗口或一個菜單等。總的來說，單元就是人為規(guī)定的最小的被測功能模塊。單元測試是在軟件開發(fā)過程中要進行的最低級別的測試活動，軟件的獨立單元將在與程序的其他部分相隔離的情況下進行測試。

在一種傳統(tǒng)的結構化編程語言中，比如C，要進行測試的單元一般是函數(shù)或子過程。在像C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨立的過程和函數(shù)，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言(4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。

經(jīng)常與單元測試聯(lián)系起來的另外一些開發(fā)活動包括代碼走讀(Code review)，靜態(tài)分析(Static analysis)和動態(tài)分析(Dynamic analysis)。靜態(tài)分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數(shù)據(jù)，并不需要對代碼進行編譯和執(zhí)行。動態(tài)分析就是通過觀察軟件運行時的動作，來提供執(zhí)行跟蹤，時間分析，以及測試覆蓋度方面的信息。
基本介紹
單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。

折疊編輯本段測試介紹
在一種傳統(tǒng)的結構化編程語言中，比如C，要進行測試的單元一般是函數(shù)或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨立的過程和函數(shù)，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言（4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。

經(jīng)常與單元測試聯(lián)系起來的另外一些開發(fā)活動包括代碼走讀（Code review)，靜態(tài)分析（Static analysis)和動態(tài)分析（Dynamic analysis)。靜態(tài)分析就是對軟件的源代碼進行研讀，查找錯誤或收集一些度量數(shù)據(jù)，并不需要對代碼進行編譯和執(zhí)行。動態(tài)分析就是通過觀察軟件運行時的動作，來提供執(zhí)行跟蹤，時間分析，以及測試覆蓋度方面的信息。

折疊單元測試

單元測試（模塊測試）是開發(fā)者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數(shù)的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現(xiàn)在list 的尾部。或者，你可能會從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。

單元測試是由程序員自己來完成，最終受益的也是程序員自己?？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執(zhí)行單元測試，就是為了證明這段代碼的行為和我們期望的一致。

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

其實我們每天都在做單元測試。你寫了一個函數(shù)，除了極簡單的外，總是要執(zhí)行一下，看看功能是否正常，有時還要想辦法輸出些數(shù)據(jù)，如彈出信息窗口什么的，這，也是單元測試，把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高后期測試和維護成本，也降低了開發(fā)商的競爭力?？梢哉f，進行充分的單元測試，是提高軟件質量，降低開發(fā)成本的必由之路。

對于程序員來說，如果養(yǎng)成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。

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

一般認為，在結構化程序時代，單元測試所說的單元是指函數(shù)，在當今的面向對象時代，單元測試所說的單元是指類。以我的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數(shù)作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數(shù)。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。

有一種看法是，只測試類的接口（公有函數(shù)），不測試其他函數(shù)，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數(shù)都要測試，跟函數(shù)是否私有沒有關系。對于C++來說，可以用一種簡單的方法區(qū)隔需測試的函數(shù)：簡單的函數(shù)如數(shù)據(jù)讀寫函數(shù)的實現(xiàn)在頭文件中編寫（inline函數(shù)），所有在源文件編寫實現(xiàn)的函數(shù)都要進行測試（構造函數(shù)和析構函數(shù)除外）。

折疊為什么要使用單元測試

我們編寫代碼時，一定會反復調試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會愿意交付給自己的老板。但代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。

幸運的是，單元測試會為我們的承諾做保證。編寫單元測試就是用來驗證這段代碼的行為是否與我們期望的一致。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的后顧之憂。

什么時候測試？單元測試越早越好，早到什么程度？XP開發(fā)理論講究TDD，即測試驅動開發(fā)，先編寫測試代碼，再進行開發(fā)。在實際的工作中，可以不必過分強調先什么后什么，重要的是高效和感覺舒適。從老納的經(jīng)驗來看，先編寫產(chǎn)品函數(shù)的框架，然后編寫測試函數(shù)，針對產(chǎn)品函數(shù)的功能編寫測試用例，然后編寫產(chǎn)品函數(shù)的代碼，每寫一個功能點都運行測試，隨時補充測試用例。所謂先編寫產(chǎn)品函數(shù)的框架，是指先編寫函數(shù)空的實現(xiàn)，有返回值的隨便返回一個值，編譯通過后再編寫測試代碼，這時，函數(shù)名、參數(shù)表、返回類型都應該確定下來了，所編寫的測試代碼以后需修改的可能性比較小。

由誰測試？單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應該由程序員完成，也就是說，經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時也要同時提交測試代碼。測試部門可以作一定程度的審核。

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

在一種傳統(tǒng)的結構化編程語言中，比如C，要進行測試的單元一般是函數(shù)或子過程。在象C++這樣的面向對象的語言中， 要進行測試的基本單元是類。對Ada語言來說，開發(fā)人員可以選擇是在獨立的過程和函數(shù)，還是在Ada包的級別上進行單元測試。單元測試的原則同樣被擴展到第四代語言（4GL)的開發(fā)中，在這里基本單元被典型地劃分為一個菜單或顯示界面。

折疊一些流行的誤解

在明確了什么是單元測試以后，我們可以進行"反調論證"了。在下面的章節(jié)里，我們列出了一些反對單元測試的普遍的論點。然后用充分的理由來證明這些論點是不足取的。

它浪費了太多的時間
測試工具
現(xiàn)在開始介紹單元測試工具，分別按編程語言進行分組介紹。

折疊C/C++

CppUnit

首先是CppUnit，這是C++單元測試工具的鼻祖，免費的開源的單元測試框架。由于已有一眾高人寫了不少關于CppUnit的很好的文章，老納就不現(xiàn)丑了，想了解CppUnit的朋友，建議讀一下Cpluser 所作的《CppUnit測試框架入門》，。該文也提供了CppUnit的下載地址。

C++Test

然后介紹C++Test，這是Parasoft公司的產(chǎn)品。[C++Test是一個功能強大的自動化C/C++單元級測試工具，可以自動測試任何C/C++函數(shù)、類，自動生成測試用例、測試驅動函數(shù)或樁函數(shù)，在自動化的環(huán)境下極其容易快速的將單元級的測試覆蓋率達到100%]。[]內的文字引自，這是華唐公司的網(wǎng)頁。老納想寫些介紹C++Test的文字，但發(fā)現(xiàn)無法超越華唐公司的網(wǎng)頁上的介紹，所以也就省點事了，想了解C++Test的朋友，建議訪問該公司的網(wǎng)站。華唐公司代理C++Test，想要購買或索取報價、試用版都可以找他們。

Visual Unit

最后介紹Visual Unit，簡稱VU，這是國產(chǎn)的單元測試工具，據(jù)說申請了多項專利，擁有一批創(chuàng)新的技術，不過老納只關心是不是有用和好用。[自動生成測試代碼 快速建立功能測試用例 程序行為一目了然 極高的測試完整性 高效完成白盒覆蓋 快速排錯 高效調試 詳盡的測試報告]。[]內的文字是VU開發(fā)商的網(wǎng)頁上摘錄的，。前面所述測試要求：完成功能測試，完成語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋，用VU可以輕松實現(xiàn)，還有一點值得一提：使用VU還能提高編碼的效率，總體來說，在完成單元測試的同時，編碼調試的時間還能大幅度縮短。算了，不想再講了，老納顯擺理論、介紹經(jīng)驗還是有興趣的，因為可以滿足老納好為人師的虛榮心，但介紹工具就覺得索然無味了，畢竟工具好不好用，合不合用，要試過才知道，還是自己去開發(fā)商的網(wǎng)站看吧，可以下載演示版，還有演示課件。

gtest　　

gtest測試框架是在不同平臺上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）為編寫C++測試而生成的。它是基于xUnit架構的測試框架，支持自動發(fā)現(xiàn)測試，豐富的斷言集，用戶定義的斷言，death測試，致命與非致命的失敗，類型參數(shù)化測試，各類運行測試的選項和XML的測試報告。需要詳細了解的朋友可以參閱《玩轉Google單元測試框架gtest系列》該篇文章。

折疊Java

JUnit

JUnit 是 Java 社區(qū)中知名度最高的單元測試工具。它誕生于 1997 年，由 Erich Gamma 和 Kent Beck 共同開發(fā)完成。其中 Erich Gamma 是經(jīng)典著作《設計模式：可復用面向對象軟件的基礎》一書的作者之一，并在 Eclipse 中有很大的貢獻；Kent Beck 則是一位極限編程（XP）方面的專家和先驅。JUnit 設計的非常小巧，但是功能卻非常強大。JUnit ——是一個開發(fā)源代碼的Java測試框架，用于編寫和運行可重復的測試。他是用于單元測試框架體系xUnit的一個實例（用于java語言）。主要用于白盒測試，回歸測試。

JUnit的好處和JUnit單元測試編寫原則：

好處：可以使測試代碼與產(chǎn)品代碼分開；針對某一個類的測試代碼通過較少的改動便可以應用于另一個類的測試；易于集成到測試人員的構建過程中，JUnit和Ant的結合可以實施增量開發(fā)；JUnit是公開源代碼的，可以進行二次開發(fā)；可以方便地對JUnit進行擴展；

編寫原則：是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫；是使測試單元保持持久性；是可以利用既有的測試來編寫相關的測試；

有興趣的朋友可以下下來仔細研究下。

JUnit-addons

對JUnit的一些補充，比如設置、獲取被測試對象的私有屬性的值，調用被測試對象的私有方法等。

常用類：junitx.util.PrivateAccessor

Spring 測試框架

可以測試基于Spring的應用，通過配置文件和注解自動組裝需要的單元測試對象。

提供了一些常用的J2EE Mock對象，比如HttpSession的Mock類等。

可以支持數(shù)據(jù)庫自動回滾，以防止對數(shù)據(jù)庫的單元測試（插入，刪除等）不可重復執(zhí)行，防止修改數(shù)據(jù)庫狀態(tài)等。

DJUnit

通過代碼自動產(chǎn)生Mock對象，省去了自己手動編寫N多的Mock類。

此外，它的Eclipse插件還可以做到測試覆蓋率、分支統(tǒng)計。

EasyMock

功能同DJUnit，也是通過編程自動Mock掉與測試對象無關的類，方法。

折疊編輯本段相關介紹
折疊范疇

如果要給單元測試定義一個明確的范疇，指出哪些功能是屬于單元測試，這似乎很難。但下面討論的四個問題，基本上可以說明單元測試的范疇，單元測試所要做的工作。

1、 它的行為和我期望的一致嗎？

這是單元測試最根本的目的，我們就是用單元測試的代碼來證明它所做的就是我們所期望的。

2、 它的行為一直和我期望的一致嗎？

編寫單元測試，如果只測試代碼的一條正確路徑，讓它正確走一遍，并不算是真正的完成。軟件開發(fā)是一個項復雜的工程，在測試某段代碼的行為是否和你的期望一致時，你需要確認：在任何情況下，這段代碼是否都和你的期望一致；譬如參數(shù)很可疑、硬盤沒有剩余空間、緩沖區(qū)溢出、網(wǎng)絡掉線的時候。

3、 我可以依賴單元測試嗎？

不能依賴的代碼是沒有多大用處的。既然單元測試是用來保證代碼的正確性，那么單元測試也一定要值得依賴。

4、 單元測試說明我的意圖了嗎？

單元測試能夠幫我們充分了解代碼的用法，從效果上而言，單元測試就像是能執(zhí)行的文檔，說明了在你用各種條件調用代碼時，你所能期望這段代碼完成的功能。

折疊不寫測試的借口

到這里，我們已經(jīng)列舉了使用單元測試的種種理由。也許，每個人都同意，是的，該做更多的測試。這種人人同意的事情還多著呢，是的，該多吃蔬菜，該戒煙，該多休息，該多鍛煉……這并不意味著我們中的所有人都會這么去做，不是嗎？

1、 編寫單元測試太花時間了。

我們知道，在開發(fā)時越早發(fā)現(xiàn)BUG，就能節(jié)省更多的時間，降低更多的風險。

下圖表摘自<<實用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準備測試，執(zhí)行測試，和修改缺陷所花費的時間（以一個功能點為基準），這些數(shù)據(jù)顯示單元測試的成本效率大約是集成測試的兩倍，是系統(tǒng)測試的三倍（參見條形圖）。

術語：域測試（Field test)意思是在軟件投入使用以后，針對某個領域所作的所有測試活動。

如果你仍然認為在編寫產(chǎn)品代碼的時候，還是沒有時間編寫測試代碼，那么請先考慮下面這些問題：

1）、對于所編寫的代碼，你在調試上面花了多少時間。

2）、對于以前你自認為正確的代碼，而實際上這些代碼卻存在重大的bug，你花了多少時間在重新確認這些代碼上面。

3）、對于一個別人報告的bug，你花了多少時間才找出導致這個bug 的源碼位置。

回答完這些問題，你一定不再以“太花時間”作為拒絕單元測試的借口。

2、 運行測試的時間太長了。

合適的測試是不會讓這種情況發(fā)生的。實際上，大多數(shù)測試的執(zhí)行都是非常快的，因此你在幾秒之內就可以運行成千上萬個測試。但是有時某些測試會花費很長的時間。這時，需要把這些耗時的測試和其他測試分開。通?？梢悦刻爝\行這種測試一次，或者幾天一次。

3、 測試代碼并不是我的工作。

你的工作就是保證代碼能夠正確的完成你的行為，恰恰相反，測試代碼正是你不可缺少的工作。

4、 我并不清楚代碼的行為，所以也就無從測試。

如果你實在不清楚代碼的行為，那么估計現(xiàn)在并不是編碼的時候。如果你并不知道代碼的行為，那么你又如何知道你編寫的代碼是正確的呢

5、 但是這些代碼都能夠編譯通過。

我們前面已經(jīng)說過，代碼通過編譯只是驗證它的語法通過。但并不能保證它的行為就一定正確。

6、 公司請我來是為了寫代碼，而不是寫測試。

公司付給你薪水是為了讓你編寫產(chǎn)品代碼，而單元測試大體上是一個工具，是一個和編輯器、開發(fā)環(huán)境、編譯器等處于同一位置的工具。

7、 如果我讓測試員或者QA（Quality Assurance）人員沒有工作，那么我會覺得很內疚。

你并不需要擔心這些。請記住，我們在此只是談論單元測試，而它只是一種針對源碼的、低層次的，為程序員而設計的測試。在整個項目中，還有其他的很多測試需要這些人來完成，如：功能測試、驗收測試、性能測試、環(huán)境測試、有效性測試、正確性測試、正規(guī)分析等等。

8、 我的公司并不會讓我在真實系統(tǒng)中運行單元測試。

我們所討論的只是針對開發(fā)者的單元測試。也就是說，如果你可以在其他的環(huán)境下（例如在正式的產(chǎn)品系統(tǒng)中）運行這些測試的話，那么它們就不再是單元測試，而是其他類型的測試了。實際上，你可以在你的本機運行單元測試，使用你自己的數(shù)據(jù)庫，或者使用mock 對象。

一旦編碼完成，開發(fā)人員總是會迫切希望進行軟件的集成工作，這樣他們就能夠看到實際的系統(tǒng)開始啟動工作了。這在外表上看來是一項明顯的進步，而象單元測試這樣的活動也許會被看作是通往這個階段點的道路上的障礙， 推遲了對整個系統(tǒng)進行聯(lián)調這種真正有意思的工作啟動的時間。

在這種開發(fā)步驟中，真實意義上的進步被外表上的進步取代了。系統(tǒng)能夠正常工作的可能性是很小的，更多的情況是充滿了各式各樣的Bug。在實踐中，這樣一種開發(fā)步驟常常會導致這樣的結果：軟件甚至無法運行。更進一步的結果是大量的時間將被花費在跟蹤那些包含在獨立單元里的簡單的Bug上面，在個別情況下，這些Bug也許是瑣碎和微不足道的，但是總的來說，他們會導致在軟件集成為一個系統(tǒng)時增加額外的工期， 而且當這個系統(tǒng)投入使用時也無法確保它能夠可靠運行。

在實踐工作中，進行了完整計劃的單元測試和編寫實際的代碼所花費的精力大致上是相同的。一旦完成了這些單元測試工作，很多Bug將被糾正，在確信他們手頭擁有穩(wěn)定可靠的部件的情況下，開發(fā)人員能夠進行更高效的系統(tǒng)集成工作。這才是真實意義上的進步，所以說完整計劃下的單元測試是對時間的更高效的利用。而調試人員的不受控和散漫的工作方式只會花費更多的時間而取得很少的好處。

使用AdaTEST和Cantata這樣的支持工具可以使單元測試更加簡單和有效。但這不是必須的，單元測試即使是在沒有工具支持的情況下也是一項非常有意義的活動。

它僅僅是證明這些代碼做了什么

這是那些沒有首先為每個單元編寫一個詳細的規(guī)格說明而直接跳到編碼階段的開發(fā)人員提出的一條普遍的抱怨， 當編碼完成以后并且面臨代碼測試任務的時候，他們就閱讀這些代碼并找出它實際上做了什么，把他們的測試工作基于已經(jīng)寫好的代碼的基礎上。當然，他們無法證明任何事情。所有的這些測試工作能夠表明的事情就是編譯器工作正常。是的，他們也許能夠抓?。ㄏＭ軌颍┖币姷木幾g器Bug，但是他們能夠做的僅僅是這些。

如果他們首先寫好一個詳細的規(guī)格說明，測試能夠以規(guī)格說明為基礎。代碼就能夠針對它的規(guī)格說明，而不是針對自身進行測試。這樣的測試仍然能夠抓住編譯器的Bug，同時也能找到更多的編碼錯誤，甚至是一些規(guī)格說明中的錯誤。好的規(guī)格說明可以使測試的質量更高，所以最后的結論是高質量的測試需要高質量的規(guī)格說明。

在實踐中會出現(xiàn)這樣的情況：一個開發(fā)人員要面對測試一個單元時只給出單元的代碼而沒有規(guī)格說明這樣吃力不討好的任務。你怎樣做才會有更多的收獲，而不僅僅是發(fā)現(xiàn)編譯器的Bug？第一步是理解這個單元原本要做什么， --- 不是它實際上做了什么。比較有效的方法是倒推出一個概要的規(guī)格說明。這個過程的主要輸入條件是要閱讀那些程序代碼和注釋， 主要針對這個單元， 及調用它和被它調用的相關代碼。畫出流程圖是非常有幫助的，你可以用手工或使用某種工具。可以組織對這個概要規(guī)格說明的走讀（Review)，以確保對這個單元的說明沒有基本的錯誤， 有了這種最小程度的代碼深層說明，就可以用它來設計單元測試了。

我是個很棒的程序員， 我是不是可以不進行單元測試？

在每個開發(fā)組織中都至少有一個這樣的開發(fā)人員，他非常擅長于編程，他們開發(fā)的軟件總是在第一時間就可以正常運行，因此不需要進行測試。你是否經(jīng)常聽到這樣的借口？
折疊測試用例設計

下面談談測試用例設計。前面已經(jīng)說了，測試用例的核心是輸入數(shù)據(jù)。預期輸出是依據(jù)輸入數(shù)據(jù)和程序功能來確定的，也就是說，對于某一程序，輸入數(shù)據(jù)確定了，預期輸出也就可以確定了，至于生成/銷毀被測試對象和運行測試的語句，是所有測試用例都大同小異的，因此，我們討論測試用例時，只討論輸入數(shù)據(jù)。

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

正常輸入

例如字符串的Trim函數(shù)，功能是將字符串前后的空格去除，那么正常的輸入可以有四類：前面有空格；后面有空格；前后均有空格；前后均無空格。

邊界輸入

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

再如一個表示年齡的參數(shù)，它的有效范圍是0-100，那么邊界輸入有兩個：0和100。

非法輸入

非法輸入是正常取值范圍以外的數(shù)據(jù)，或使代碼不能完成正常功能的輸入，如上例中表示年齡的參數(shù)，小于0或大于100都是非法輸入，再如一個進行文件操作的函數(shù)，非法輸入有這么幾類：文件不存在；目錄不存在；文件正在被其他程序打開；權限錯誤。

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

白盒覆蓋

上面所說的測試數(shù)據(jù)都是針對程序的功能來設計的，就是所謂的黑盒測試。單元測試還需要從另一個角度來設計測試數(shù)據(jù)，即針對程序的邏輯結構來設計測試用例，就是所謂的白盒測試。在老納看來，如果黑盒測試是足夠充分的，那么白盒測試就沒有必要，可惜“足夠充分”只是一種理想狀態(tài)，例如：真的是所有功能點都測試了嗎？程序的功能點是人為的定義，常常是不全面的；各個輸入數(shù)據(jù)之間，有些組合可能會產(chǎn)生問題，怎樣保證這些組合都經(jīng)過了測試？難于衡量測試的完整性是黑盒測試的主要缺陷，而白盒測試恰恰具有易于衡量測試完整性的優(yōu)點，兩者之間具有極好的互補性，例如：完成功能測試后統(tǒng)計語句覆蓋率，如果語句覆蓋未完成，很可能是未覆蓋的語句所對應的功能點未測試。

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

關于白盒測試用例的設計，程序測試領域的書籍一般都有講述，普通方法是畫出程序的邏輯結構圖如程序流程圖或控制流圖，根據(jù)邏輯結構圖設計測試用例，這些是純粹的白盒測試，不是老納想推薦的方式。老納所推薦的方法是：先完成黑盒測試，然后統(tǒng)計白盒覆蓋率，針對未覆蓋的邏輯單位設計測試用例覆蓋它，例如，先檢查是否有語句未覆蓋，有的話設計測試用例覆蓋它，然后用同樣方法完成條件覆蓋、分支覆蓋和路徑覆蓋，這樣的話，既檢驗了黑盒測試的完整性，又避免了重復的工作，用較少的時間成本達到非常高的測試完整性。不過，這些工作可不是手工能完成的，必須借助于工具，后面會介紹可以完成這些工作的測試工具。
在真實世界里，每個人都會犯錯誤。即使某個開發(fā)人員可以抱著這種態(tài)度在很少的一些簡單的程序中應付過去。但真正的軟件系統(tǒng)是非常復雜的。真正的軟件系統(tǒng)不可以寄希望于沒有進行廣泛的測試和Bug修改過程就可以正常工作。

編碼不是一個可以一次性通過的過程。在真實世界中，軟件產(chǎn)品必須進行維護以對操作需求的改變作出反應， 并且要對最初的開發(fā)工作遺留下來的Bug進行修改。你希望依靠那些原始作者進行修改嗎？ 這些制造出這些未經(jīng)測試的原始代碼的資深專家們還會繼續(xù)在其他地方制造這樣的代碼。在開發(fā)人員做出修改后進行可重復的單元測試可以避免產(chǎn)生那些令人不快的負作用。

不管怎樣， 集成測試將會抓住所有的Bug

我們已經(jīng)在前面的討論中從一個側面對這個問題進行了部分的闡述。這個論點不成立的原因在于規(guī)模越大的代碼集成意味著復雜性就越高。如果軟件的單元沒有事先進行測試，開發(fā)人員很可能會花費大量的時間僅僅是為了使軟件能夠運行，而任何實際的測試方案都無法執(zhí)行。

一旦軟件可以運行了，開發(fā)人員又要面對這樣的問題：在考慮軟件全局復雜性的前提下對每個單元進行全面的測試。這是一件非常困難的事情，甚至在創(chuàng)造一種單元調用的測試條件的時候，要全面的考慮單元的被調用時的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復雜程度遠遠的超過獨立進行的單元測試過程。

最后的結果是測試將無法達到它所應該有的全面性。一些缺陷將被遺漏，并且很多Bug將被忽略過去。

讓我們類比一下，假設我們要清洗一臺已經(jīng)完全裝配好的食物加工機器！無論你噴了多少水和清潔劑，一些食物的小碎片還是會粘在機器的死角位置，只有任其腐爛并等待以后再想辦法。但我們換個角度想想，如果這臺機器是拆開的， 這些死角也許就不存在或者更容易接觸到了，并且每一部分都可以毫不費力的進行清洗。

折疊成本效率不高

一個特定的開發(fā)組織或軟件應用系統(tǒng)的測試水平取決于對那些未發(fā)現(xiàn)的Bug的潛在后果的重視程度。這種后果的嚴重程度可以從一個Bug引起的小小的不便到發(fā)生多次的死機的情況。這種后果可能常常會被軟件的開發(fā)人員所忽視（但是用戶可不會這樣），這種情況會長期的損害這些向用戶提交帶有Bug的軟件的開發(fā)組織的信譽，并且會導致對未來的市場產(chǎn)生負面的影響。相反地，一個可靠的軟件系統(tǒng)的良好的聲譽將有助于一個開發(fā)組織獲取未來的市場。

很多研究成果表明，無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進行測試將使效率和質量得到最好的保證。Bug發(fā)現(xiàn)的越晚，修改它所需的費用就越高，因此從經(jīng)濟角度來看， 應該盡可能早的查找和修改Bug。在修改費用變的過高之前，單元測試是一個在早期抓住Bug的機會。

相比后階段的測試，單元測試的創(chuàng)建更簡單，維護更容易，并且可以更方便的進行重復。從全程的費用來考慮， 相比起那些復雜且曠日持久的集成測試，或是不穩(wěn)定的軟件系統(tǒng)來說，單元測試所需的費用是很低的。

折疊結論

經(jīng)驗表明一個盡責的單元測試方法將會在軟件開發(fā)的某個階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會變得更加困難，并要消耗大量的時間和開發(fā)費用。無論什么時候作出修改都要進行完整的回歸測試，在生命周期中盡早地對軟件產(chǎn)品進行測試將使效率和質量得到最好的保證。在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實現(xiàn)上，而不是陷入充滿很多Bug的單元之中不能自拔。

使測試工作的效力發(fā)揮到最大化的關鍵在于選擇正確的測試策略，這其中包含了完全的單元測試的概念，以及對測試過程的良好的管理，還有適當?shù)厥褂孟驛daTEST和Cantata這樣的工具來支持測試過程。這些活動可以產(chǎn)生這樣的結果：在花費更低的開發(fā)費用的情況下得到更穩(wěn)定的軟件。更進一步的好處是簡化了維護過程并降低了生命周期的費用。有效的單元測試是推行全局質量文化的一部分，而這種質量文化將會為軟件開發(fā)者帶來無限的商機。

折疊優(yōu)點一

它是一種驗證行為。

程序中的每一項功能都是測試來驗證它的正確性。它為以后的開發(fā)提供支援。就算是開發(fā)后期，我們也可以輕松的增加功能或更改程序結構，而不用擔心這個過程中會破壞重要的東西。而且它為代碼的重構提供了保障。這樣，我們就可以更自由的對程序進行改進。

折疊優(yōu)點二

它是一種設計行為。

編寫單元測試將使我們從調用者觀察、思考。特別是先寫測試（test-first），迫使我們把程序設計成易于調用和可測試的，即迫使我們解除軟件中的耦合。

折疊優(yōu)點三

它是一種編寫文檔的行為。

單元測試是一種無價的文檔，它是展示函數(shù)或類如何使用的最佳文檔。這份文檔是可編譯、可運行的，并且它保持最新，永遠與代碼同步。

折疊優(yōu)點四

它具有回歸性。

自動化的單元測試避免了代碼出現(xiàn)回歸，編寫完成之后，可以隨時隨地的快速運行測試。