Web測試方法

在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟體測試不同，它不但需要檢查和驗證是否按照設計的要求執行，而且還要測試系統在不同使用者的瀏覽器端的顯示是否合適。重要的是，還要從終端使用者的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須為測試和評估複雜的基於Web的系統研究新的方法和技術

本文將 web 測試分為 6 個部分：

• 功能測試
• 效能測試（包括負載/壓力測試）
• 使用者介面測試
• 相容性測試
• 安全測試
• 介面測試

本文的目的是覆蓋 web 測試的各個方面，未就某一主題進行深入說明。

1 功能測試

1.1 連結測試

連結是Web應用系統的一個主要特徵，它是在頁面之間切換和指導使用者去一些不知道地址的頁面的主要手段。連結測試可分為三個方面。首先，測試所有連結是否按指示的那樣確實連結到了該連結的頁面；其次，測試所連結的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連結指向該頁面，只有知道正確的URL地址才能訪問。

　　連結測試可以自動進行，現在已經有許多工具可以採用。連結測試必須在整合測試階段完成，也就是說，在整個Web應用系統的所有頁面開發完成之後進行連結測試。

採取措施：採用自動檢測網站連結的軟體來進行。

推薦軟體：

Xenu Link Sleuth 免費綠色免安裝軟體

HTML Link Validator 共享（30天試用）

1.2 表單測試

當使用者通過表單提交資訊的時候，都希望表單能正常工作。

如果使用表單來進行線上註冊，要確保提交按鈕能正常工作，當註冊完成後應返回註冊成功的訊息。如果使用表單收集配送資訊，應確保程式能夠正確處理這些資料，最後能讓顧客能讓客戶收到包裹。要測試這些程式，需要驗證伺服器能正確儲存這些資料，而且後臺執行的程式能正確解釋和使用這些資訊。

當使用者使用表單進行使用者註冊、登陸、資訊提交等操作時，我們必須測試提交操作的完整性，以校驗提交給伺服器的資訊的正確性。例如：使用者填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了預設值，還要檢驗預設值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。

1.3 資料校驗

如果系根據業務規則需要對使用者輸入進行校驗，需要保證這些校驗功能正常工作。例如，省份的欄位可以用一個有效列表進行校驗。在這種情況下，需要驗證列表完整而且程式正確呼叫了該列表(例如在列表中新增一個測試值，確定系統能夠接受這個測試值)。

在測試表單時，該項測試和表單測試可能會有一些重複。

1.2和1.3的採取措施：第一個完整的版本採用手動檢查，同時形成WinRunner（QTP）指令碼；迴歸測試以及升級版本主要靠WinRunner（QTP）自動回放測試。

1.4 cookies測試

Cookies通常用來儲存使用者資訊和使用者在某應用系統的操作，當一個使用者使用Cookies訪問了某一個應用系統時，Web伺服器將傳送關於使用者的資訊，把該資訊以Cookies的形式儲存在客戶端計算機上，這可用來建立動態和自定義頁面或者儲存登陸等資訊。

　　如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內容可包括Cookies是否起作用，是否按預定的時間進行儲存，重新整理對Cookies有什麼影響等。如果在 cookies 中儲存了註冊資訊，請確認該 cookie能夠正常工作而且已對這些資訊已經加密。如果使用 cookie 來統計次數，需要驗證次數累計正確。

採取措施：

1 採用黑盒測試：採用上面提到的方法進行測試

2 採用檢視cookies的軟體進行（初步的想法）

可以選擇採用的軟體

IECookiesView v1.50

Cookies Manager v1.1

1.5 資料庫測試

在Web應用技術中，資料庫起著重要的作用，資料庫為Web應用系統的管理、執行、查詢和實現使用者對資料儲存的請求等提供空間。在Web應用中，最常用的資料庫型別是關係型資料庫，可以使用SQL對資訊進行處理。

在使用了資料庫的Web應用系統中，一般情況下，可能發生兩種錯誤，分別是資料一致性錯誤和輸出錯誤。資料一致性錯誤主要是由於使用者提交的表單資訊不正確而造成的，而輸出錯誤主要是由於網路速度或程式設計問題等引起的，針對這兩種情況，可分別進行測試。

採取措施：暫時沒有更好的測試方法

考慮結合到1.2和1.3的測試中

1.6 應用程式特定的功能需求

最重要的是，測試人員需要對應用程式特定的功能需求進行驗證。嘗試使用者可能進行的所有操作：下訂單、更改訂單、取消訂單、核對訂單狀態、在貨物傳送之前更改送貨資訊、線上支付等等。這是使用者之所以使用網站的原因，一定要確認網站能像廣告宣傳的那樣神奇。

