試論提高軟件質(zhì)量的利器-Valgrind

試論提高軟件質(zhì)量的利器-ValgrindPurifyPlus投資回報分析花費更少的時間修補BUG，每位開發(fā)人員每年節(jié)約2.6研究表明假設(shè)一個中等工作團隊為5人，則每個團隊每月出現(xiàn)3次關(guān)鍵的內(nèi)存訪問錯誤。也就是每位開發(fā)人員每月0.6個錯誤。使用常規(guī)工具發(fā)現(xiàn)一個內(nèi)存訪問錯誤平均花費16小時。0.6個錯誤/月/開發(fā)人員×16小時/錯誤＝9.6小時/月用來修補內(nèi)存錯誤百分之六十的被調(diào)查者認為，使用PurifyPlus發(fā)現(xiàn)運行時錯誤帶來的生產(chǎn)率系數(shù)大約是10倍，這就意味著過去用十小時發(fā)現(xiàn)并糾正的錯誤可以在不到一小時內(nèi)得以糾正。即：使用常規(guī)的工具9.6小時×1/10（Purify生產(chǎn)率系數(shù)）＝0.96小時/月。這說明每位開發(fā)人員每月節(jié)省8.64小時（＝8.64）。按這樣的方法計算一年，8.64小時/月×12月＝103.7小時/40小時，這樣就可以換算成每年節(jié)省2.6103.7小時/40小時＝2.6PurifyPlus投資回報分析花費更少的時間解決性能每位開發(fā)人員每年節(jié)省1.96周研究表明每位程序員花費大約5％的時間用于優(yōu)化/改進程序性能。這樣計算的話，不使用PurifyPlus，程序員每年花費2.4周改進程序性能：0.05×48周/年＝2.4周/年。當使用了PurifyPlus解決性能問題后，生產(chǎn)率增益的系數(shù)估計為5倍，這就意味著以前花費5小時糾正的錯誤現(xiàn)在僅需要1小時。在贏得這個5倍的"量化的生產(chǎn)率系數(shù)"后，每位開發(fā)人員每年將僅僅使用0.48周來解決性能問題：使用常規(guī)工具需要2.4小時×1/5（量化的生產(chǎn)率因子）＝0.48周/年。這表明每位開發(fā)人員每年節(jié)省將近兩周的時間（2.4－0.48＝1.92）PurifyPlus投資回報分析提早發(fā)現(xiàn)BUG每年節(jié)省7000美元PurifyPlus通過突出顯示沒有完全通過測試并且可能仍舊包含BUG或性能問題的代碼段，從而改進錯誤檢測。通過提早發(fā)現(xiàn)BUG，PurifyPlus帶來了顯著的費用節(jié)省。公認的行業(yè)標準表明在軟件交付前修補BUG的花費小于10倍。使用PurifyPlus的開發(fā)人員與不使用PurifyPlus的開發(fā)人員相比，每年平均多發(fā)現(xiàn)10個BUG在軟件交付后修補一個BUG的開銷估計是700美元，而在交付前修補一個BUG的開銷僅為70美元。對于每位開發(fā)人員來說，使用PurifyPlus提前發(fā)現(xiàn)BUG節(jié)省的成本每年就是7000美元：10BUG×700美元交付后成本＝7000美元好的工具可以幫助開發(fā)人員

