Web 2.0 瀏覽器端可靠性測試 第 1 部分: 帶你走進 Web 2.0 瀏覽器端可靠性測試

瀏覽器端可靠性測試的概念和背景

背景

Web 2.0 是一個體現當代網絡技術發展趨勢的流行概念。它使得基於 Web 的信息交互和用戶間協作性更加靈活和豐富。很多的社交網站、博客、wiki，都是 Web 2.0 技術的典型應用。

我們知道，Web 2.0 最突出的特色就是豐富的客戶端技術；而客戶端技術中，最基本也最重要的技術就是 JavaScript。通過大量的 JavaScript 腳本，我們可以創建動態的頁面展示，活潑的界面效果，以及與服務器之間進行數據交互等。

然而，我們往往忽略了一個重要問題，就是大量使用這些 JavaScript 腳本可能對瀏覽器端帶來的種種問題。在很多 Web 應用的使用過程中，我們會發現頁面響應越來越慢，瀏覽器進程佔用的內存不斷增多（圖 1），甚至瀏覽器會異常關閉（圖 2）。諸如此類問題，都會導致極差的用戶體驗。現在我們逐漸認識到了這一問題，並且提出了瀏覽器端可靠性測試的概念，來保證我們的 Web 應用擁有更高的可靠性和穩定性。

圖 1. 用 Windows Perfmon 監控的 IE 進程內存消耗情況
 

圖 2 . IE 異常關閉
 

概念

瀏覽器端可靠性測試，就是以瀏覽器爲測試平臺，通過模擬用戶在真實場景下的頁面操作（點擊、拖拽），來發現 Web 應用中潛在可靠性問題的測試。測試目的是確保 Web 應用在瀏覽器上能達到令人滿意的用戶體驗和可靠性。

回頁首

瀏覽器端可靠性測試的特點

通常，瀏覽器端可靠性測試具有以下幾個特點：

1. 單用戶，單瀏覽器進程

   與服務器端可靠性測試不同，瀏覽器端的可靠性測試，是模擬一個用戶在一個客戶端（瀏覽器）中的操作。

2. 最大限度模擬客戶端的操作行爲

   測試中應用的場景應最大限度的模擬最終用戶的操作行爲，比如點擊、拖拽、複製、粘貼等等，並按功能點的重要程度和用戶操作的頻率來設計測試場景和測試用例，以便使測試結果更接近真實結果。

3. 瀏覽器相關

   不同的瀏覽器會有不同的測試結果；現在用戶使用的瀏覽器衆多。爲了確保用戶在不同瀏覽器 ( 包括操作系統 ) 下都能達到高可靠性，我們需要儘可能地在產品所支持的瀏覽器和操作系統下進行測試。目前市場上的瀏覽器種類繁多，這無疑對我們的測試是一個挑戰。

4. 有助於發現客戶端的設計缺陷

   通過瀏覽器端可靠性測試，可以發現因爲客戶端設計缺陷或考慮不周而導致的問題，比如大量複雜的 JavaScript 代碼可能導致用戶響應時間過長。

回頁首

瀏覽器端可靠性測試的流程

我們將瀏覽器端可靠性測試的測試流程分爲：測試場景設計、腳本開發、環境準備、測試執行（包括壓力測試和長時間測試）、發現問題、分析問題及報告缺陷、編寫測試報告幾個部分。

測試的流程圖

圖 3. 瀏覽器端可靠性測試的流程圖
 

瀏覽器端與服務器端可靠性測試的比較

表 1. 瀏覽器端可靠性測試和服務器端可靠性測試的比較

	瀏覽器端測試	服務器端測試
用戶數	單用戶	多用戶
測試對象	瀏覽器端的問題，主要是 JavaScript 代碼，主要發現 memory leak （內存泄漏）和響應時間問題， 與瀏覽器關係密切	測試 Server 端代碼，例如 Java, C/C++ 等，與瀏覽器無關
使用工具	RFT（Rational Functional Tester）,Selenium 等	RPT（Rational Performance Tester）, LoadRunner 等
測試經驗	極少測試經驗，Web 2.0 以來新興測試領域	已有成熟的測試經驗
測試特點	衡量單客戶端用戶真實操作體驗	衡量服務器端對來自多客戶端的承載能力通過模擬用戶的操作行爲

