2、如何发现客户端软件的“内存泄漏”？

　　如果开发过程中已经按照我上面提到的去做，相信发布后的程序存在“内存泄漏”的可能性几乎为零。

　　如果开发过程已经到了后期，系统测试已经开始做了，还要发现内存泄漏，这个时候我希望你能够拿到源代码。如果有源代码，你还可以考虑1中的第二步，借助于专业的工具协助，虽然可能效果不一定特别理想，但总比下面我提到的方法更好一些。

　　当然作为测试人员，我当然也理解事情总没有想像那么完美。我们通常会碰到“需要在系统测试阶段检测是否有内存泄漏，而且没有源代码”的难题。我曾经也遇到过。

　　记得那还是2002年的事情了。当时我承接的项目是一个电力行业的自动化系统，分为server端和client端，典型的c/s模式，老板要求在测试功能的同时顺便检查内存泄漏的问题，因为这个client端在客户那里可能是长时间不间断运行的，虽然客户很少操作。我当时很为难，因为没有源代码，我甚至无法做“代码走查”。在做功能测试的同时，我一直在琢磨...... 采用什么手段呢？

　　最后，借助于WinRunner，我出色的完成了任务，起码我的老板相信我的测试是可信的。我的方法是这样的。

　　● 首先咨询开发方，了解到关于内存操作频繁的功能点和模块

　　● 从我的功能测试用例中挑选出和这些功能点和模块相关的测试用例

　　● 找到一个“纯净”的机器，上面除了操作系统和被测的client端外，没有任何其他应用，这样做是为了排除其他应用可能存在的干扰。

　　● 借助于WinRunner，自动化这些用例，形成自动化的脚本；在脚本的最后，添加“切换到Windows任务管理器”“记录该client进程所占用内存数据到文件”的操作脚本。

　　● 连续运行N个小时

　　● 最后我打开这个数据文件，可以发现在该客户端运行过程中，每次执行完特定的测试用例后，记录的内存占用数据。当时我得出的结论是该client程序有“少许”的内存泄漏，因为在连续运行了72小时后，内存使用增加了近百分之十几。我会把这些数据导入到EXCEL中绘成了一个图表，这样更直观一些。经过简单的计算（内存的增量/用例循环次数），得到用例每次执行后增加的内存使用值，即泄漏的内存数量，然后把操作过程和这个结果一起交给开发方，最后开发方根据我的信息，真的找到了一处有内存泄漏的地方，虽然泄漏的数量很少。

　　以上就是我有过的一个类似的经历，我觉得可以提供给大家参考，同时也可以“举一反三，融会贯通”。如B/S的客户端控件，可以用QTP协助完成。

　　在测试的最后阶段要去发现甚至定位内存泄漏挺难的，但只要发挥我们测试人员的主观能动性，总是找到一些“旁门左道”的测试手段。

　　最后，我个人认为，从时间成本和各种风险考虑，要避免内存泄漏的问题，还是要回到前期的预防，即编程过程的规则检查和单元测试阶段主动的检测。

　　一家之言，欢迎讨论。