每年多活一個月BUG的危害增加產(chǎn)品的開發(fā)時間、可能會把產(chǎn)品掛掉增加研發(fā)人員的勞動、經(jīng)常加班可能會把人掛掉不斷的消耗公司的利潤嚴重影響研發(fā)人員的自信心和學習機會導致與家人團聚的時間減少，降低幸福指數(shù)影響壽命影響同事間感情致命的BUG可能會把公司掛掉軟件BUG分類如何降低軟件的BUG使用成熟的代碼和框架少直接使用裸API多使用自己積累的開發(fā)代碼使用CBB，COTS使用成熟的開源框架ACE,ICE,BOOST,STL技術(shù)代碼與業(yè)務代碼解耦技術(shù)代碼+業(yè)務代碼=產(chǎn)品代碼 抽象技術(shù)代碼->好的設(shè)計模式->形成框架->通用中間件抽象業(yè)務代碼->好的設(shè)計模式->形成框架->領(lǐng)域中間件如何降低軟件的BUG對句柄資源在應用層進行資源使用統(tǒng)計文件,SOCKET,內(nèi)存等系統(tǒng)資源不直接使用系統(tǒng)的內(nèi)存管理，在應用層開發(fā)自己的內(nèi)存池可以提高運行效率，減少頻繁內(nèi)存分配內(nèi)存的分配釋放可以自己控制，避免內(nèi)存泄露如何降低軟件的BUG編寫代碼盡量符合OCP原則面對變化優(yōu)先考慮不增加代碼面對變化優(yōu)先考慮增加新的模塊面對變化優(yōu)先考慮增加新的文件面對變化優(yōu)先考慮增加新的類面對變化優(yōu)先考慮增加新的函數(shù)模塊對外接口要保持寬進嚴出原則如何降低軟件的BUG盡量少用鎖，用鎖的最高境界是不用鎖禁止使用遞歸鎖、交叉鎖、嵌套鎖建議多使用ScopedLocking避免忘記釋放鎖對外接口采用Thread-SafeInterface避免自死鎖采用成熟的網(wǎng)絡(luò)I/O模型、少用SELECT模型單線程能解決問題就少使用多線程、多線程下優(yōu)先采用靜態(tài)多線程能用數(shù)組就不用堆進程間通信優(yōu)先使用文本協(xié)議如何降低軟件的BUG養(yǎng)成好的編碼習慣使用簡單的語法少使用多重繼承、多級繼承、嵌套、友元編寫簡單的類功能單一、接口清晰、函數(shù)不要過多編寫簡單的函數(shù)輸入?yún)?shù)[0,3]個、輸出參數(shù)[0,1]、少用**、少用遞歸行數(shù)[0,20]=20%,(20,50]=70%,(50,100]=10%,(100,+~)=0%編寫簡單的指令如何降低軟件的BUG開發(fā)做好單元測試,需要有單元測試代碼長時間在Valgrind環(huán)境運行，發(fā)現(xiàn)潛在BUG每個模塊確保代碼執(zhí)行覆蓋率在90%以上關(guān)鍵代碼要Review如何降低軟件的BUGSE要充分理解用戶需求、對需求負責開發(fā)代碼要確保設(shè)計符合需求、對設(shè)計負責測試代表要在產(chǎn)品各個階段進行測試、對產(chǎn)品質(zhì)量負責開發(fā)人員對代碼負責項目經(jīng)理對進度、質(zhì)量負責做好配置管理如何降低軟件的性能如何定位軟件BUGLOG日志做到內(nèi)部模塊區(qū)別時間精確到毫秒異步調(diào)用可重定向到網(wǎng)絡(luò)如何定位軟件BUGTelnet診斷通過標準的Telnet客戶端實現(xiàn)遠程控制通過命令可以查看程序內(nèi)部狀態(tài)通過命令可以修改程序內(nèi)部狀態(tài)如何定位軟件BUG加入捕獲代碼LONGWINAPICocaUnhandledFilter(struct_EXCEPTION_POINTERS*lpExceptionInfo){ HANDLEhFile=::CreateFile(szFileName,GENERIC_WRITE,0,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL,NULL); if(hFile!=INVALID_HANDLE_VALUE) { MINIDUMP_EXCEPTION_INFORMATIONExInfo; ExInfo.ThreadId=::GetCurrentThreadId(); ExInfo.ExceptionPointers=lpExceptionInfo; ExInfo.ClientPointers=false; BOOLbOK=MiniDumpWriteDump(GetCurrentProcess(),GetCurrentProcessId(),hFile,MiniDumpNormal,&ExInfo,NULL,NULL); if(bOK) printf("CreateDumpFile=%sSuccess!\n",szFileName); else printf("MiniDumpWriteDumpFailed:%d\n",GetLastError());

::CloseHandle(hFile); } returnret;}如何定位軟件BUG診斷工具IBMRationalPurifyPlusPurifyPlus是一套測試工具集合，擁有三個工具PureCoverage、Quantifyis和Purify，您可以用這套工具完成對代碼覆蓋率、性能和內(nèi)存分析的運行時分析。它可以加強自動化測試工作，改善產(chǎn)品性能和質(zhì)量PureCoverage用來進行代碼覆蓋率分析：它測量在所有測試用例中多少代碼運行了，多少代碼沒有運行Quantify用來進行性能分析：分析應用程序的性能瓶頸Purify用來進行內(nèi)存分析：它幫助尋找應用程序的內(nèi)存泄漏和錯誤的內(nèi)存使用，這些有可能導致應用程序崩潰