測試流程說明

1. 測試場景設計

   瀏覽器端的可靠性測試中，需要設計兩種類型的測試場景：壓力測試和長時間測試。壓力測試一般針對關鍵功能點和用戶操作頻率較高的操作。長時間測試則是對整個產品進行的可靠性把關。

2. 測試腳本開發

   瀏覽器端的可靠性測試主要是通過執行自動化腳本完成的。所以，開發健壯的腳本來模擬瀏覽器端的 GUI 操作，會使我們的測試事半功倍。從整個測試過程來看，自動化測試可以節約我們大量的時間和精力。

   值得說明的是，我們在編寫腳本的同時，需要注意幾個方面的問題。首先，我們要考慮測試腳本對不同瀏覽器的兼容問題。儘可能通過一些公共屬性查找頁面元素，以使腳本能夠順利地跨瀏覽器執行。其次，利用日誌來分析潛在的可靠性問題。我們通常將對頁面的操作信息（也可能包括瀏覽器的內存佔用等信息）打印在日誌文件中，便於分析。

3. 測試環境準備

   準備測試環境是測試執行前最關鍵的一步。我們一般會制定一份檢查列表，通過勾對每個檢查項目來確保測試環境的正確。下面我們列出一些針對瀏覽器端測試，需要考慮的環境因素：

   • 操作系統
   1. 1. 操作系統版本及補丁要在測試前指定好，並嚴格按照要求進行安裝。因爲某些微小的差別可能會導致不同的測試結果。
      2. 關閉操作系統自動更新的設置，關閉桌面屏保，禁止自動關閉顯示器、硬盤。以上這些都是爲了避免測試腳本在運行過程中意外中止。
   • 瀏覽器
   1. 1. 瀏覽器版本要正確，特別注意瀏覽器的小版本號
      2. 關閉自動更新瀏覽器的選項，同時禁止自動更新瀏覽器插件
      3. 關閉一切不使用的、或可能對可靠性產生影響的瀏覽器插件。禁用插件的目的是杜絕插件本身對測試結果的干擾，比如插件本身可能帶來的導致瀏覽器內存泄露等問題。
   • 監測工具

     配置監測工具，指定需要收集的數據，並在監測工具中配置相應的計數器，比如內存佔用、CPU 等信息。對瀏覽器端可靠性測試而言，我們主要收集瀏覽器進程的相關信息。

   • 測試數據

     根據測試場景，準備必要的測試數據。用於測試的數據通常要求具有代表性。一方面是爲了能夠通過數據覆蓋到更多的功能點，另一方面也可以最大限度地模擬用戶的真實使用狀況。

   • 服務器端

     有時，服務器端的相關配置也會對瀏覽器端的測試產生影響。比如測試一個基於 WebSphere Application Server 的應用。當我們需要進行一個持續 3 小時的測試的時候，我們就需要對 WAS 上的 LTPA timeout 進行必要的修改，使它大於 3 小時。否則，當測試腳本執行到 2 小時（默認值）的時候，頁面會自動 logout 退出，導致腳本無法繼續執行。

4. 執行測試

   執行測試的步驟如下圖所示。主要是通過運行自動化腳本來模擬用戶操作頁面，同時使用監測工具監測瀏覽器進程的過程。

   
   
   圖 4. 執行測試的步驟
    
   
   
5. 發現問題

   我們常常在測試還未結束的時候就能發現問題。通過監測工具實時地監測瀏覽器進程，很多問題在測試過程中就已經表現出來了。

   下面就是一個典型的例子：

   
   
   圖 5. 通過檢測工具發現內存泄露
    
   
   

   從圖中可以看到，在測試持續了 21 分鐘的時候，從系統監測工具中，已經清晰地看到一個內存增長趨勢圖。圖中的內存佔用由開始的 100 多兆，迅速漲到近 800M。這說明此段測試中所執行的頁面操作，導致了嚴重的瀏覽器端內存泄露。

