4．哪個層真正的引起了那個問題？
在Web系統中的錯誤通常是很難一直重現因為許多由C/S架構的分布式特性而引入的許多變量。（例如，服務器，客戶端和網絡組件）。在一個web環境中至少由3個常見的懷疑部分：客戶端，服務器和網絡�？蛻舳撕头⻊掌鞫紩䲠y帶誒之和兼容性問題，那些和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的問題，保留仔細的記錄，并且有系統的研究難以重現的錯誤的能力。就是這些技巧不僅在尋找錯誤中給你提供幫助，而且也會幫助你發現那些和他們相關的隱藏錯誤。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