支持Windows&Linux,C/C++,Java要錢的WinDbg微軟提供的基于源碼級的調(diào)試工具功能上類似Linux下的GDB支持Kernel模式調(diào)試和User模式調(diào)試支持DMP文件分析支持二次開發(fā)WinDbg-如何定位程序崩潰ValgrindValgrind是一款動態(tài)分析工具，能自動檢測內(nèi)存管理和線程錯誤，以及發(fā)現(xiàn)程序的性能，以及Cache的使用、能直穿程序錯誤的心臟，真可謂是程序員的瑞士軍刀Valgrind基于仿真技術(shù)，而非插入目標代碼運行環(huán)境:X86/Linux,AMD64/Linux,ARM/Linux,PPC32/Linux,PPC64/Linux,X86/DarwinandAMD64/DarwinOnlySupportC/C++ValgrindValgrindMemcheck

isamemoryerrordetector.Ithelpsyoumakeyourprograms,particularlythosewritteninCandC++,morecorrect.Cachegrind

isacacheandbranch-predictionprofiler.Ithelpsyoumakeyourprogramsrunfaster.Callgrind

isacall-graphgeneratingcacheprofiler.IthassomeoverlapwithCachegrind,butalsogatherssomeinformationthatCachegrinddoesnot.Helgrind

isathreaderrordetector.Ithelpsyoumakeyourmulti-threadedprogramsmorecorrect.DRD

isalsoathreaderrordetector.ItissimilartoHelgrindbutusesdifferentanalysistechniquesandsomayfinddifferentproblems.Massif

isaheapprofiler.Ithelpsyoumakeyourprogramsuselessmemory.DHAT

isadifferentkindofheapprofiler.Ithelpsyouunderstandissuesofblocklifetimes,blockutilisation,andlayoutinefficiencies.Valgrind-Memcheck

對未初始化內(nèi)存的使用讀/寫釋放后的內(nèi)存塊讀/寫超出malloc分配的內(nèi)存塊讀/寫不適當?shù)臈Ｖ袃?nèi)存塊內(nèi)存泄漏，指向一塊內(nèi)存的指針永遠丟失不正確的malloc/free或new/delete匹配memcpy()相關(guān)函數(shù)中的dst和src指針重疊ValgrindExle:valgrind–tool=memcheck--leak-check=full--xml=yes--xml-file="log.xml"myprogvalgrind–tool=helgrind--xml=yes--xml-file="log.xml"myprogValgrind-HelgrindHelgrindisaValgrindtoolfordetectingsynchronisationerrorsinC,C++andFortranprogramsthatusethePOSIXpthreadsthreadingprimitives

MisusesofthePOSIXpthreadsAPI.Potentialdeadlocksarisingfromlockorderingproblems.Dataraces--accessingmemorywithoutadequatelockingorsynchronisation.Problemsliketheseoftenresultinunreproducible,timing-dependentcrashes,deadlocksandothermisbehaviour,andcanbedifficulttofindbyothermeans

Valgrind-Helgrindunlockinganot-loc