背景

Web 2.0 是一個體現當代網路技術發展趨勢的流行概念。它使得基於 Web 的資訊互動和使用者間協作性更加靈活和豐富。很多的社交網站、部落格、wiki，都是 Web 2.0 技術的典型應用。

我們知道，Web 2.0 最突出的特色就是豐富的客戶端技術；而客戶端技術中，最基本也最重要的技術就是 JavaScript。通過大量的 JavaScript 指令碼，我們可以建立動態的頁面展示，活潑的介面效果，以及與伺服器之間進行資料互動等。

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

概念

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

回頁首

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

1. 單使用者，單瀏覽器程序

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

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

   測試中應用的場景應最大限度的模擬終端使用者的操作行為，比如點選、拖拽、複製、貼上等等，並按功能點的重要程度和使用者操作的頻率來設計測試場景和測試用例，以便使測試結果更接近真實結果。
3. 瀏覽器相關

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

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

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

回頁首

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

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，這多半是由於產品自身的原因引起的。

當自動化測試與手工測試得到的結果不一致的時候，我們通常考慮下面幾個因素的影響。首先，要排除因為操作步驟上的細微差別而導致不同結果的可能。比如，測試指令碼中使用鍵盤操作，而手工測試卻使用的拖拽操作等等。然後，要檢查測試指令碼中是否加入了一些驗證點來驗證頁面的操作。通常情況下，在驗證點中，會有一些額外的頁面動作，比如移動滑鼠，點選等，這些操作也許會帶來一定程度的記憶體消耗。最後，我們還要考慮到，自動化測試工具本身也可能會導致記憶體洩漏，比如在使用 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 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 系統測試部門技術負責人。