採取措施：深刻理解需求說明文件

1.7 設計語言測試

Web設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分散式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的指令碼語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。

暫時沒有方法測試，可以多參考一點討論組內的更新資訊

2 效能測試

2.1 連線速度測試

使用者連線到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，使用者可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統響應時間太長（例如超過5秒鐘），使用者就會因沒有耐心等待而離開。

　　另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。

2.2 負載測試

負載測試是為了測量Web系統在某一負載級別上的效能，以保證Web系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統的使用者數量，也可以是線上資料處理的數量。例如：Web應用系統能允許多少個使用者同時線上？如果超過了這個數量，會出現什麼現象？Web應用系統能否處理大量使用者對同一個頁面的請求？

2.3 壓力測試

負載測試應該安排在Web系統釋出以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在Internet上，接受負載測試，其結果才是正確可信的。

　　進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼情況下會崩潰。黑客常常提供錯誤的資料負載，直到Web應用系統崩潰，接著當系統重新啟動時獲得存取權。

　　壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。

負載/壓力測試應該關注什麼

測試需要驗證系統能否在同一時間響應大量的使用者，在使用者傳送大量資料的時候能否響應，系統能否長時間執行。可訪問性對使用者來說是極其重要的。如果使用者得到“系統忙”的資訊，他們可能放棄，並轉向競爭對手。系統檢測不僅要使使用者能夠正常訪問站點，在很多情況下，可能會有黑客試圖通過傳送大量資料包來攻擊伺服器。出於安全的原因，測試人員應該知道當系統過載時，需要採取哪些措施，而不是簡單地提升系統效能。

瞬間訪問高峰
如果您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內能夠響應上百萬的請求。負載測試工具能夠模擬 X 個使用者同時訪問測試站點。

每個使用者傳送大量資料
網上書店的多數使用者可能只訂購 1-5 書，但是大學書店可能會訂購 5000 本有關心理學介紹的課本? 或者一個祖母為她的 50 個兒孫購買聖誕禮物(當然每個孩子都有自己的郵件地址) 系統能處理單個使用者的大量資料嗎?

長時間的使用
如果站點用於處理鮮花訂單，那麼至少希望它在母親節前的一週內能持續執行。如果站點提供基於 web 的 email 服務，那麼點最好能持續執行幾個月，甚至幾年。可能需要使用自動測試工具來完成這種型別的測試，因為很難通過手工完成這些測試。你可以想象組織100 個人同時點選某個站點。但是同時組織 100000 個人呢。通常，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。而且，測試工具安裝完成之後，再次使用的時候，只要點選幾下。

採取措施：採用測試工具WAS、ACT協助進行測試

3 使用者介面測試

3.1 導航測試

導航描述了使用者在一個頁面內操作的方式，在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等；或在不同的連線頁面之間。通過考慮下列問題，可以決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可通過主頁存取？Web系統是否需要站點地圖、搜尋引擎或其他的導航幫助？

　　在一個頁面上放太多的資訊往往起到與預期相反的效果。Web應用系統的使用者趨向於目的驅動，很快地掃描一個Web應用系統，看是否有滿足自己需要的資訊，如果沒有，就會很快地離開。很少有使用者願意花時間去熟悉Web應用系統的結構，因此，Web應用系統導航幫助要儘可能地準確。

　　導航的另一個重要方面是Web應用系統的頁面結構、導航、選單、連線的風格是否一致。確保使用者憑直覺就知道Web應用系統裡面是否還有內容，內容在什麼地方。

　　Web應用系統的層次一旦決定，就要著手測試使用者導航功能，讓終端使用者參與這種測試，效果將更加明顯。

3.2 圖形測試

在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web應用系統的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。圖形測試的內容有：

　　（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都連結到某個具體的頁面。

　　（2）驗證所有頁面字型的風格是否一致。

　　（3）背景顏色應該與字型顏色和前景顏色相搭配。

　　（4）圖片的大小和質量也是一個很重要的因素，一般採用JPG或GIF壓縮，最好能使圖片的大小減小到 30k 以下

（5）最後，需要驗證的是文字迴繞是否正確。如果說明文字指向右邊的圖片，應該確保該圖片出現在右邊。不要因為使用圖片而使視窗和段落排列古怪或者出現孤行。

通常來說，使用少許或儘量不使用背景是個不錯的選擇。如果您想用背景，那麼最好使用單色的，和導航條一起放在頁面的左邊。另外，圖案和圖片可能會轉移使用者的注意力。

3.3內容測試

內容測試用來檢驗Web應用系統提供資訊的正確性、準確性和相關性。