6. 分析問題及報告缺陷

   我們發現問題以後，一般要先做必要的分析。然後將分析結果分享給開發人員，幫助他們快速的定位和解決問題。

   在報告缺陷的時候，我們通常要提供下面的信息給開發人員：

   1. 1. 能夠重現問題的步驟
      2. 測試環境：操作系統的版本、瀏覽器的版本
      3. 是否是瀏覽相關的問題，比如是否只有在 Internet Explorer 上纔會出現的問題，而在其他瀏覽器是沒有問題的
      4. 給出測試數據。比如計算出每次操作導致的內存泄漏。如果在多個瀏覽器上都存在內存泄漏，要在不同的瀏覽器上進行測試，並將內存泄漏的數據進行比較。
      5. 其他一些必要的信息和分析結果。比如用其他工具分析的數據，或是代碼走查發現的問題等等。
7. 編寫測試報告

   測試報告可以通過通用的模板生成的。測試報告裏要求記錄所有關於測試的信息。包括測試環境、測試場景、測試數據、測試步驟、測試結果、趨勢圖、測試分析、日誌文件等等。

   測試報告不僅記錄了整個測試的過程，留下文檔，也對我們對分析產品問題提供了大量的歷史數據和經驗，更有助於技術交流和分享。

   測試報告模板樣例：

   
   
   

   標題
   壓力測試 - 驗證產品頁面切換時瀏覽器端的可靠性 
   
   測試結果
   通過 / 未通過 
   
   概要
   描述測試的任務、目的，記錄測試人員和測試日期。
   
   測試環境
   包括服務器端和客戶端的測試環境、軟件和工具等的配置信息。
   
   測試步驟
   包括測試前的準備工作以及測試的執行步驟。 
   
   用戶定義
   定義測試時長、操作時間間隔、監測取值間隔、測試數據準備等信息。
   
   測試場景
   描述測試用例和操作步驟 
   
   資源佔用
   內存使用表
   記錄內存使用的最大、最小、平均值等信息。
   
   趨勢圖
   由監測工具展示的內存使用趨勢圖 
   
   測試結果分析
   根據上述測試數據分析問題所在。需要描述分析的方法和依據。
   
   日誌文件
   提供監測工具和測試軟件在測試執行過程中收集的測試數據。
   
   缺陷報告和分析
   是否有缺陷報告及分析產生的原因。

   
   
   

回頁首

測試的方法和工具

測試方法

按照測試工具分

按照測試工具來分，測試方法分成手工測試和自動化測試兩種。前面我們提到了自動化測試，然而在實際測試中，我們通常會採用手工測試與自動化測試相結合的方法。

1. 手工測試

   手工測試是指測試人員通過手工操作頁面，同時使用監測工具來監測瀏覽器進程的各計數器數值的變化。在手工測試中，我們經常可以發現一些明顯的可靠性問題，比如嚴重的內存泄漏。由於手工測試比較簡單，不需要準備測試腳本，所以，對關鍵功能點的壓力測試，我們通常先進行手工測試，在沒有發現明顯問題的時候再開始自動化測試。

   那麼怎樣通過手工測試來發現問題呢？

   我們在對頁面進行操作的同時，使用監測工具來監測瀏覽器進程內存的變化。記錄每次頁面操作（點擊或拖動）的開始和結束時刻的內存佔用，重複多次，就可以得到一組數據，從而看出內存的變化趨勢。需要注意的是，對於一個頁面操作，我們通常會不計算第一次操作引起的內存增長，因爲通常在第一次操作的時候，腳本創建一些對象，從而會導致內存的增長，這種增長屬於正常現象，並不是我們常說的內存泄漏。

2. 自動化測試

   通過自動化測試，我們可以發現更多的問題。比如，一些細微的內存泄漏，只有在經過腳本重複幾十次上百次的操作後，積累到一定的程度，纔可以被發現。另外，一些響應時間等指標，也是需要操作一定的時間和數量之後才能被發現的。我們也經常能通過自動化測試發現一些更嚴重的可靠性問題，比如瀏覽器進程的意外終止。

按照測試場景和時間分

按照測試場景和時間來分，測試方法分爲壓力測試和長時間測試。

