测试某业数据门户进行功能测试时查看了一下任务管理器，发现IE进程竟然达到了423，145K，怀疑发生了内存泄漏，因此打算直接用IE的插件 js memory leaks dector来检测一下，但是进行了一些可能引起内存泄漏的操作后，检测结果一直都很正常，并没有发现关于内存泄漏的地方，开发人员只好自己判断哪些 IFRAM没有被销毁来优化系统，降低内存的使用。
下午的时候，查看以前的测试文档，发现用SIEVE来测试此类系统的IE内存泄漏时，通常在报表刷新的过程中，通常是会发生内存泄漏的，因此，用SIEVE测试了一下，果然，登录后，内存泄漏显示位58，在报表每次刷新的时候，内存泄漏显示+1，在切换报表的时候，内存泄漏在原基础上又增加了7，然后再退出的时候，内存泄漏由原来的77一下增加到了1200多。通过此工具记录下的发生内存泄漏的ID 和TAG名称，可查找出发生内存泄漏的代码。
关于内存泄漏，通俗简单的解释就是已经不再被使用应该被释放的资源没有被释放，从而程序占用的内存一直增多，IE浏览器发生的内存泄漏，引起IE内存泄漏的主要情况为js对象实例跟dom对象的相互引用、“内部函数引用(Closures)”以及 DOM插入顺序泄漏，其中最常见的就是js对象实例跟 dom对象的相互引用，对基于对象的JScript，一个通常用法是通过封装JScript对象来扩充DOM对象，在构建的过程中，通常在涉及DOM对象时，建立一个对DOM对象的引用，DOM对象也建立一个指向JS对象实例的引用，这就形成了一个循环，虽然不管js调用dom还是从dom反向找到实例都非常方便，但如果在对象销毁或document unload的时候不去解除他们之间的引用，就会引起内存泄漏。JS的GC可以识别循环，当对dom节点和事件处理函数的引用消失，会自动回收，但是IE 自己的内存管理器并不识别循环，因此占用的内存没有被回收，就会发生内存泄漏。例如：当页面进行刷新时，由于前页面占用的内存一直没有释放，导致内存不断升高。
Java leak memorys detector通过在访问每个URL结束时给出测试解果，如果没有发生内存泄漏，那么URL显示为绿色，如果发生了内存泄漏，显示为红色，可以记录下发生内存泄漏的详细信息，左侧部分显示发生内存泄漏的代码位置为粗体字，在中间的两格中显示详细信息与CALL STACK，右侧显示完整的代码。
SIEVE通过在地址栏输入要访问的系统地址来进行操作测试，中间直接显示要访问的系统界面，下栏显示COM和DOM的使用情况，右侧显示实时数据：内存使用情况，内存泄漏等，如果发生内存泄漏可以通过右侧数据看出，然后点击show leaks的按钮可以看到发生内存泄漏的详细信息如ID等，不过不是所有发生内存泄漏的都会被记录下所有的详细信息，只有很少一部分ID被记录下来，还可通过界面上的自动刷新按钮对系统进行刷新，代替了手工刷新。但是此工具使用起来占用内存很大，进行操作比较多后会无响应，有些操作还会引起工具自动关闭，在复制出内存泄漏信息时只能选择全部的详细信息，不能滤掉一些没有必要的信息和空信息，造成使用不是很方便。
总之，IE内存泄漏的查找不仅需要有一定的经验，还需要有一定的耐心！