軟體測試中IE記憶體流失測試執行個體

測試某業資料門戶進行功能測試時查看了一下工作管理員，發現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記憶體流失的尋找不僅需要有一定的經驗，還需要有一定的耐心，當然，有一個使用起來有效方便的工具當然更好，現在，對於IE記憶體流失測試我也是剛剛起步，還有很多需要學習的地方，謹以此次測試過程與大家分享，共同進步！