1. 壓力測試

   對於一些關鍵功能點，我們需要將它們分離出來，進行單獨的壓力測試。壓力測試通常是對某個相對獨立的功能點進行重複的頁面操作，並觀察其對瀏覽器進程的影響。這樣做的目的是爲了確保那些基本的、關鍵的、以及使用頻率較高的功能點能夠得到充足的測試，從而確保達到最高的可靠性。這樣做的好處也很明顯，當測試過程發現問題的時候，比較容易進行調試和分析，因爲被測功能單一併且相對獨立，我們很容易知道是什麼樣的操作引起的問題。而且，由於功能點的分離，使每一個壓力測試都比較短小，一般在 1 到 3 個小時就可以發現問題。

2. 長時間測試

   在所有的壓力測試都完成並且確保沒有嚴重的可靠性問題之後，我們就會進行長時間測試。我們在測試中要覆蓋幾乎所有已經通過壓力測試的功能點。長時間測試一般都會持續較長的時間（比如 24 小時或是更久），所以都是通過自動化工具完成的。測試腳本執行的同時，使用監測工具監測和記錄瀏覽器進程各計數器的變化。根據日誌文件和內存增長趨勢圖來進行分析。

測試工具

對瀏覽器端進行可靠性測試，我們主要需要兩種測試工具。一種是用來模擬頁面操作的 GUI 自動化測試工具，一種是用來監測瀏覽器進程的監測工具。另外，對於測試後的分析工作，我們也需要相應的分析工具。

GUI 自動化測試工具

GUI 自動化測試工具有很多種，我們常用的工具主要是 Rational Functional Tester。

進程監測工具

對於 Windows 操作系統來說，我們通常使用兩種工具來進行進程監測：

1. Task Manager，這個工具通常在手工測試中被使用，來監測瀏覽器進程的內存和 CPU 佔用。
2. System Monitor，我們在自動化測試中使用它，通過加入指定的計數器來監測瀏覽器進程 的內存和 CPU 使用等信息，並保留日誌在硬盤上。也可以通過這個工具直接展示各個 計數器的趨勢圖。

對於使用 Linux 或其他的操作系統的用戶，也可以找到相應的工具對瀏覽器進行監測。

分析工具

有了以上工具，我們就可以執行我們的測試，並且發現一些瀏覽器端的可靠性缺陷。一旦發現了問題，我們需要使用工具來做必要的分析。

介紹幾款常用的分析工具：

1. Firebug：是 Mozilla Firefox 瀏覽器的開源擴展，提供了很多功能，可以監視、編輯和調試任何 Web 站點的級聯樣式表（CSS）、HTML、文檔對象模型（DOM）和 JavaScript。Firebug 包括一個 JavaScript 控制檯、一個日誌記錄 API 以及一種有用的網絡監視器。藉助 Firebug，可以很輕鬆地調試和優化 Web 和 Ajax 應用程序。

2. sIEve：是一個專門針對 Internet Explorer 瀏覽器的內存泄露監測工具，是一款開源軟件。它可以幫助我們列出當前頁面內所有 DOM 節點的基本信息，以及頁面內所有 DOM 節點的高級信息，可以查找出頁面中的孤立節點，查找出頁面中的循環引用等等。

3.JavaScript memory leak detector：是 IE 瀏覽器的插件，由微軟的內部員工開發，功能看起來比 sIEve 要強大。 它可以報告可疑的內存泄露，包括泄露的 DOM 對象，引起泄漏的引用代碼和代碼出處。但是這個工具只是對於簡單的 JavaScript 代碼比較好用，對於一些複雜的代碼，如使用了 dojo 工具包的 JavaScript 代碼，即使發生了內存泄露，也很難定位到引起泄漏的代碼，所以很難派上用場。

回頁首

測試過程中的常見問題

在不同瀏覽器下進行測試

大多數 web 應用，都會支持一些主流的瀏覽器，比如 IE，Firefox, Safari 等等。對 web 應用所支持的瀏覽器，原則上都要進行瀏覽器端的可靠性測試。

以下幾個方面需要我們在測試中特別注意：

1. 瀏覽器設置對測試的影響

   瀏覽器的設置對測試結果有着重要的影響。比如我們是否需要在測試前清除 cache，是否需要清除私有數據，瀏覽器打開鏈接是使用標籤頁還是新窗口，瀏覽器最小化的時候是否需要釋放內存，等等，都根據我們的測試要求進行指定。

