一、單元測試的意義
單元測試會(huì)為我們的質(zhì)量做保證。編寫單元測試就是用來驗(yàn)證這段代碼的行為是否與我們期望的一致。有了單元測試，我們可以自信的交付自己的代碼，而沒有任何的后顧之憂。
我們在編碼時(shí)，一定會(huì)反復(fù)調(diào)試保證它能夠編譯通過。如果是編譯沒有通過的代碼，沒有任何人會(huì)愿意交付給Boss。但代碼通過編譯，只是說明了它的語法正確；我們卻無法保證它的語義也一定正確，沒有任何人可以輕易承諾這段代碼的行為一定是正確的。
從成本角度考慮，BUG發(fā)現(xiàn)越早越好，加強(qiáng)單元測試力度有利于降低缺陷定位和修復(fù)難度，從而降低缺陷解決成本，同時(shí)加強(qiáng)單元測試也減輕了后續(xù)集成測試和系統(tǒng)測試的 負(fù)擔(dān)。據(jù)業(yè)界統(tǒng)計(jì)，如果一個(gè)BUG在單元測試階段發(fā)現(xiàn)花費(fèi)是1的話，到集成測試就變?yōu)?0，到系統(tǒng)測試就高達(dá)100，到實(shí)際推向市場量產(chǎn)后就高達(dá) 1000，所以，進(jìn)行充分的單元測試，是提高軟件質(zhì)量，降低開發(fā)成本的必由之路。但單元測試在目前國內(nèi)軟件企業(yè)中開展得并不好，一方面是由于對單元測試重 視程度不夠，測試投入不足，另一方面是由于在單元測試實(shí)踐方面積累得也不夠，單元測試處于一種摸索狀態(tài)。
單元測試不僅僅是作為無錯(cuò)編碼一種輔助手段，在一次性的開發(fā)過程中使用，單元測試必須是可重復(fù)的，無論是在軟件修改，或是移植到新的運(yùn)行環(huán)境的過程中。因此，所有的測試都必須在整個(gè)軟件系統(tǒng)的生命周期中進(jìn)行維護(hù)。
單元測試與其他測試不同，單元測試可看作是編碼工作的一部分，應(yīng)該由程序員完成，也就是說，經(jīng)過了單元測試的代碼才是已完成的代碼，提交產(chǎn)品代碼時(shí)也要同時(shí)提交單元測試代碼。測試部門可以對單元測試的過程以及結(jié)果作一定程度的審核，作為集成和系統(tǒng)測試準(zhǔn)入的一種標(biāo)準(zhǔn)。
二、如何做好單元測試
1）組織結(jié)構(gòu)應(yīng)該保證測試部門參與單元測試
目前普遍都認(rèn)為單元測試應(yīng)該由開發(fā)人員開展，這是因?yàn)閺膯卧獪y試的過程看，單元測試普遍采用白盒測試的方法，離不開深入被測對象的代碼，同時(shí)還需要構(gòu)造驅(qū)動(dòng)模塊、樁函數(shù)，因此開展單元測試需要較好的開發(fā)知識(shí)。從人員的知識(shí)結(jié)構(gòu)、對代碼的熟悉程度考慮，開發(fā)人員具有一定的優(yōu)勢。
單元測試由開發(fā)人員進(jìn)行能帶來一些特別的收益。我們知道，在實(shí)踐中開發(fā)人員進(jìn)行單元測試一般推薦采用交叉測試的方法，例如由被測單元的調(diào)用方進(jìn)行該單元 的測試，即盡量避免對自己的代碼進(jìn)行單元測試。這種交叉的測試安排可以避免測試受開發(fā)思路影響太大，局限于原來的思路不容易發(fā)現(xiàn)開發(fā)過程中制造的問題；二 來也達(dá)到一個(gè)技術(shù)備份或充分交流的目的，這對組織非常有利。即使不采用交叉測試的方法，而安排單元的生產(chǎn)者自行開展單元測試，也是有很大的優(yōu)越性的，其最 大的優(yōu)點(diǎn)是快速。在人員緊張的情況下這種自行測試的安排也是不錯(cuò)的選擇。
從經(jīng)驗(yàn)值來看，單元測試投入和編碼投入相比基本上是一比一，如果由專職測試隊(duì)伍來進(jìn)行單元測試，維持這樣龐大的單一任務(wù)隊(duì)伍顯然是不合適的，對于一般企業(yè)來說也是不小的成本負(fù)擔(dān)。
以上談的是由開發(fā)人員進(jìn)行單元測試的優(yōu)點(diǎn)，其中主要是從單元測試的效率角度來考慮。但是從單元測試效果的角度考慮，必須從組織結(jié)構(gòu)上保證測試部門參與單元測試，這是因?yàn)椋?/p>
首先，從目前國內(nèi)企業(yè)普遍現(xiàn)狀來看，測試人員質(zhì)量意識(shí)要高于開發(fā)人員，測試人員參與單元測試能夠提高測試質(zhì)量。
其次，對被測系統(tǒng)越了解，測試才有可能越深入，測試人員參與單元測試，將使得測試人員能夠從代碼級(jí)熟悉被測系統(tǒng)，這對測試人員后期集成測試和系統(tǒng)測試活動(dòng)非常有幫助，會(huì)很大的提升集成測試和系統(tǒng)測試質(zhì)量。
測試部門以何種方式參與單元測試，應(yīng)該結(jié)合軟件組織的實(shí)際情況來定。如果軟件組織測試充分，測試人員對開發(fā)人員的比例較高，那么可以由測試人員獨(dú)立承擔(dān) 部分重要模塊的單元測試工作；如果測試資源不足，測試人員對開發(fā)人員的比例較低，那么可以采取由測試人員進(jìn)行單元測試計(jì)劃、單元測試設(shè)計(jì)的工作，而單元測 試的實(shí)現(xiàn)和執(zhí)行由開發(fā)人員來完成；而如果測試資源非常缺乏或測試人員素質(zhì)不夠全面，連單元測試計(jì)劃、單元測試設(shè)計(jì)都無法承擔(dān)，那么測試部門至少應(yīng)該參與開 發(fā)過程的各相關(guān)單元測試文檔、單元測試報(bào)告的評(píng)審，保證單元測試的質(zhì)量。
2）制訂單元測試的過程定義
軟件質(zhì)量的提高需要規(guī)范的流程，對軟件開發(fā)過程進(jìn)行管理也需要依據(jù)規(guī)范的過程定義。要提高單元測試的質(zhì)量，首先要制定規(guī)范的單元測試過程，各生產(chǎn)部門可以依據(jù)單元測試過程定義開展各自的工作，共同保證單元測試的質(zhì)量。
單元測試過程的定義需要參照企業(yè)的實(shí)際情況，例如階段劃分可以分為四個(gè)階段：計(jì)劃、設(shè)計(jì)、實(shí)現(xiàn)、執(zhí)行。
其中計(jì)劃階段應(yīng)當(dāng)考慮整個(gè)單元測試過程的時(shí)間表，工作量，任務(wù)的劃分情況，人員和資源的安排情況，需要的和測試方法，單元測試結(jié)束的標(biāo)準(zhǔn)等，同時(shí)還應(yīng)當(dāng)考慮可能存在的，以及針對這些風(fēng)險(xiǎn)的具體處理辦法，并輸出《單元測試計(jì)劃》文檔，作為項(xiàng)目中整個(gè)單元測試過程的指導(dǎo)。
設(shè)計(jì)階段需要具體考慮對哪些單元進(jìn)行測試，被測單元之間的關(guān)系以及同其它模塊單元之間的關(guān)系，具體測試的策略采用哪一種、如何進(jìn)行單元測試用例的設(shè)計(jì)、如何進(jìn)行單元測試代碼設(shè)計(jì)、采用何種工具等，并輸出《單元測試方案》文檔，用來指導(dǎo)具體的單元測試操作。
實(shí)現(xiàn)階段需要完成單元測試用例設(shè)計(jì)、腳本的編寫，測試驅(qū)動(dòng)模塊的編寫，測試樁模塊的編寫工作，輸出《單元測試用例》文檔、相關(guān)測試代碼。
執(zhí)行階段的主要工作是搭建單元測試環(huán)境，執(zhí)行測試腳本，記錄測試結(jié)果，如果發(fā)現(xiàn)錯(cuò)誤，開發(fā)人員需要負(fù)責(zé)錯(cuò)誤的修改，同時(shí)進(jìn)行回歸測試，該階段結(jié)束需要提交《單元測試報(bào)告》。我們可以將設(shè)計(jì)和實(shí)現(xiàn)階段合并，輸出《單元測試用例》文檔、相關(guān)測試代碼。
3）必須制訂覆蓋率指標(biāo)和質(zhì)量目標(biāo)來指導(dǎo)和驗(yàn)收單元測試
單元測試必須制訂一定的覆蓋率指標(biāo)和質(zhì)量目標(biāo)，來指導(dǎo)單元測試設(shè)計(jì)和執(zhí)行，同時(shí)作為單元測試驗(yàn)收的標(biāo)準(zhǔn)。設(shè)計(jì)用例時(shí)，可針對要達(dá)到的覆蓋率指標(biāo) 來設(shè)計(jì)用例，而在測試執(zhí)行時(shí)，可以依據(jù)覆蓋率分析工具分析測試是否達(dá)到了覆蓋率指標(biāo)，如果沒達(dá)到，需要分析哪些部分沒有覆蓋到，從而補(bǔ)充用例來達(dá)到覆蓋率 指標(biāo)。而單元測試質(zhì)量目標(biāo)的制訂，需要符合軟件企業(yè)的實(shí)際過程能力，這依賴于軟件企業(yè)對以前單元測試過程度量數(shù)據(jù)的積累，不能憑空制造出來。有了以前度量 數(shù)據(jù)的積累，完全可以了解當(dāng)前組織的單元測試能力，例如單元測試每千行代碼發(fā)現(xiàn)的缺陷數(shù)是多少。如果單元測試統(tǒng)計(jì)結(jié)果沒有落到這個(gè)質(zhì)量目標(biāo)范圍內(nèi)，說明單 元測試過程中某些方面存在一些問題，需要對測試過程進(jìn)行分析后找出問題原因進(jìn)行改進(jìn)。
這些指標(biāo)確定下來后，一定要嚴(yán)格推行。定會(huì)有一些人找出各種理由證明覆蓋率指標(biāo)達(dá)不到等等，這需要質(zhì)量部門根據(jù)實(shí)際情況分析指標(biāo)是否合理。實(shí)際 證明有一個(gè)相對簡單的標(biāo)準(zhǔn)也比沒有標(biāo)準(zhǔn)要好得多，但顯然，通過推行硬性指標(biāo)，單元測試發(fā)現(xiàn)的問題數(shù)目比沒有標(biāo)準(zhǔn)前至少增加了2倍。
4）單元測試者技能的提高
1、加強(qiáng)對單元測試人員的技能
單元測試的質(zhì)量很大程度上決定于進(jìn)行單元測試的人的技術(shù)水平。如果測試者不具備單元測試的知識(shí)，那么應(yīng)該對測試者進(jìn)行相關(guān)的培訓(xùn)。一個(gè)沒有做過 單元測試人，不經(jīng)過培訓(xùn)初次是很難做好單元測試的。單元測試在詳細(xì)設(shè)計(jì)階段結(jié)束時(shí)開始，但是單元測試相關(guān)培訓(xùn)應(yīng)該盡早準(zhǔn)備和計(jì)劃，培訓(xùn)可以分兩個(gè)階段，每 個(gè)階段的內(nèi)容類似。第一階段是寫單元測試方案前，培訓(xùn)對象為測試方案的寫作者和詳細(xì)設(shè)計(jì)的寫作者，這樣可以在設(shè)計(jì)時(shí)多考慮可測試性，培訓(xùn)的內(nèi)容為單元測試 基本概念、單元測試分析方法、單元測試用例的寫作、單元測試標(biāo)準(zhǔn)的明確；第二階段為單元測試執(zhí)行前，對象為測試執(zhí)行者，培訓(xùn)內(nèi)容為具體單元測試的執(zhí)行，包 括驅(qū)動(dòng)函數(shù)、樁函數(shù)的構(gòu)造、覆蓋率測試工具的使用(TrueCoverage、Logiscope等)、利用自動(dòng)化單元測試框架構(gòu)造單元測試自動(dòng)化 (TCL、CppUnit、JUnit等)。培訓(xùn)過程中最好結(jié)合實(shí)例穿插其中，會(huì)比較生動(dòng)，而且增強(qiáng)理解。
通過以上的系統(tǒng)培訓(xùn)，可以統(tǒng)一單元測試方法、明確單元測試的標(biāo)準(zhǔn)、掌握單元測試基本技能，為后期單元測試的順利開展掃平道路。
2、必須引入工具進(jìn)行輔助
單元測試非常需要工具的幫助，特別是覆蓋率工具不能缺少，否則用例執(zhí)行后無法得到測試質(zhì)量如語句覆蓋、路徑覆蓋等情況，也就無法對被測對象進(jìn)行 進(jìn)一步的分析。應(yīng)用較廣的分析覆蓋率的工具有Logiscope、TrueCoverage、PureCoverage等，它們的功能有強(qiáng)有弱，可以根據(jù) 實(shí)際情況采用。
為了提高單元測試的效率，特別是提高進(jìn)行回歸測試時(shí)的效率，需要在單元測試中引入自動(dòng)化。目前常用的方法是采用TCL語言編寫擴(kuò)展指令，構(gòu)造自己的單元測試自動(dòng)化。也可以直接采用開源的自動(dòng)化測試框架如CppUnit、JUnit等。
此外，在單元測試之前，還需要利用PC_Lint對被測代碼進(jìn)行檢查，排除代碼語法錯(cuò)誤，確保進(jìn)行單元測試的代碼已經(jīng)具備了基本質(zhì)量，保證單元測試能夠順利進(jìn)行，提高單元測試執(zhí)行效率。
3、單元測試者加強(qiáng)對被測軟件的全面了解
單元測試的目的除了要發(fā)現(xiàn)編碼中引入的錯(cuò)誤和發(fā)現(xiàn)代碼與詳細(xì)設(shè)計(jì)不一致的地方之外，還有一個(gè)目的是為了保證詳細(xì)設(shè)計(jì)的質(zhì)量。因?yàn)闇y試分析和測試用例設(shè)計(jì)需要依據(jù)詳細(xì)設(shè)計(jì)來進(jìn)行，這個(gè)過程實(shí)際上是對詳細(xì)設(shè)計(jì)的重新檢視，在這個(gè)過程中會(huì)發(fā)現(xiàn)以前評(píng)審中沒有發(fā)現(xiàn)的問題。
三、我們公司的單元測試 我們公司的單元測試才剛剛起步，質(zhì)量體系中尚無明確的規(guī)范，程序員對單元測試的意識(shí)也較淡薄。雖然在推行單元測試上取得了一些進(jìn)步，但很難落實(shí) 到實(shí)際的環(huán)節(jié)上，很多都是走過場的。不少程序員覺得任務(wù)大，時(shí)間趕，人手少，一接到任務(wù)就是先趕代碼完成工作量了，這其實(shí)是很普遍的現(xiàn)象。而且，絕大部分 程序員從骨子里不喜歡寫單元測試，這卻是不爭的事實(shí)。我們公司的開發(fā)人員在單元測試上多是走過場，而測試人員也只涉及到存儲(chǔ)過程的單元測試，且沒有單元測 試用例，測試方法存在誤區(qū)，導(dǎo)致測試帶有隨意性，效率低下。
要做好單元測試，還必須充分考慮到公司自身的實(shí)際情況。基于我們公司目前的諸多現(xiàn)狀，結(jié)合項(xiàng)目具體實(shí)際情況，在公司某一項(xiàng)目中，對單元測試做了如下理論結(jié)合實(shí)際的應(yīng)用。
1、項(xiàng)目經(jīng)理在項(xiàng)目計(jì)劃的過程定義文件中明確單元測試作為本項(xiàng)目的過程，確定在單元測試的各個(gè)階段的工作產(chǎn)物；
2、項(xiàng)目經(jīng)理制定單元測試計(jì)劃，明確測試目標(biāo)、測試方法、準(zhǔn)入準(zhǔn)則、準(zhǔn)處準(zhǔn)則、單元測試數(shù)據(jù)、單元測試工具、人力資源計(jì)劃、進(jìn)度計(jì)劃；
3、開發(fā)人員在編碼前設(shè)計(jì)測試用例，并且準(zhǔn)備單元測試代碼及設(shè)計(jì)文檔，項(xiàng)目組組織人員評(píng)審，測試人員必須參加；
4、開發(fā)人員在編碼完成提交產(chǎn)物前，必須做單元測試，可以是自測，也可以是開發(fā)人員互測，發(fā)現(xiàn)的缺陷必須提交缺陷庫，并提交單元測試報(bào)告。在人力資源緊張時(shí)，可以由測試人員執(zhí)行單元測試；
5、有了單元測試的缺陷數(shù)據(jù)，我們就可以分析，一般常見的缺陷有哪些類型，如何改進(jìn)；還可以發(fā)現(xiàn)哪些開發(fā)人員的編碼質(zhì)量，為獎(jiǎng)懲提供依據(jù)。
四、結(jié)論和展望
總而言之，單元測試將讓我們的開發(fā)工作變得更加輕松，讓我們對自己的代碼更加自信。無論是項(xiàng)目的規(guī)模大小，無論是時(shí)間緊迫的項(xiàng)目還是時(shí)間寬裕的項(xiàng)目，只要代碼不是一次寫完永不改動(dòng)，編寫單元測試就一定超值。我希望它能成為我們公司編碼過程中不可缺少的一部分。
單元測試僅僅是軟件質(zhì)量保證的一個(gè)環(huán)節(jié)，軟件的質(zhì)量由組織、流程和技術(shù)三個(gè)維度來決定，任何一個(gè)維度都不能單獨(dú)決定軟件的質(zhì)量。好的組織結(jié)構(gòu)可 以保證流程的順利實(shí)施，好的流程能提高軟件開發(fā)的規(guī)范性和可控性，從而提高軟件開發(fā)的效率和質(zhì)量，而采用了好的技術(shù)和有好的技術(shù)的載體--人，則從根本上 保證了軟件的質(zhì)量。
該項(xiàng)目在落實(shí)以上措施后，達(dá)到了一下效果：
1、在一定承擔(dān)上提升了軟件交付質(zhì)量；
2、測試部門反映：有效降低集成和系統(tǒng)測試投入的成本；
3、項(xiàng)目執(zhí)行周期比預(yù)期的縮短。
因此，論證了單元測試在軟件生產(chǎn)過程中作用。