　　資訊的正確性是指資訊是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；資訊的準確性是指是否有語法或拼寫錯誤。這種測試通常使用一些文書處理軟體來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；資訊的相關性是指是否在當前頁面可以找到與當前瀏覽資訊相關的資訊列表或入口，也就是一般Web站點中的所謂"相關文章列表"。

對於開發人員來說，可能先有功能然後才對這個功能進行描述。大家坐在一起討論一些新的功能，然後開始開發，在開發的時候，開發人員可能不注重文字表達，他們新增文字可能只是為了對齊頁面。不幸的是，這樣出來的產品可能產生嚴重的誤解。因此測試人員和公關部門一起檢查內容的文字表達是否恰當。否則，公司可能陷入麻煩之中，也可能引起法律方面的問題。測試人員應確保站點看起來更專業些。過分地使用粗體字、大字型和下劃線可能會讓使用者感到不舒服。在進行使用者可用性方面的測試時，最好先請圖形設計專家對站點進行評估。你可能不希望看到一篇到處是黑體字的文章，所以相信您也希望自己的站點能更專業一些。 最後，需要確定是否列出了相關站點的連結。很多站點希望使用者將郵件發到一個特定的地址，或者從某個站點下載瀏覽器。但是如果使用者無法點選這些地址，他們可能會覺得很迷惑。

3.4 表格測試

需要驗證表格是否設定正確。使用者是否需要向右滾動頁面才能看見產品的價格？把價格放在左邊，而把產品細節放在右邊是否更有效? 每一欄的寬度是否足夠寬，表格裡的文字是否都有折行？是否有因為某一格的內容太多，而將整行的內容拉長?

3.5 整體介面測試

整體介面是指整個Web應用系統的頁面結構設計，是給使用者的一個整體感。例如：當使用者瀏覽Web應用系統時是否感到舒適，是否憑直覺就知道要找的資訊在什麼地方？整個Web應用系統的設計風格是否一致？

對整體介面的測試過程，其實是一個對終端使用者進行調查的過程。一般Web應用系統採取在主頁上做一個調查問卷的形式，來得到終端使用者的反饋資訊。

　　對所有的使用者介面測試來說，都需要有外部人員（與Web應用系統開發沒有聯絡或聯絡很少的人員）的參與，最好是終端使用者的參與。

採取措施：手動測試，參與人員最好有外部人員

4 相容性測試

4.1 平臺測試

市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux等。Web應用系統的終端使用者究竟使用哪一種作業系統，取決於使用者系統的配置。這樣，就可能會發生相容性問題，同一個應用可能在某些作業系統下能正常執行，但在另外的作業系統下可能會執行失敗。

　　因此，在Web系統釋出之前，需要在各種作業系統下對Web系統進行相容性測試。

4.2 瀏覽器測試

瀏覽器是Web客戶端最核心的構件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規格有不同的支援。例如，ActiveX是Microsoft的產品，是為Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設定也不一樣。

　　測試瀏覽器相容性的一個方法是建立一個相容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構件和設定的適應性。

4.3 解析度測試

頁面版式在 640x400、600x800 或 1024x768 的解析度模式下是否顯示正常? 字型是否太小以至於無法瀏覽? 或者是太大? 文字和圖片是否對齊?

4.4 Modem/連線速率

是否有這種情況，使用者使用 28.8 modem下載一個頁面需要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 使用者在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最後，需要確認圖片不會太大。

4.5 印表機

使用者可能會將網頁列印下來。因此網也在設計的時候要考慮到列印問題，注意節約紙張和油墨。有不少使用者喜歡閱讀而不是盯著螢幕，因此需要驗證網頁列印是否正常。有時在螢幕上顯示的圖片和文字的對齊方式可能與列印出來的東西不一樣。測試人員至少需要驗證訂單確認頁面列印是正常的。

4.6 組合測試

最後需要進行組合測試。600x800 的解析度在 MAC 機上可能不錯，但是在 IBM 相容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。如果是內部使用的 web 站點，測試可能會輕鬆一些。如果公司指定使用某個型別的瀏覽器，那麼只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。(但需要注意的是，可能會有員工從家裡撥號進入系統) 有些內部應用程式，開發部門可能在系統需求中宣告不支援某些系統而只支援一些那些已設定的系統。但是，理想的情況是，系統能在所有機器上執行，這樣就不會限制將來的發展和變動。

採取措施：根據實際情況，採取等價劃分的方法，列出相容性矩陣

5 安全測試

即使站點不接受信用卡支付，安全問題也是非常重要的。Web 站點收集的使用者資料只能在公司內部使用。如果使用者資訊被黑客洩露，客戶在進行交易時，就不會有安全感。