2. 腳本對測試的影響

   同一份腳本在不同的瀏覽器下運行多少會遇到些問題，需要做相應的修改。健壯的能跨瀏覽器運行的測試腳本是我們的目標。通過一些技巧，可以使測試腳本兼顧到不同的瀏覽器。比如：查找對象進可能使用一些穩定的屬性和值，如 id。對瀏覽器相關的問題用分支語句進行分別處理，如不同瀏覽器彈出的證書認證窗口等。

3. 監測和分析工具

   在不同的操作系統上進行測試的時候，我們可以選擇不同的監測工具，在對瀏覽器進程進行分析時，工具也隨着瀏覽器和操作系統的不同而有所選擇。

瀏覽器端內存泄漏

內存泄漏是瀏覽器的可靠性測試中最常見的問題，也是我們測試的重點。根據以往的測試經驗，大多數的內存泄漏問題出現在 IE 瀏覽器上。IE 上內存泄漏的主要原因是由於 IE 瀏覽器的本地對象和 JavaScript 對象使用的垃圾回收機制不同的引起的（IE 本地對象使用 Reference Counting 垃圾回收機制，而 JavaScript 對象則使用的 Mark-and-Sweep 垃圾回收機制，兩種對象之間的循環引用就會導致垃圾回收機制失效。我們後面會有文章專門來講如何發現和分析瀏覽器端的內存泄漏問題。）

爲了便於發現內存泄漏，我們通常會在測試腳本中輸出詳細的日誌信息來記錄每一個頁面操作，同時使用監測工具監測瀏覽器進程的內存使用狀況。通過兩組日誌信息的對比和分析，我們可以很清晰地看出內存的增長趨勢，也就可以輕鬆地找出是哪種操作導致的內存泄漏。

使用工具來分析內存泄漏問題也是測試過程中的一個重要環節。一般常用的工具有 sIEve，js Memory leak detector，Firebug 等等。

瀏覽器 Crash

通常，長時間的頁面操作會導致瀏覽器的內存增加，響應變慢，但是不會造成瀏覽器 crash。但是，偶爾也會發生瀏覽器 crash 的情況。比如，嚴重的內存泄漏導致瀏覽器內存使用迅速增長，瀏覽器進程長時間沒有響應，造成瀏覽器進程異常終止。某些特定的操作也可能導致瀏覽器 crash，這多半是由於產品自身的原因引起的。

自動化測試與手工測試結果不同

當自動化測試與手工測試得到的結果不一致的時候，我們通常考慮下面幾個因素的影響。首先，要排除因爲操作步驟上的細微差別而導致不同結果的可能。比如，測試腳本中使用鍵盤操作，而手工測試卻使用的拖拽操作等等。然後，要檢查測試腳本中是否加入了一些驗證點來驗證頁面的操作。通常情況下，在驗證點中，會有一些額外的頁面動作，比如移動鼠標，點擊等，這些操作也許會帶來一定程度的內存消耗。最後，我們還要考慮到，自動化測試工具本身也可能會導致內存泄漏，比如在使用 Rational Functional Tester 的時候，要通過正確使用 unregister() 或 unregisterAll() 方法來釋放對象所佔用的內存，否則就可能導致瀏覽器進程分配的內存不能及時釋放，不僅使得自動化測試與手工測試的結果產生差異，同時也降低了軟件的可靠性。

服務器端異常

我們在一個長時間的測試過程中有可能遇到服務器端的異常，最終導致測試終止。所以，在測試前一定要反覆檢查服務器端的配置是否正確，比如，LTPA timeout 的時間是否過短，使得測試到一定的時間就退出登錄，等等。另外，在發現問題後要認真查看服務器端的日誌文件，根據日誌中的信息分析是導致出錯的原因，以確認是否是產品的缺陷，並做必要的分析。

回頁首

測試技巧和注意事項

1. 測試場景設計

   設計測試場景前一定要了解用戶的使用習慣和實際場景，並以此爲參照。對於壓力測試來說，要進可能多地覆蓋關鍵的功能點。而對於長時間測試來說，則要注意不同的操作順序可能會導致不同的測試結果。

2. 在功能測試通過之後再開始瀏覽器端的可靠性測試

   這是瀏覽器端可靠性測試進入的標準。如果產品的基本功能還存在很多功能問題的時候，可靠性測試是無法開始的。我們通常在某一功能點相對穩定之後就開始對這一功能點的壓力測試。

