測試Web Application之三：進攻

     在“測試Web Application之二：準備作戰”一文中，我給出了一些計劃測試一個web application的建議。在這關于web application測試系列的最后一篇中。我將提出測試web application的藝術，包括一些關于簡化面前任務的工具和技巧的想法。

1. 從由后向前測試，而不是由前向后

    許多測試人員集中通過瀏覽器來測試一個web application。然而，這會導致花格外的時間來測試瀏覽器，而不是web application本身。當然，你仍然需要在瀏覽器中測試，但是不要讓它變成你測試的焦點。在執行負載和性能測試的時候，這是特別重要的。如果你的web application象大多數一樣，你將有一個連接著一個或多個應用服務器的web服務器，那些應用服務器也連接著一個數據庫。因此，性能和負載的變慢可能會出現在web服務器，應用服務器或數據庫服務器上。

2. 編寫腳本是有好處的

    不通過瀏覽器測試不同后臺服務器的最好方法之一是使用腳本。我喜歡的用于測試web服務器的腳本語言是Perl，因為它容易學習，容易使用，并且有一組很好的特別為這個目的設計的（LWP或Win32::Internet library，取決于你的平臺）web服務器庫文件。他們讓你：解析HTML文件；提供客戶端請求并且處理服務器響應；創建，解析并解釋URL。你應該可以使用JavaScript，VBScript，或PerlScript來測試應用服務器和數據庫（例如，通過在腳本中嵌入SQL語句）。

3. 使用基于風險的測試

    這仍然是今天測試人員可用的最好的技術之一。在項目的初期，測試團隊應該定時地聚在一起以生成“排名前10的風險列表”，它列出了測試（明確）和項目（總體）中所有的風險。然后，當項目進行時，定時的開會并更新這個列表。利用這個列表來幫助達到你測試的目標。對于每個已驗證的風險，計劃一些方法以減少或最小化如果風險出現所帶來的影響。許多可能的解決方案將影響你的測試策略。那是可以的－這時你需要擁抱變換以最小化你失敗的風險。當新的問題突然出現時，你將不得不改變你的計劃和策略以有效地處理它們。因此不要鎖住到"隧道幻想"中，在那里你只會盲目地遵從原始的測試策略并向上天（和你的開發團隊）發誓它是*唯一*能起作用的策略。貫穿項目的始末風險會發生變化，因此為了處理它們，你的策略也必須變更。

4. 記住UI和可用性不是一樣的

    僅僅因為你的web application看上去不錯，并不意味著它是可用的（或它展示出良好的可用性）�，F實是大多數網站和web application邊際的展示出低劣的可用性。許多 web application的UI設計人員來自圖形設計或桌面出版 背景。這對于以文字基礎的網站很有用－想想Internet原本設計的目的是什么，但是web application需要更多的集中在人機界面設計上。

在考慮可用性時，5個需要記住的關鍵區域是移動，察覺，語言，內存和思考。

可以應用于以上每個區域的三個系統屬性包括：

數量－能夠記得，察覺到多少項目

距離－用戶必須在項目之間移動鼠標，為了察覺項目要在項目之間移動他們的眼睛多少距離，等等。

結構－在項目之間鼠標移動的結構，為察覺項目要在項目之間眼睛移動的結構是否一致，等等。

需要測試的一些項目：

眼睛追蹤的距離：為了記下所有相關的信息，你的眼睛必須交叉和向下移動多遠？

鼠標追蹤的距離：為了完成任務，用戶必須要移動鼠標光標多遠，包括基本的導航，例如瀏覽器中的“Back”回到一個頁面 。

顏色的組合，特別是背景和圖像。

便于導航和定位：你能怎樣輕松地說出你在網站上的位置或者用戶必須回憶嗎，你總是可以回到“首頁”嗎，你可以從每個頁面中“退出”嗎，你可以輕松地返回到上一個頁面嗎？例如搜索結果。

數據的組織：例如按字母排序的列表，按數字排序的列表，最頻繁使用項目和/或最近使用項目的列表

在線幫助：有沒有在線幫助？是否正確？

    這些僅僅是少數一些關于測試web application的心得。我希望當你和你的團隊工作以使你們的應用程序發布時它們可以節約你們一些時間和許多擔憂。然而，這些技巧不能代替經驗。你在這一領域做的工作越多，你將能積聚更多的經驗，你也將會越輕松地計劃和執行測試web application。
 

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: application Application web Web WEB