單元測試任務(wù)

要進(jìn)行充分的單元測試，應(yīng)專門編寫測試代碼，并與產(chǎn)品代碼隔離。比較簡單的辦法是為產(chǎn)品工程建立對應(yīng)的測試工程，為每個(gè)類建立對應(yīng)的測試類，為每個(gè)函數(shù)(很簡單的除外)建立測試函數(shù)。

一般認(rèn)為，在結(jié)構(gòu)化程序時(shí)代，單元測試所說的單元是指函數(shù)，在當(dāng)今的面向?qū)ο髸r(shí)代，單元測試所說的單元是指類。以類作為測試單位，復(fù)雜度高，可操作性較差，因此仍然主張以函數(shù)作為單元測試的測試單位，但可以用一個(gè)測試類來組織某個(gè)類的所有測試函數(shù)。單元測試不應(yīng)過分強(qiáng)調(diào)面向?qū)ο?，因?yàn)榫植看a依然是結(jié)構(gòu)化的。單元測試的工作量較大，簡單實(shí)用高效才是硬道理。

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

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

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

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

單元測試與其他測試不同，單元測試可看作是編碼??過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時(shí)也要同時(shí)提交測試代碼。測試部門可以作一定程度的審核。

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

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

單元測試不僅僅是作為無錯(cuò)編碼一種輔助手段在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。

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

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

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

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

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

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

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

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

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

我是個(gè)很棒的程序員， 我是不是可以不進(jìn)行單元測試?

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

在真實(shí)世界里，每個(gè)人都會犯錯(cuò)誤。即使某個(gè)開發(fā)人員可以抱著這種態(tài)度在很少的一些簡單的程序中應(yīng)付過去。 但真正的軟件系統(tǒng)是非常復(fù)雜的。真正的軟件系統(tǒng)不可以寄希望于沒有進(jìn)行廣泛的測試和Bug修改過程就可以正常工作。

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

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

一旦軟件可以運(yùn)行了，開發(fā)人員又要面對每個(gè)單元進(jìn)行全面的測試。 這是一件非常困難的事情，甚至在創(chuàng)造一種單元調(diào)用的測試條件的時(shí)候，要全面的考慮單元的被調(diào)用時(shí)的各種入口參數(shù)。在軟件集成階段，對單元功能全面測試的復(fù)雜程度遠(yuǎn)遠(yuǎn)的超過獨(dú)立進(jìn)行的單元測試過程。

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

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

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

Bug發(fā)現(xiàn)的越晚，修改它所需的費(fèi)用就越高，因此從經(jīng)濟(jì)角度來看， 應(yīng)該盡可能早的查找和修改Bug。在修改費(fèi)用變的過高之前，單元測試是一個(gè)在早期抓住Bug的機(jī)會。

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

這些圖表摘自<<實(shí)用軟件度量>>(Capers Jones，McGraw-Hill 1991)，它列出了準(zhǔn)備測試，執(zhí)行測試，和修改缺陷所花費(fèi)的時(shí)間(以一個(gè)功能點(diǎn)為基準(zhǔn))，這些數(shù)據(jù)顯示單元測試的成本效率大約是集成測試的兩倍系統(tǒng)測試的三倍(參見條形圖)。 (術(shù)語域測試(Field test)意思是在軟件投入使用以后，針對某個(gè)領(lǐng)域所作的所有測試活動)

這個(gè)圖表并不表示開發(fā)人員不應(yīng)該進(jìn)行后階段的測試活動，這次測試活動仍然是必須的。它的真正意思是盡可能早的排除盡可能多的Bug可以減少后階段測試的費(fèi)用。

其他的一些圖表顯示高達(dá)50%的維護(hù)工作量被花在那些總是會有的Bug的修改上面。如果這些Bug在開發(fā)階段被排除掉的話，這些工作量就可以節(jié)省下來。當(dāng)考慮到軟件維護(hù)費(fèi)用可能會比最初的開發(fā)費(fèi)用高出數(shù)倍的時(shí)候，這種潛在的對50%軟件維護(hù)費(fèi)用的節(jié)省將對整個(gè)軟件生命周期費(fèi)用產(chǎn)生重大的影響。

經(jīng)驗(yàn)表明一個(gè)盡責(zé)的單元測試方法將會在軟件開發(fā)的某個(gè)階段發(fā)現(xiàn)很多的Bug，并且修改它們的成本也很低。在軟件開發(fā)的后期階段，Bug的發(fā)現(xiàn)并修改將會變得更加困難，并要消耗大量的時(shí)間和開發(fā)費(fèi)用。在提供了經(jīng)過測試的單元的情況下，系統(tǒng)集成過程將會大大地簡化。開發(fā)人員可以將精力集中在單元之間的交互作用和全局的功能實(shí)現(xiàn)上，而不是陷入充滿很多Bug的單元之中不能自拔。

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