有效利用白盒工具提高代碼質(zhì)量.doc

有效利用白盒工具提高代碼質(zhì)量代碼質(zhì)量是在軟件滿足了設(shè)計功能的前提下，對軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。如何能夠有效提高代碼質(zhì)量，又節(jié)約程序員查找和修復(fù)bug的時間，成了一個難題。白盒測試工具的引入，恰好解決了這一難題。本文將闡述程序員如何有效利用白盒測試工具，提高代碼質(zhì)量和開發(fā)效率。提高代碼質(zhì)量的巨大經(jīng)濟收益從提高軟件投資回報的角度出發(fā)，企業(yè)應(yīng)在降低開發(fā)成本的同時，提高軟件的可用性，這就意味著盡量減少應(yīng)用程序中的bug和性能缺陷。而由于代碼編寫過程的人為因素，代碼中的bug是不可避免的。據(jù)統(tǒng)計，每千行軟件代碼中，就可能存在20到30個bug。在無法避免bug產(chǎn)生的情況下，如何發(fā)現(xiàn)并及時消除這些bug，就成了提高軟件投資回報的唯一可行辦法。首先，我們來看看修復(fù)一個bug所需要的成本。在軟件交付周期的不同階段，修復(fù)一個bug所需的成本差別非常之大。越是到了軟件交付的后期，修復(fù)bug越困難，成本也就越高。從圖1可以看出，在測試階段修復(fù)bug的代價是開發(fā)階段的幾倍，而一旦產(chǎn)品上線，進入維護期后，所需的代價更是達到幾十倍。根據(jù)國際上的經(jīng)驗，在測試階段修復(fù)一個bug的時間往往要比在代碼編寫階段要多出15到75倍。因此，越早發(fā)現(xiàn)bug，越早解決，企業(yè)所付出的代價就越小。我們建議在軟件進入測試階段之前就解決掉大部分的bug，即交付高質(zhì)量代碼的意義所在。提高代碼質(zhì)量的幾個關(guān)注點代碼質(zhì)量是在程序滿足了設(shè)計功能的前提下，對軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。為了保證交付給測試人員的代碼能夠滿足上述質(zhì)量方面的要求，在開發(fā)階段應(yīng)該對代碼進行如下方面的測試：1.靜態(tài)代碼分析為保正團隊內(nèi)各程序員之間編寫習(xí)慣的一致性和規(guī)范性，消除容易導(dǎo)致錯誤的語法隱患，通常會制定一系列的編程規(guī)范。靜態(tài)代碼分析，即要求程序員對所有代碼行進行規(guī)范性檢查，消滅潛在隱患，提高代碼的可靠性。靜態(tài)代碼分析的好處在于能發(fā)現(xiàn)大量潛在的軟件缺陷。比如下面一段VB .NET代碼中，使用Asc()函數(shù)返回ASCII碼。If (Asc(mChar) 13) And (Asc(mChar) 10) Then從語法上分析，這段代碼是完全正確的。但若mChar為空，Asc()就會拋出ArgumentException錯誤，導(dǎo)致程序異?；蛑袛唷Ｒ虼?，從代碼可靠性的角度出發(fā)，在使用Asc()之前，應(yīng)對引用的字符串作判斷，如下：If Len(strchars) 0 And strchars nothing Then Ascii = Asc(strchars)這樣，就可以避免潛在的異常錯誤。而類似的這樣問題，IDE的語法檢查通常沒有辦法，只有通過手工或自動化的代碼檢查來發(fā)現(xiàn)和解決。沒有經(jīng)過靜態(tài)分析的程序可能跑起來不錯，而實際上可能像一塊奶酪一樣，滿身是漏洞，問題一出現(xiàn)就很嚴(yán)重而且直接面對問題的是可能是最終用戶。2、代碼覆蓋率分析只有經(jīng)過充分測試的代碼，質(zhì)量才是有保障的。而程序員在做單元測試時，往往很難遍歷所有的分支情況，尤其是程序?qū)﹀e誤輸入的反應(yīng)往往被忽略。因此，對代碼的測試覆蓋率分析是保證交付高質(zhì)量代碼的關(guān)鍵。利用一些代碼覆蓋率檢查工具，不僅可以了解代碼的整體測試水平，也能夠指出未經(jīng)過測試的代碼，給程序員以方向上的指引。3、運行時內(nèi)存分析內(nèi)存往往是導(dǎo)致嚴(yán)重性能故障的根本原因，而一些不良的編程習(xí)慣經(jīng)常會導(dǎo)致運行時的內(nèi)存泄露。這類問題幾乎無法通過單元測試或功能驗證來發(fā)現(xiàn)，而又經(jīng)常被程序員忽視，直到軟件投入生產(chǎn)后才逐漸暴露出來，這時再查找和修復(fù)內(nèi)存問題就非常困難了。因此，應(yīng)盡量在代碼交付之前消滅內(nèi)存問題。運行時內(nèi)存分析，即在代碼調(diào)試階段，對所有對象的內(nèi)存占用狀態(tài)的運行時分析，查找內(nèi)存泄露的隱患。運行時內(nèi)存分析的第一步就是內(nèi)存使用的監(jiān)控，以便了解在運行期間，程序?qū)?nèi)存的使用和釋放情況，查找程序?qū)?nèi)存的不當(dāng)使用。如下圖所示，在A點位置，程序穩(wěn)定運行，對內(nèi)存的使用也基本穩(wěn)定。在B點，我們打開程序的某個窗口時，程序使用了更多的內(nèi)存來儲存新的對象。當(dāng)窗口關(guān)閉時，這些對象被釋放，內(nèi)存也應(yīng)隨之釋放。而從圖上B點之后的內(nèi)存使用情況來看，這些內(nèi)存并沒有被釋放。因而，可能存在著內(nèi)存泄露。在C點和D點再次打開前面的窗口，內(nèi)存還是不斷增加而沒有回收。可以斷定，該窗口對應(yīng)的代碼存在內(nèi)存泄露的問題。雖然無論是Java還是.Net，都提供了自動的內(nèi)存回收機制，但內(nèi)存泄露仍是引起應(yīng)用系統(tǒng)性能劣化的一個主要原因。除此之外，運行時的內(nèi)存分析還應(yīng)深入的對每個對象、方法的內(nèi)存占用進行分析，以便為內(nèi)存使用的優(yōu)化提供方向。4、性能分析和優(yōu)化代碼的執(zhí)行效率，直接影響著應(yīng)用程序的可用性和可靠性。因此，軟件的性能問題應(yīng)該在開發(fā)階段就充分加以考慮，提高代碼的執(zhí)行效率，而不是把性能問題全部留到壓力測試階段去解決。性能分析和優(yōu)化，即要求在代碼提交之間，對每一個功能實現(xiàn)的響應(yīng)時間以及每個方法的效率進行分析，并對運行效率較低的代碼進行優(yōu)化，從而提高代碼的整體性能，保證交付高質(zhì)量的代碼。程序員總是被要求優(yōu)化某段代碼，縮短執(zhí)行時間，但這并不是一件容易的事情。困難就在于，代碼執(zhí)行是一個非常復(fù)雜的過程，包含了太多的分支和無數(shù)的方法、代碼行，往往讓程序員無從著手。這就需要借助一些動態(tài)的代碼分析工具，幫助程序員了解每個方法及代碼行的執(zhí)行效率，從而有針對性地對那些執(zhí)行時間最長的方法或代碼行進行性能改進。動態(tài)代碼分析工具應(yīng)能夠提供諸如運行期間調(diào)用了哪些文件、方法、代碼行，每個文件、方法和代碼行的執(zhí)行時間、對總體運行時間的影響程度等等。有了這些信息，程序員就能夠找出影響執(zhí)行時間的關(guān)鍵路徑，有效改進代碼性能。5、 線程分析、錯誤檢測在Java編程中，線程是一個非常好的技術(shù)，它可以讓程序更加靈活 更加強大。但是，線程技術(shù)的誤用 同樣也會帶來非常嚴(yán)重的問題，而且線程問題是最難定位和修復(fù)的問題之一。在代碼交付之前，程序員應(yīng)充分分析和判斷代碼執(zhí)行過程中是否存在線程死鎖以及代碼在什么位置使用了鎖和同步機制等等，避免將線程問題拖延到系統(tǒng)測試階段。與性能分析類似，線程的死鎖很難通過手工的方式去判斷，必須日借助動態(tài)的代碼分析工具，了解線程間的調(diào)用次序、同步機制以及判斷死鎖。告別“刀耕火種”的手工時代隨著軟件應(yīng)用環(huán)境的日趨復(fù)雜，對軟件質(zhì)量的要求越來越高。而隨著敏捷式開發(fā)等新的開發(fā)方式的出現(xiàn)，開發(fā)的周期越來越短。顯然，再依靠過去人工的方式逐行Review代碼、統(tǒng)計測試覆蓋率、查找bug等，實在是力不從心。幸運的是，越來越強大的白盒測試工具的出現(xiàn)，彌補了這一點人力的不足。自動化白盒工具的引入目前市場上存在著多種多樣的白盒測試工具，有的是只為某項測試而設(shè)計的開源軟件，如僅限于代碼覆蓋率的檢查，也有功能強大、覆蓋面廣的商業(yè)套裝軟件，如Compuware的DevPartner系列、IBM的Rational系列工具等。筆者在這里簡單介紹幾款主流工具，供有興趣的讀者參考。1、Compuware DevPartner工具。雖然Compuware在國內(nèi)的知名度還不是很高，但在北美市場，其白盒測試工具DevPartner卻是聲名遠播、屢屢獲獎，在最近的Visual Studio雜志的2008年工具評選中，其DevPartner Studio再次贏得了最受讀者青睞獎 。DevPartner主要有面向.Net和Java兩個版本，提供代碼覆蓋率統(tǒng)計、靜態(tài)代碼檢查、內(nèi)存分析和性能分析等多種分析手段，使用相對簡單，可以與Visual Studio或Eclipse等開發(fā)工具IDE集成，但暫時還沒有中文版本。2、IBM Rational工具集IBM的Rational系列也是一套為廣大讀者熟知的白盒工具集，如用于覆蓋率檢查的PureCoverage和內(nèi)存檢查的Purity。Rational系列工具對使用人員的專業(yè)技能要求較高，要想把這個工具用好，要求每個成員至少有兩年的使用經(jīng)驗。3、C+ TestC+ TesT是ParASoft公司出品的一個針對C/C+源代碼進行自動化單元測試的工具，支持白盒測試、黑盒測試以及回歸功測試。C+ Test對于簡單的靜態(tài)代碼分析和邊界測試來說，是一款非常不錯的工具，但由于自身性能問題，筆者認(rèn)為不適合用于大型項目的開發(fā)。如何挑選白盒測試工具工欲善其事，必先利其器。挑選一款合適的白盒測試工具，能夠有效的提高代碼質(zhì)量和節(jié)約開發(fā)人員的時間。下面筆者就結(jié)合自己所知，嘗試解讀挑選白盒測試工具的幾個考慮因素。1.功能因素首先，應(yīng)考慮工具支持的語言和平臺。目前主流測試工具支持的開發(fā)語言包括.Net和Java，針對不同的語言，實現(xiàn)方式一般有較大差異。其次，選擇適合的功能。并非功能越豐富越好，而是應(yīng)該選擇適用于自己應(yīng)用場景和測試要求的工具。若對軟件質(zhì)量的要求較為嚴(yán)格，如軍工、航天軟件，則需要更多、更強的的白盒測試手段支持。若一般的自用或簡單商用軟件，則可以考慮某些功能簡單又有較強針對性的工具，甚至是開源工具。再次，要考慮工具的集成能力。那些提供與開發(fā)環(huán)境向集成的白盒測試工具，能夠避免程序員在開發(fā)和調(diào)試階段在多個窗口之間頻繁切換，節(jié)約寶貴的時間。2、價格因素任何一個軟件的開發(fā)，都必須考慮成本的壓力。對功能的要求越高，相應(yīng)的工具軟件肯定越昂貴，例如Rational就不是每個企業(yè)都負(fù)擔(dān)得起的。3、易用性在選擇白盒工具時，還要考慮到使用人員的技術(shù)素養(yǎng)以及工具的易用性。某些工具雖然功能強大，但易用性不高，需要較長時間摸索