5.1 目錄設定

Web 安全的第一步就是正確設定目錄。每個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的所有內容。我服務的一個公司沒有執行這條規則。我選中一幅圖片，單擊滑鼠右鍵，找到該圖片所在的路徑"…com/objects/images"。然後在瀏覽器位址列中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什麼關係。我進入下一級目錄 "…com/objects" ，點選 jackpot。在該目錄下有很多資料，其中引起我注意的是已過期頁面。該公司每個月都要更改產品價格，並且儲存過期頁面。我翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們為了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前檢視了這些資訊，他們在談判桌上肯定處於上風。

5.2 SSL

很多站點使用 SSL 進行安全傳送。你知道你進入一個 SSL 站點是因為瀏覽器出現了警告訊息，而且在位址列中的 HTTP 變成 HTTPS。如果開發部門使用了SSL，測試人員需要確定是否有相應的替代頁面(適用於3.0 以下版本的瀏覽器，這些瀏覽器不支援SSL。當使用者進入或離開安全站點的時候，請確認有相應的提示資訊。是否有連線時間限制？超過限制時間後出現什麼情況？

5.3 登入

有些站點需要使用者進行登入，以驗證他們的身份。這樣對使用者是方便的，他們不需要每次都輸入個人資料。你需要驗證系統阻止非法的使用者名稱/口令登入，而能夠通過有效登入。使用者登入是否有次數限制? 是否限制從某些 IP 地址登入? 如果允許登入失敗的次數為3，你在第三次登入的時候輸入正確的使用者名稱和口令，能通過驗證嗎? 口令選擇有規則限制嗎?  是否可以不登陸而直接瀏覽某個頁面？

Web應用系統是否有超時的限制，也就是說，使用者登陸後在一定時間內（例如15分鐘）沒有點選任何頁面，是否需要重新登陸才能正常使用。

5.4 日誌檔案

在後臺，要注意驗證伺服器日誌工作正常。日誌是否記所有的事務處理? 是否記錄失敗的註冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務完成的時候都進行儲存? 記錄IP 地址嗎? 記錄使用者名稱嗎?

5.5 指令碼語言

指令碼語言是常見的安全隱患。每種語言的細節有所不同。有些指令碼允許訪問根目錄。其他只允許訪問郵件伺服器，但是經驗豐富的黑客可以將伺服器使用者名稱和口令傳送給他們自己。找出站點使用了哪些指令碼語言，並研究該語言的缺陷。還要需要測試沒有經過授權，就不能在伺服器端放置和編輯指令碼的問題。最好的辦法是訂閱一個討論站點使用的指令碼語言安全性的新聞組。　

6 介面測試

在很多情況下，web 站點不是孤立。Web 站點可能會與外部伺服器通訊，請求資料、驗證資料或提交訂單。

6.1伺服器介面

第一個需要測試的介面是瀏覽器與伺服器的介面。測試人員提交事務，然後檢視伺服器記錄，並驗證在瀏覽器上看到的正好是伺服器上發生的。測試人員還可以查詢資料庫，確認事務資料已正確儲存。

這種測試可以歸到功能測試中的表單測試和資料校驗測試中

6.2 外部介面

有些 web 系統有外部介面。例如，網上商店可能要實時驗證信用卡資料以減少欺詐行為的發生。測試的時候，要使用 web 介面傳送一些事務資料，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的資料。(簡單的客戶端指令碼能夠在提交事務之前對程式碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，測試人員需要確認軟體能夠處理外部伺服器返回的所有可能的訊息。 

這種情況在遠端抄表中可能會體現到

6.3 錯誤處理

最容易被測試人員忽略的地方是介面錯誤處理。通常我們試圖確認系統能夠處理所有錯誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什麼情況？訂單是否完成？嘗試中斷使用者到伺服器的網路連線。嘗試中斷 web 伺服器到信用卡驗證伺服器的連線。在這些情況下，系統能否正確處理這些錯誤？是否已對信用卡進行收費？如果使用者自己中斷事務處理，在訂單已儲存而使用者沒有返回網站確認的時候，需要由客戶代表致電使用者進行訂單確認。

採取措施：在理解需求的基礎上，充分發揮想象力，儘量比較全面的列出各種異常情況

7 結論

無論你在測試 internet、intranet 或者是 extranet 應用程式，web 測試相對於非 web 測試來說都是更具挑戰性的工作。使用者對 web 頁面質量有很高的期望。在很多情況下，就像業務功能一樣，頁面用於維護和發展公共關係，所以第一印象非常重要。