如何發現客戶端軟件中的內存泄露？（轉載）
上一篇 / 下一篇 2008-10-08 13:32:05 / 個人分類：轉載
http://www.51testing.com/index.php?uid/10851/action/viewspace/itemid/84835/php/1
51testing本週的問題：如何發現客戶端軟件中的內存泄露？詳細的問題描述請參考以下鏈接
http://bbs.51testing.com/thread-117015-1-1.html
如何發現客戶端軟件中的內存泄露？我的看法是：檢測內存泄漏的問題應該儘早進行，它絕不應該是系統時的主要目標。也就是說，檢查是否存在內存泄漏，應該從編碼時就要考慮，和集成測試時要重點檢查。如果前期沒有考慮，等到了系統測試纔想起檢查或者才發現泄漏，爲時已晚，此時再去定位泄漏的位置，太難太難了，它可能會讓你的交付日期delay不確定的時間。
最近看了一些自動錯誤預防（AEP）的理論，我深受啓發。作爲測試人員的我們，從“發現錯誤”轉變到“幫助開發人員預防錯誤”，這將是一個巨大的轉變。所以說，下面我的答案中的第一點，我先說如何預防內存泄漏的問題，然後再講如何發現。
1 如何在開發過程中有效預防內存泄漏？
第一步：遵循“好”的編程規則
“好”的編程規則是各位前輩經驗和教訓的集合，好的編程規則堪稱開發者的“聖經”。遵循統一的編程規則，可以讓開發新手少走好多彎路，可以讓項目整體的質量維持一個起碼的“質量底線”。
有關內存泄漏方面的規則主要是“內存管理”方面的，舉幾個簡單的，如下
×用malloc或new申請內存之後，立即檢查指針值是否爲NULL（防止使用指針值爲NULL的內存）
×動態內存的申請與釋放是否配對（防止內存泄漏）
×malloc語句是否正確無誤？例如字節數是否正確？類型轉換是否正確
×是否出現野指針，例如用free或delete釋放了內存之後，忘記將指針設置爲NULL
... ...
第二步：積極主動檢測“內存泄漏”
嚴格遵循好的編程規則，可以讓程序員在代碼中儘量少的引入bug，但一旦不小心引入了，怎麼辦？這就要求我們在單元測試和集成測試中嚴格把關。
在這個階段，單靠程序員或者測試員通過“代碼走查”的方式檢查內存泄漏，客戶的實踐和我的經驗告訴我，這將是“不切實際”的，無論效率還是時間。如果能夠藉助於一些專業的工具的話，情況可能就不一樣了。
如果你的程序是用Visual C++ 6.0開發，那麼Numega的BoundsChecker將是你檢測“內存泄漏”最好的選擇，如果是Visual C++.NET，可以試一下Compuware的DevPartner。
如果你的程序基於Unix或者平臺，使用C或者C++，可以考慮一下開源的工具valgrind，我的朋友跟我說，它在一定程度上比的Purify更出色。
上面的工具都要求程序能夠動態運行起來，而且測試用例需要你自己準備。
如果你正處於單元測試或集成測試階段，程序代碼量已經足夠大，而且還不能夠動態運行，要儘早檢測代碼中的“內存泄漏”問題，該怎麼辦？此時你可以試用一下目前最新的靜態分析：
×它不要求代碼能夠動態運行
×也不需要你來編寫測試用例
×只需要代碼能夠正常編譯，就可以發現代碼只有在執行過程中才出現的錯誤，當然也包括內存泄漏。
這方面的工具有Klocwork的K7，Coverity的SQS，以及C++test中的BugDetective，其中最“物美價廉”的就是c++test的BugDetective。
2 如何發現客戶端軟件的“內存泄漏”？
如果開發過程中已經按照我上面提到的去做，相信發佈後的程序存在“內存泄漏”的可能性幾乎爲零。
如果開發過程已經到了後期，系統測試已經開始做了，還要發現內存泄漏，這個時候我希望你能夠拿到源代碼。如果有源代碼，你還可以考慮1中的第二步，藉助於專業的工具協助，雖然可能效果不一定特別理想，但總比下面我提到的方法更好一些。
當然作爲測試人員，我當然也理解事情總沒有想像那麼完美。我們通常會碰到“需要在系統測試階段檢測是否有內存泄漏，而且沒有源代碼”的難題。我曾經也遇到過。
記得那還是2002年的事情了。當時我承接的項目是一個電力行業的自動化系統，分爲server端和client端，典型的c/s模式，老闆要求在測試功能的同時順便檢查內存泄漏的問題，因爲這個client端在客戶那裏可能是長時間不間斷運行的，雖然客戶很少操作。我當時很爲難，因爲沒有源代碼，我甚至無法做“代碼走查”。在做的同時，我一直在琢磨...... 採用什麼手段呢？
最後，藉助於，我出色的完成了任務，起碼我的老闆相信我的測試是可信的。我的方法是這樣的。
×首先諮詢開發方，瞭解到關於內存操作頻繁的功能點和模塊
×從我的功能測試用例中挑選出和這些功能點和模塊相關的測試用例
×找到一個“純淨”的機器，上面除了和被測的client端外，沒有任何應用，這樣做是爲了排除其他應用可能存在的干擾。
×藉助於WinRunner，自動化這些用例，形成自動化的腳本；在腳本的最後，添加“切換到任務管理器”“記錄該client進程所佔用內存數據到文件”的操作腳本。
×連續運行N個小時
×最後我打開這個數據文件，可以發現在該客戶端運行過程中，每次執行完特定的測試用例後，記錄的內存佔用數據。當時我得出的結論是該client程序有“少許”的內存泄漏，因爲在連續運行了72小時後，內存使用增加了近百分之十幾。我會把這些數據導入到EXCEL中繪成了一個圖表，這樣更直觀一些。經過簡單的計算（內存的增量/用例循環次數），得到用例每次執行後增加的內存使用值，即泄漏的內存數量，然後把操作過程和這個結果一起交給開發方，最後開發方根據我的信息，真的找到了一處有內存泄漏的地方，雖然泄漏的數量很少。
以上就是我有過的一個類似的經歷，我覺得可以提供給大家參考，同時也可以“舉一反三，融會貫通”。如B/S的客戶端控件，可以用協助完成。
在測試的最後階段要去發現甚至定位內存泄漏挺難的，但只要發揮我們測試人員的主觀能動性，總是找到一些“旁門左道”的測試手段。
最後，我個人認爲，從時間成本和各種風險考慮，要避免內存泄漏的問題，還是要回到前期的預防，即編程過程的規則檢查和單元測試階段主動的檢測。
一家之言，歡迎討論。