測試基于Web的應用程序(3)

　　在測試這個應用程序過程中，我發現圖表功能可以在以上的配置上運行，但是卻不能在其他配置上工作。在我更進一步的研究之后，我認識到問題可能出現在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測試經驗將會更少的被挫敗和更加開心。

原文轉自：http://www.uml.org.cn/Test/201006282.asp