資源描述：
《有效利用白盒工具提高代碼質(zhì)量》由會(huì)員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在教育資源-天天文庫。
1、有效利用白盒工具提高代碼質(zhì)量代碼質(zhì)量是在軟件滿足了設(shè)計(jì)功能的前提下，對軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。如何能夠有效提高代碼質(zhì)量，又節(jié)約程序員查找和修復(fù)bug的時(shí)間，成了一個(gè)難題。白盒測試工具的引入，恰好解決了這一難題。本文將闡述程序員如何有效利用白盒測試工具，提高代碼質(zhì)量和開發(fā)效率。 提高代碼質(zhì)量的巨大經(jīng)濟(jì)收益 從提高軟件投資回報(bào)的角度出發(fā)，企業(yè)應(yīng)在降低開發(fā)成本的同時(shí)，提高軟件的可用性，這就意味著盡量減少應(yīng)用程序中的bug和性能缺陷。而由于代碼編寫過程的人為因素，代碼中的bug是不可避免的。據(jù)統(tǒng)計(jì)，每千行軟件代碼中，就可能存在20到30個(gè)bug。在無法避免b
2、ug產(chǎn)生的情況下，如何發(fā)現(xiàn)并及時(shí)消除這些bug，就成了提高軟件投資回報(bào)的唯一可行辦法?！ ∈紫龋覀儊砜纯葱迯?fù)一個(gè)bug所需要的成本。在軟件交付周期的不同階段，修復(fù)一個(gè)bug所需的成本差別非常之大。越是到了軟件交付的后期，修復(fù)bug越困難，成本也就越高。從圖1可以看出，在測試階段修復(fù)bug的代價(jià)是開發(fā)階段的幾倍，而一旦產(chǎn)品上線，進(jìn)入維護(hù)期后，所需的代價(jià)更是達(dá)到幾十倍?！ 「鶕?jù)國際上的經(jīng)驗(yàn)，在測試階段修復(fù)一個(gè)bug的時(shí)間往往要比在代碼編寫階段要多出15到75倍。 因此，越早發(fā)現(xiàn)bug，越早解決，企業(yè)所付出的代價(jià)就越小。我們建議在軟件進(jìn)入測試階段之前就解決掉大部分的bug，即交付高質(zhì)量
3、代碼的意義所在?！ √岣叽a質(zhì)量的幾個(gè)關(guān)注點(diǎn) 代碼質(zhì)量是在程序滿足了設(shè)計(jì)功能的前提下，對軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。為了保證交付給測試人員的代碼能夠滿足上述質(zhì)量方面的要求，在開發(fā)階段應(yīng)該對代碼進(jìn)行如下方面的測試： 1.靜態(tài)代碼分析 為保正團(tuán)隊(duì)內(nèi)各程序員之間編寫習(xí)慣的一致性和規(guī)范性，消除容易導(dǎo)致錯(cuò)誤的語法隱患，通常會(huì)制定一系列的編程規(guī)范。靜態(tài)代碼分析，即要求程序員對所有代碼行進(jìn)行規(guī)范性檢查，消滅潛在隱患，提高代碼的可靠性。 靜態(tài)代碼分析的好處在于能發(fā)現(xiàn)大量潛在的軟件缺陷。比如下面一段VB.NET代碼中，使用Asc()函數(shù)返回ASCII碼。If(Asc(
4、mChar)<>13)And(Asc(mChar)<>10)Then 從語法上分析，這段代碼是完全正確的。但若mChar為空，Asc()就會(huì)拋出ArgumentException錯(cuò)誤，導(dǎo)致程序異?；蛑袛?。因此，從代碼可靠性的角度出發(fā)，在使用Asc()之前，應(yīng)對引用的字符串作判斷，如下：IfLen(strchars)>0Andstrchars<>nothingThenAscii=Asc(strchars) 這樣，就可以避免潛在的異常錯(cuò)誤。而類似的這樣問題，IDE的語法檢查通常沒有辦法，只有通過手工或自動(dòng)化的代碼檢查來發(fā)現(xiàn)和解決?！ ]有經(jīng)過靜態(tài)分析的程序可能跑起來不錯(cuò)，而實(shí)際上可能像
5、一塊奶酪一樣，滿身是漏洞，問題一出現(xiàn)就很嚴(yán)重而且直接面對問題的是可能是最終用戶?！ ?、代碼覆蓋率分析 只有經(jīng)過充分測試的代碼，質(zhì)量才是有保障的。而程序員在做單元測試時(shí)，往往很難遍歷所有的分支情況，尤其是程序?qū)﹀e(cuò)誤輸入的反應(yīng)往往被忽略。因此，對代碼的測試覆蓋率分析是保證交付高質(zhì)量代碼的關(guān)鍵。利用一些代碼覆蓋率檢查工具，不僅可以了解代碼的整體測試水平，也能夠指出未經(jīng)過測試的代碼，給程序員以方向上的指引?！ ?、運(yùn)行時(shí)內(nèi)存分析 內(nèi)存往往是導(dǎo)致嚴(yán)重性能故障的根本原因，而一些不良的編程習(xí)慣經(jīng)常會(huì)導(dǎo)致運(yùn)行時(shí)的內(nèi)存泄露。這類問題幾乎無法通過單元測試或功能驗(yàn)證來發(fā)現(xiàn)，而又經(jīng)常被程序員忽視，直到
6、軟件投入生產(chǎn)后才逐漸暴露出來，這時(shí)再查找和修復(fù)內(nèi)存問題就非常困難了。因此，應(yīng)盡量在代碼交付之前消滅內(nèi)存問題。運(yùn)行時(shí)內(nèi)存分析，即在代碼調(diào)試階段，對所有對象的內(nèi)存占用狀態(tài)的運(yùn)行時(shí)分析，查找內(nèi)存泄露的隱患?！ ∵\(yùn)行時(shí)內(nèi)存分析的第一步就是內(nèi)存使用的監(jiān)控，以便了解在運(yùn)行期間，程序?qū)?nèi)存的使用和釋放情況，查找程序?qū)?nèi)存的不當(dāng)使用?！ ∪缦聢D所示，在A點(diǎn)位置，程序穩(wěn)定運(yùn)行，對內(nèi)存的使用也基本穩(wěn)定。在B點(diǎn)，我們打開程序的某個(gè)窗口時(shí)，程序使用了更多的內(nèi)存來儲(chǔ)存新的對象。當(dāng)窗口關(guān)閉時(shí)，這些對象被釋放，內(nèi)存也應(yīng)隨之釋放。而從圖上B點(diǎn)之后的內(nèi)存使用情況來看，這些內(nèi)存并沒有被釋放。因而，可能存在著內(nèi)存泄露。在
7、C點(diǎn)和D點(diǎn)再次打開前面的窗口，內(nèi)存還是不斷增加而沒有回收?？梢詳喽ǎ摯翱趯?yīng)的代碼存在內(nèi)存泄露的問題?！ ‰m然無論是Java還是.Net，都提供了自動(dòng)的內(nèi)存回收機(jī)制，但內(nèi)存泄露仍是引起應(yīng)用系統(tǒng)性能劣化的一個(gè)主要原因。除此之外，運(yùn)行時(shí)的內(nèi)存分析還應(yīng)深入的對每個(gè)對象、方法的內(nèi)存占用進(jìn)行分析，以便為內(nèi)存使用的優(yōu)化提供方向?！ ?、性能分析和優(yōu)化 代碼的執(zhí)行效率，直接影響著應(yīng)用程序的可用性和可靠性。因此，軟件的性能問題應(yīng)該在開發(fā)階段就充分加以考慮，提高代碼的執(zhí)
