原文依據：Web Testing: Complete guide on testing web applications
本文原文：软件测试基于Web的系统测试方法
基於 Web 的系統測試與傳統的軟體測試既有相同之處，也有不同的地方，對軟體測試提出了新的挑戰。基於 Web 的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的流覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。
本文從功能、性能、可用性、用戶端相容性、安全性等方面討論了基於 Web 的系統測試方法。
隨著 Internet 和 Intranet/Extranet 的快速增長，Web 已經對商業、工業、銀行、財政、教育、政府和娛樂及我們的工作和生活產生了深遠的影響。許多傳統的資訊和資料庫系統正在被移植到互聯網 上，電子商務迅速增長，早已超過了國界。範圍廣泛的、複雜的分散式應用正在 Web 環境中出現。Web 的流行和無所不在，是因為它能提供支援所有類型內容連 接的資訊發佈，容易為最終用戶存取。
Yogesh Deshpande 和 Steve Hansen 在1998年就提出了 Web 工程的概念。Web 工程作為一門新興的學科，提倡使用一個過程和系統的方法來開發高品質的基於 Web 的系統。它" 使用合理的、科學的工程和管理原則，用嚴密的和系統的方法來開發、發佈和維護基於 Web 的系統"。目前，對於 Web 工程的研究主要是在國外開展的，國內還剛剛起步。
在基於 Web 的系統開發中，如果缺乏嚴格的過程，我們在開發、發佈、實施和維護 Web 的過程中，可能就會 碰到一些嚴重的問題，失敗的可能性很大。而且，隨著基於 Web 的系統變得越來越複雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對 Web 和 Internet 的信心可能會無法挽救地動搖，從而引起 Web 危機。並且， Web 危機可能會比軟體發展人員所面對的軟體危機更加嚴重、更加廣泛。
在 Web 工程過程中，基於 Web 系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於 Web 的系統測試與傳統的軟體測試不同，它不但需要檢查和驗證是 否按照設計的要求運行，而且還要測試系統在不同用戶的流覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然 而，Internet 和 Web 媒體的不可預見性使測試基於 Web 的系統變得困難。因此，我們必須為測試和評估複雜的基於 Web 的系統研究新的方法和技術。
一般軟體的發佈週期以月或以年計算，而 Web 應用的發佈週期以天計算甚至以小時計算。 Web 測試人員必須處理更短的發佈週期，測試人員和測試管理人員面臨著從測試傳統的C/S結構和框架環境到測試快速改變的 Web 應用系統的轉變。
一、功能測試
1、鏈結測試
鏈結是 Web 應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道位址的頁面的主要手段。鏈結測試可分為三個方面。首先，測試所有鏈結是否按 指示的那樣確實鏈結到了該鏈結的頁面；其次，測試所鏈結的頁面是否存在；最後，保證 Web 應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的 URL 位址才能訪問。
鏈結測試可以自動進行，現在已經有許多工具可以採用。鏈結測試必須在集成測試階段完成，也就是說，在整個 Web 應用系統的所有頁面開發完成之後進行鏈結測試。
2、表單測試
當用戶給 Web 應用系統管理員提交資訊時，就需要使用表單操作，例如用戶註冊、登陸、資訊提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交 給伺服器的資訊的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了預設值，還要檢驗默認值的正確性。如 果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。
3、Cookies 測試
Cookies 通常用來存儲用戶資訊和用戶在某應用系統的操作，當一個用戶使用 Cookies 訪問了某一個應用系統時， Web 伺服器將發送關於用戶的資訊，把該資訊以 Cookies 的形式存儲在用戶端電腦上，這可用來創建動態和自定義頁面或者存儲登入等資訊。
如果 Web 應用系統使用了 Cookies，就必須檢查 Cookies 是否能正常工作。測試的內容可包括 Cookies 是否起作用，是否按預定的時間進行保存，刷新對 Cookies 有什麼影響等。
4、設計語言測試
Web 設計語言版本的差異可以引起用戶端或伺服器端嚴重的問題，例如使用哪種版本的 HTML 等。當在分散式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了 HTML 的版本問題外，不同的腳本語言，例如 Java、JavaScript、ActiveX、VBScript 或 Perl 等也要進行驗證。
5、資料庫測試
在 Web 應用技術中，資料庫起著重要的作用，資料庫為 Web 應用系統的管理、運行、查詢和實現用戶對資料存儲的請求等提供空間。在 Web 應用中，最常用的資料庫類型是關係型數據庫，可以使用 SQL 對資訊進行處理。
在使用了資料庫的 Web 應用系統中，一般情況下，可能發生兩種錯誤，分別是資料一致性錯誤和輸出錯誤。資料一致性錯誤主要是由於用戶提交的表單資訊不正確而造成的，而輸出錯誤主要是由於網路速度或程式設計問題等引起的，針對這兩種情況，可分別進行測試。
二、性能測試
1、連接速度測試
用戶連接到 Web 應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬頻上網。當下載一個程式時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果 Web 系統回應時間太長(例如超過5秒鐘)，用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，如果回應速度太慢，用戶可能還沒來得及流覽內容，就需要重新登入了。而且，連接速度太慢，還可能引起資料丟失，使用戶得不到真實的頁面。
2、負載測試
負載測試是為了測量 Web 系統在某一負載級別上的性能，以保證 Web 系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問 Web 系統的用戶數量，也可以是線上資料處理的數量。例如： Web 應用系統能允許多少個用戶同時線上？如果超過了這個數量，會出現什麼現象？ Web 應用系統能否處理大量用戶對同一 個頁面的請求？
3、壓力測試
負載測試應該安排在 Web 系統發佈以後，在實際的網路環境中進行測試。因為一個企業內部員工，特別是專案組人員總是有限的，而一個 Web 系統能同時處理的請求數量將遠遠超出這個限度，所以，只有放在 Internet 上，接受負載測試，其結果才是正確可信的。
進行壓力測試是指實際破壞一個 Web 應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試 Web 應用系統會不會崩潰，在什麼情況下會崩潰。駭客常常提供錯誤的資料負載，直到 Web 應用系統崩潰，接著當系統重新啟動時獲得存取權。
壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。
三、可用性測試
1、導航測試
導航描述了用戶在一個頁面內操作的方式，在不同的用戶介面控制之間，例如按鈕、對話方塊、列表和視窗等；或在不同的連接頁面之間。通過考慮下列問題，可以決定一個 Web 應用系統是否易於導航：導航是否直觀？ Web 系統的主要部分是否可通過主頁存取？ Web 系統是否需要站點地圖、搜索引擎或其他的導航幫助？
在一個頁面上放太多的資訊往往起到與預期相反的效果。 Web 應用系統的用戶趨向於目的驅動，很快地掃描一個 Web 應用系統，看是否有滿足自己需要的資訊，如 果沒有，就會很快地離開。很少有用戶願意花時間去熟悉 Web 應用系統的結構，因此， Web 應用系統導航幫助要盡可能地準確。
導航的另一個重要方面是 Web 應用系統的頁面結構、導航、功能表、連接的風格是否一致。確保用戶憑直覺就知道 Web 應用系統裏面是否還有內容，內容在什麼地方。
Web 應用系統的層次一旦決定，就要著手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2、圖形測試
在 Web 應用系統中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個 Web 應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
- 要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。 Web 應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都鏈結到某個具體的頁面。
- 驗證所有頁面字體的風格是否一致。
- 背景顏色應該與字體顏色和前景顏色相搭配。
- 圖片的大小和品質也是一個很重要的因素，一般採用 JPG 或 GIF 壓縮。
3、內容測試
內容測試用來檢驗 Web 應用系統提供資訊的正確性、準確性和相關性。資訊的正確性是指資訊是可靠的還是誤傳的。例如，在商品價格列表中，錯誤的價格可能引起財政問題甚至導致法律糾紛；資訊的準確性是指是否有語法或拼寫錯誤。 這種測試通常使用一些文書處理軟體來進行，例如使用 Microsoft Word 的「拼音與語法檢查」功能；資訊的相關性是指是否在當前頁面可以找到與當前流覽資訊相關的資訊列表或入口，也就是一般 Web 站點中的所謂「相關文章列表」。
4、整體介面測試
整體介面是指整個 Web 應用系統的頁面結構設計，是給用戶的一個整體感。例如：當用戶流覽 Web 應用系統時是否感到舒適，是否憑直覺就知道要找的資訊在什麼地方？整個 Web 應用系統的設計風格是否一致？
對整體介面的測試過程，其實是一個對最終用戶進行調查的過程。一般 Web 應用系統採取在主頁上做一個調查問卷的形式，來得到最終用戶的回饋資訊。
對所有的可用性測試來說，都需要有外部人員(與 Web 應用系統開發沒有聯繫或聯繫很少的人員)的參與，最好是最終用戶的參與。
四、用戶端相容性測試
1、平臺測試
市場上有很多不同的作業系統類型，最常見的有 Windows、Unix、Macintosh、Linux 等。 Web 應用系統的最終用戶究竟使用哪一種作業系統，取決於用戶系統的配置。這樣，就可能會發生相容性問題，同一個應用可能在某些作業系統下能正常運行，但在另外的作業系統下可能會運行失敗。因此，在 Web 系統發佈之前，需要在各種作業系統下對 Web 系統進行相容性測試。
2、流覽器測試
流覽器是 Web 用戶端最核心的構件，來自不同廠商的流覽器對 Java、JavaScript、ActiveX、plug-ins 或不同的 HTML 規格有不同的支援。例如，ActiveX 是 Microsoft 的產品，是為 Internet Explorer 而設計的，JavaScript 是 Netscape 的產品，Java 是 Sun 的產品等等。另外，框架和層次結構風格在不同的流覽器中也有不同的顯示，甚至根本不顯示。不同的流覽器對安全性和 Java 的設置也不一樣。
測試流覽器相容性的一個方法是創建一個相容性矩陣。在這個矩陣中，測試不同廠商、不同版本的流覽器對某些構件和設置的適應性。
五、安全性測試
Web 應用系統的安全性測試區域主要有：
- 現在的 Web 應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接流覽某個頁面等。
- Web 應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內(例如15分鐘)沒有點擊任何頁面，是否需要重新登陸才能正常使用。
- 為了保證 Web 應用系統的安全性，日誌檔是至關重要的。需要測試相關資訊是否寫進了日誌檔、是否可追蹤。
- 當使用了安全套接字時，還要測試加密是否正確，檢查資訊的完整性。
- 伺服器端的腳本常常構成安全漏洞，這些漏洞又常常被駭客利用。所以，還要測試沒有經過授權，就不能在伺服器端放置和編輯腳本的問題。
總結
本文從功能、性能、可用性、用戶端相容性、安全性等方面討論了基於 Web 的系統測試方法。
基於 Web 的系統測試與傳統的軟體測試既有相同之處，也有不同的地方，對軟體測試提出了新的挑戰。基於 Web 的系統測試不但需要檢查和驗證是否按照設計的要 求運行，而且還要評價系統在不同用戶的流覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。