3. 測試客戶端使用虛擬機

   因爲我們需要對不同的瀏覽器（操作系統）進行測試，所以，我們需要準備不同的測試客戶端。爲了節約時間和硬件，我們也可以使用虛擬機來作爲我們的測試客戶端。這些客戶端都似乎相對簡單的輕量級的測試環境，主要差別就在操作系統和瀏覽器上。

4. 自由測試的補充

   作爲補充，我們會在設計的測試場景之外做一些自由測試。比如我們會去測試一些比較複雜的和用戶不常使用的功能點，也可能會測試純鍵盤的操作給瀏覽器進程帶來的影響。

5. 瀏覽器端可靠性測試面臨的挑戰

   瀏覽器端可靠性測試是一個新的測試領域，它的發展還需要更多的人來參與。目前，我們在測試中面臨一些挑戰。比如：

   • 瀏覽器的種類繁多，而且不同瀏覽器之間無論在配置上，顯示上，還是對腳本的處理上都有所差異。
   • 對於相同的瀏覽器而言，瀏覽器版本的不斷更新，也促使我們在測試中做相應的應對。
   • 目前針對瀏覽器端內存泄露進行分析的工具還很有限。
   • 測試工具需要進一步滿足測試的需要，以方便分析內存增長與操作的關係，並且獲取操作的響應時間。
   • 測試中瀏覽器的環境與真實客戶環境的差異。比如網絡，瀏覽器插件等因素。

回頁首

結束語

通過這篇文章的介紹，您對瀏覽器端可靠性測試已經有了一些初步的認識，也對測試流程、測試方法以及常用工具有了一定的瞭解。

我們將在瀏覽器端可靠性測試系列文章的第 2 部分中爲您介紹瀏覽器端可靠性測試中如何發現和分析瀏覽器的內存泄漏問題。

參考資料

學習

• Firebug：Firefox 瀏覽器的開源擴展，可以監視、編輯和調試任何 Web 站點的級聯樣式表（CSS）、HTML、文檔對象模型（DOM）和 JavaScript，可以很輕鬆地調試和優化 Web 和 Ajax 應用程序。 
  
  
• sIEve：專門針對 Internet Explorer 瀏覽器的內存泄露監測工具，可以幫助我們列出當前頁面內所有 DOM 節點的基本信息，以及頁面內所有 DOM 節點的高級信息，可以查找出頁面中的孤立節點，查找出頁面中的循環引用等等。 
  
  
• JavaScript memory leak detector：IE 瀏覽器的插件，由微軟的內部員工開發，可以報告可疑的內存泄露，包括泄露的 DOM 對象，引起泄漏的引用代碼和代碼出處。 
  
  
• IBM Rational Functional Tester：IBM Rational Functional Tester 面向測試人員的自動化測試技術參考資源。 
  
  
• developerWorks Web development 專區：通過專門關於 Web 技術的文章和教程，擴展您在網站開發方面的技能。
  
  
• developerWorks Ajax 資源中心：這是有關 Ajax 編程模型信息的一站式中心，包括很多文檔、教程、論壇、blog、wiki 和新聞。任何 Ajax 的新信息都能在這裏找到。
  
  
• developerWorks Web 2.0 資源中心，這是有關 Web 2.0 相關信息的一站式中心，包括大量 Web 2.0 技術文章、教程、下載和相關技術資源。您還可以通過 Web 2.0 新手入門欄目，迅速瞭解 Web 2.0 的相關概念。
  
  
• 查看 HTML5 專題，瞭解更多和 HTML5 相關的知識和動向。
  
  

討論

• 加入 developerWorks 中文社區。查看開發人員推動的博客、論壇、組和維基，並與其他 developerWorks 用戶交流。
  
  

作者簡介

胡晶晶，目前工作於 IBM Mashup Center 系統測試部門，主要從事 Lotus Mashups 的系統測試。

張曉輝，目前工作於 IBM Mashup Center 系統測試部門，主要從事 Lotus Mashups 的瀏覽器端可靠性測試。

歐勝高，資深軟件工程師，目前是 IBM CDL Lotus 系統測試部門技術負責人。