文章出處：CSDN 作者：Hung Nguyen 翻譯：Kiki 發佈時間：2006-04-26
測試web應用程序和測試桌面系統用很多共同點：例如你需要和執行所有標準測試類型一樣測試常見的功能點，配置及兼容性。但是由於與應用程序交互的所有分佈式系統組件的複雜性成倍的增加的原因，導致web應用程序測試更加的困難。當我們在web環境中看到一個錯誤時，通常很難指出錯誤發生的地方，並且由於我們看到的行爲或我們接受到的錯誤信息可能是發生在Web系統中不同部分的錯誤的結果。錯誤可能是很難重現的。那麼我們如何在web系統中分析錯誤呢，並且爲了重現那些錯誤又應該做哪些考慮呢？
當我們對潛在的技術有一個瞭解時，我們可以更好的最大化測試效率－編寫更多可重現的bug報告並且在較少的時間裏發現更多的錯誤。說比做更加容易－特別是在web環境裏。Web環境在錯誤傾向技術變量是密度高的。以下是測試Web應用程序的需要考慮的5個基本事項：
1． 當我們在客戶端看到一個錯誤時，我們所看到的是錯誤的症狀，而不是錯誤本身。
2． 錯誤可能是與環境相關的，並且可能不出現在不同的環境裏
3． 錯誤可能是存在代碼或是配置中的
4． 錯誤可能駐留在幾個層中的任一個層中
5． 檢查操作系統中的兩個類別－靜態vs動態－需要不同的方法。
現在讓我們來詳細的看看這5個需要考慮的事項。
1. 什麼是我們真正看到的東西？是一個錯誤還是一個症狀？
如果不診斷環境，我們不能夠確定是什麼導致了一個症狀出現。如果客戶端和服務器端的一個環境特定的變量被移除或被改變的話，我們或許將不能夠重現問題。
例如，我正在測試一個Web的缺陷跟蹤應用程序，並且遍歷創建一個bug報告的流程。當我選擇“新建”按鈕時，我接收到一個錯誤信息：Microsoft OLE DB Provider for ODBC Drivers error '80040e14'。在花了一些時間調查我的瀏覽器環境後，我發現JavaScript在瀏覽器的參數設置對話框中被禁止了。啓用JavaScript就消除了這個錯誤。（這個問題是否是個bug不在我們今天討論的範圍裏）這裏是要說如果我在bug報告中增加關於JavaScript的信息，我可以節約我們團隊花費在分析這個問題的時間。此外，“禁用JavaScript”從此應該要添加到我的測試包中；它將被應用到應用程序的各個地方，以使所有潛在的相關問題不會出現。
2. 這個錯誤是環境依賴的嗎？
爲了重現一個環境相關的錯誤，我們不得不完全地複製活動的準確順序和應用程序操作所在環境的條件（操作系統，瀏覽器版本，插件的組件，數據庫服務器，web服務器，第三方組件，服務器/客戶端資源，網絡帶寬和通信量等等）。例如，當你試圖使用一個28.8 kbps的撥號連接登錄到你的Web應用程序中，你會碰到一個由於在認證過程中因超時而導致的登錄失敗－但是同樣的登錄步驟如果你用一個1.54 mbps 的T－1連接將會成功的通過認證。在這個案例中，你有一個環境依賴的錯誤，這個依賴條件是在帶寬中。
環境無依賴的錯誤，用另一種話說，相對來說是容易重現的－它沒有必要複製操作環境。環境無關的錯誤，需要複製所有都能夠揭示錯誤的步驟。例如，如果公司的名稱在所有產品在線頁面上錯誤地拼寫爲WebTessting.Con, 你就總能看到這個錯誤－它是和硬件，軟件和你操作環境中資源變量無關的。更爲常見的是，我們將環境無關的錯誤稱爲功能特定的錯誤。
3. 是一個代碼錯誤或是一個配置問題
錯誤（或是假定錯誤的症狀）可能會在代碼修復中或系統重新配置（客戶，服務器或網絡）解決（假設錯誤是真實的）。不要太快的下結果它是一個bug。
Microsoft OLE DB Provider for ODBC Drivers error '80004005' 對比真正的軟件錯誤，這是一個說明識別可能的配置問題挑戰。它顯示了由於Web應用程序“登錄失敗”而引起的一個錯誤信息。只是簡單的查看這個錯誤信息，是不可能判斷這個錯誤是由於軟件bug引起的還是服務器端配置問題，或是兼容性問題，瀏覽器配置問題或以上所有的。
在進一步分析這個失敗以後，我發現幾個可能的產生這個錯誤信息的條件:
IIS (Web server) virtual directory has not been set up properly當虛擬目錄沒有被正確的配置時，將找不到請求的文件，腳本或數據。這是一個典型的服務器配置的問題。然而，如果安裝程序未能根據說明書一樣配置web服務器，那麼這是一個軟件的錯誤。如果一個系統管理員未能根據說明書正確地配置web服務器，這個就變成了用戶錯誤。
Application directory has not been configured properly to execute scripts一個典型的應用服務器目錄包含了需要執行的腳本，它們會被代表客戶端的Web服務器調用。爲了安全的原因，一個Web服務器可以被配置以允許或不允許腳本在一些目錄裏執行。如果你的應用服務器目錄被設計來包含將要被執行的腳本－但是Web服務器被配置爲在那個目錄裏禁用腳本執行－應用程序將不能工作。這是軟件錯誤還是一個配置問題呢？
Default Web page has not been set up properly這個問題和上面的問題相似
SQL Server is not running爲了執行查詢，存儲過程和訪問數據，應用服務器需要連接後臺在SQL服務器上的數據庫。如果SQL服務器進程沒有運行，顯然應用程序將不能工作。
DLL/COM objects are missing or were unsuccessfully registered可能安裝程序在安裝過程中未能複製應用服務器要使用的所有DLL。如果遺漏了其中一個應用程序所需的DLL，應用程序將不可以工作。
也可能安裝程序正確的複製了所有需要的模塊，但是失敗的註冊一個或多個DLL。例如OLE－Based的對象，例如COM或DCOM，它們的class ID(CLSID) 在它們可以被使用之前必須註冊到註冊表庫中。如果一個應用程序試圖訪問一個沒有被成功註冊的COM對象，應用程序將不能工作。
這個問題通常由安裝過程中的錯誤引起來。另一方面，如果組件必須被手工註冊地話，就變成一個配置問題。
Browser-side JavaScript setting has been disabled這是一個瀏覽器端的配置問題，由於應用程序要求瀏覽器啓用JavaScript。這是一個軟件錯誤，配置問題或是一個技術支持的問題呢？
4．哪個層真正的引起了那個問題？
在Web系統中的錯誤通常是很難一直重現因爲許多由C/S架構的分佈式特性而引入的許多變量。（例如，服務器，客戶端和網絡組件）。在一個web環境中至少由3個常見的懷疑部分：客戶端，服務器和網絡。客戶端和服務器都會攜帶誒之和兼容性問題，那些和PC環境相似，所有的組件都在一個盒子裏。在C/S系統裏，問題成倍的增長，然而，由於可能有很多的客戶端和服務器鏈接在一個網絡中。典型的C/S配置和兼容性問題涉及到硬件和操作系統的混合（例如，基於UNIX的vs基於windows的盒子）以及在服務器端的軟件組合（Web服務器包，數據庫服務器包，防火牆，COM對象，CORBA對象等等）。問題也可能涉及客戶端的軟件組合（TCP/IP堆棧，撥號軟件，幫助組件，瀏覽器帶寬和瀏覽器版本）。另外，瀏覽器設置，例如一些常見的設置，連接設置，安全設置（包括ActiveX空間，插件，Java，腳本，下載，用戶認證等等），內容設置，程序設置，和其他高級設置（包括瀏覽器選項，多媒體選項，JVM選項，打印選項和HTTP選項）引入很多可以被測試並分析的變量。
網絡提供了另一套變量。網絡用幾個方式影響着Web應用程序，包括由於帶寬和響應時間引起的分時相關的問題（競態條件，性能，超時等等），由於硬件設備例如網關和路由器導致的潛在的配置和兼容性問題，以及和安全實現相關的端問題。
5．靜態和動態操作環境是不同的
一般來說，有兩類操作環境－每個都有自己獨一無二的測試牽連：
靜態環境（例如配置和兼容性錯誤）不兼容性問題可能存在其中，不管可變的條件，例如處理速度和可用的內存
動態環境（例如資源及時間相關的錯誤）其他方面可兼容的組件可能出現錯誤在其中，由於內存相關的錯誤和反應時間條件（我們將在這一節中更詳盡的探討動態環境）
靜態操作環境：配置和兼容性變量
配置和兼容性問題可能會出現在web系統中的任何一個點上：客戶端，服務器端，或網絡中。配置問題包括不同的服務器軟件和硬件設置，瀏覽器設置，網絡連接，和TCP/IP堆棧設置。瀏覽器設置/ 前面提到的JavaScript例子說明了配置問題的一種類型。圖1和圖2展示的是另一個配置問題的類型，兩種可能的物理服務器配置：one-box 和two-box配置。
我們用來示範的所測試應用程序有一些製圖的功能，可以讓用戶生成度量報告，例如條形圖和直線圖。當用戶請求一個度量報告時，應用程序服務器執行的僞碼如下：
1．連接服務器並運行查詢，
2．編寫查詢結果到一個名爲c:/temp/chart.val的文件中，
3．執行Chart的JavaApplet。從c:/temp/chart.val文件中讀取數據以生成一個圖表
4．發送JavaApplet到瀏覽器
在測試這個應用程序過程中，我發現圖表功能可以在以上的配置上運行，但是卻不能在其他配置上工作。在我更進一步的研究之後，我認識到問題可能出現在two-box配置中。在檢查代碼之後，我認識到問題在步驟2和3中。在步驟2中，查詢結果被寫到數據庫服務器本地驅動器中c:/temp/chart.val。在步驟3裏，Chart JavaApplet是運行在應用服務器上而不是和數據庫服務器在一個相同的盒中。當它試圖在應用服務器本地驅動器中打開c:/temp/chart.val文件時，文件並不存在。
在這個用例中，我不建議在遇到問題時就閱讀代碼，我把調試的工作留給開發人員。我只不過想指出識別哪個服務器配置是有問題的，並且在bug報告中含括這些信息。我也會在測試下的應用程序支持的全部的分別式配置下運行一個粗略的測試用例包。
配置問題在靜態操作環境中也是很終於的。例如，在圖3中我們看到在Netscape Navigator和IE瀏覽器的一個兼容性區別。
這個例子並不是要說IE比Netscape Navigator更好，它只不過意味着在瀏覽器之間有不兼容性問題－並且代碼應該假設相對路徑在所有的瀏覽器中都可以工作。更重要的是，它建議當你在一個環境中發現一個錯誤時，如果它是一個環境相關的錯誤的話，同樣的錯誤可能不會出現在不同的環境中。
動態的操作環境：事情不會保持一樣
當特定環境的屬性值不是每次都在測試過程中保持常量時，它會引起操作環境變爲動態。屬性可以從資源特定（可用的RAM，磁盤空間等）轉變爲時間特定的（網絡反應時間，用戶要提交的交易順序等）。
當一個測試用例取決於步驟集和操作環境的準確複製，然而（由於它的動態本質）操作環境不可能被複制，錯誤變得不可重現或很難重現。
順便說一下，這也是內存相關錯誤通常較難重現的原因。當一個內存覆蓋的錯誤出現在代碼中時，例如，它常常會引起一個內存覆蓋的問題。然而，從一個黑盒測試的角度看，我們永遠沒有機會看到這個錯誤的症狀直到執行或讀取特定的代碼或數據溢出字節。在這個例子中，步驟集代表了黑盒測試的準確集合。內存覆蓋錯誤代表了在代碼中的真實的錯誤。被執行或讀取的被覆蓋的字節的條件代表了動態的操作環境或需要揭露（重現）錯誤的條件。
這是一個動態環境相關錯誤的Web應用程序例子，我們在其中將調查一個時間相關錯誤。功能說明書要求：
·在系統中的項目名稱必須是唯一的
·爲了可能的複製需要在客戶端使用JavaScript來執行錯誤識別和處理
·用戶將可以通過請求項目設置頁面增加或刪除項目名稱
·當一個用戶創建一個新的項目名稱時，瀏覽器端的JavaScript檢查輸入的名稱和內嵌在HTML頁面中選擇列表（如圖4）。
看看圖5中的時間相關的錯誤。在項目設置頁面之前和之後的屏幕截圖中說明了應用程序失敗檢測重名的“Doomed”。圖4解釋了這個時間相關的錯誤，它包括了兩個用戶增加新的項目名稱到同一個數據庫中。
如表1中所示，用戶A和B同時創建新的項目，但是並不知道其他人的動作。在步驟3中，用戶A增加了一個名爲Another的項目。由於這個項目名稱已經存在，他瀏覽器的JavaScript會顯示一個提示他輸入不同項目名稱的信息。
用戶B增加了一個項目名稱爲Doomed。她瀏覽器的JavaScript不會檢測Doomed爲一個已經存在的項目名並且添加它到數據庫中並返回列表。更新過的項目名稱列表被髮送到用戶B。
用戶A隨後添加相同名稱Doomed到項目列表中。他瀏覽器的JavaScript沒有在HTML列表中檢測，因此Doomed會再次被添加到數據庫中－同樣到了返回的列表中。更新的項目名稱列表被髮送給用戶A，並且包括兩個Doomed的條目。
這個結果未能滿足產品的說明書。除非這種情況出現在一個設計良好的測試用例，偶然發現這個錯誤並且試圖重現它不是一個簡單的工作。在這個例子中，實際的錯誤是應用程序在檢查服務器端重名（除了客戶端檢查以外）的失誤。這些步驟包括用戶A的活動。通過用戶B的活動創建了動態操作環境－這些活動對於用戶A是隱藏的或不知道的。
總結
爲了有效的在Web環境中分析並重現錯誤，你需要對操作環境有個掌握。你也需要理解環境特定的變量可能會影響你複製錯誤的能力。在應用程序有着這份文章中的一些技能，我希望你的Web測試經驗將會更少的被挫敗和更加開心。
記住沒有任何東西將替代你的測試技能－你編寫出好的測試用例，問相關what-if的問題，保留仔細的記錄，並且有系統的研究難以重現的錯誤的能力。就是這些技巧不僅在尋找錯誤中給你提供幫助，而且也會幫助你發現那些和他們相關的隱藏錯誤。
