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