測試方法
基於Web的系統測試與傳統的軟件測試既有相同之處，也有不同的地方。基於Web的系統測試不但需要檢查和驗證是否按照設計的要求運行，而且還要評價系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。下面從功能、性能、可用性、客戶端兼容性、安全性等方面討論基於Web的系統測試方法。
在基於Web的系統開發中，如果缺乏嚴格的過程，在開發、發佈、實施和維護Web的過程中，可能就會碰到一些嚴重的問題，失敗的可能性很大。而且，隨着基於Web的系統變得越來越複雜，一個項目的失敗將可能導致很多問題。當這種情況發生時，我們對Web和 Internet的信心可能會無法挽救地動搖，從而引起Web危機。並且，Web危機可能會比軟件開發人員所面對的軟件危機更加嚴重、更加廣泛。
在Web工程過程中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟件測試不同，它不但需要檢查和驗證是否按照設計的要求運行，而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而， Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此，我們必須爲測試和評估複雜的基於Web的系統研究新的方法和技術。
一般軟件的發佈週期以月或以年計算，而Web應用的發佈週期以天計算甚至以小時計算。Web測試人員必須處理更短的發佈週期，測試人員和測試管理人員面臨着從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。
一、界面測試
現在一般人都有使用瀏覽器瀏覽網頁的經歷，用戶雖然不是專業人員但是對界面效果的印象是很重要的。如果你注重這方面的測試，那麼驗證應用程序是否易於使用就非常重要了。很多人認爲這是測試中最不重要的部分，但是恰恰相反界面對不懂技術的客戶來說那相當關鍵，慢慢體會你會明白的。
方法上可以根據設計文檔，如果夠專業的話可以專業美工人員，來確定整體風格頁面風格，然後根據這個可以頁面人員可以生成靜態的HTML，CSS等甚至生成幾套不用的方案來討論，或者交給客戶評審，最後形成統一的風格的頁面/框架。注意不要靠程序員的美術素養形成你的web風格，那樣可能會很糟糕。
主要包括以下幾個方面的內容：
· 站點地圖和導航條 位置、是否合理、是否可以導航等內容佈局 佈局是否合理，滾動條等簡介說明 說明文字是否合理，位置，是否正確；
· 背景/色調 是否正確、美觀，是否符合用戶需求；
· 頁面在窗口中的顯示是否正確、美觀（在調整瀏覽器窗口大小時，屏幕刷新是否正確）表單樣式 大小，格式，是否對提交數據進行驗證（如果在頁面部分進行驗證的話）等；
·連接的形式，位置，是否易於理解等。
web測試的主要頁面元素
· 頁面元素的容錯性列表（如輸入框、時間列表或日曆）；
· 頁面元素清單（爲實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、複選框、列表框、超連接、輸入框等等）；
· 頁面元素的容錯性是否存在；
· 頁面元素的容錯性是否正確；
· 頁面元素基本功能是否實現（如文字特效、動畫特效、按鈕、超連接）；
· 頁面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超連接等）；
· 頁面元素是否顯示正確（主要針對文字、圖形、簽章）；
· 元素是否顯示（元素是否存在）；
· 頁面元素清單（爲實現功能，是否將所需要的元素全部都列出來了，如按鈕、單選框、複選框、列表框、超連接、輸入框等等）。
測試技術
· 通過頁面走查，瀏覽確定使用的頁面是否符合需求。可以結合兼容性測試對不用分辨率下頁面顯示效果，如果有影響應該交給設計人員提出解決方案；
· 可以結合數據定義文檔查看錶單項的內容，長度等信息；
· 對於動態生成的頁面最好也能進行瀏覽查看。如Servelet部分可以結合編碼規範，進行代碼走查。是否支持中文，如果數據用XML封裝要做的工作會多一點等等。
1、界面測試要素:
符合標準和規範,靈活性,正確性,直觀性,舒適性,實用性,一致性
1.1直觀性:
· 用戶界面是否潔淨,不唐突,不擁擠.界面不應該爲用戶製造障礙.所需功能或者期待的響應應該明顯,並在預期出現的地方；
· 界面組織和佈局合理嗎?是否允許用戶輕鬆地從一個功能轉到另一個功能?下一步做什麼明顯嗎?任何時刻都可以決定放棄或者退回,退出嗎?輸入得到承認了嗎?菜單或者窗口是否深藏不露?
· 有多餘功能嗎?軟件整體抑或局部是否做得太多?是否有太多特性把工作複雜化了?是否感到信息太龐雜?
· 如果其他所有努力失敗,幫助系統真能幫忙嗎?
l.2一致性
· 快速鍵和菜單選項.在Windows 中按F1鍵總是得到幫助信息；
· 術語和命令.整個軟件使用同樣的術語嗎?特性命名一致嗎?例如,Find是否一直叫Find,而不是有時叫Search?
· 軟件是否一直面向同一級別用戶?帶有花哨用戶界面的趣味賀卡程序不應該顯示泄露技術機密的錯誤提示信息；
· 按鈕位置和等價的按鍵.大家是否注意到對話框有OK按鈕和Cancel按鈕時,OK按鈕總是在上方或者左方,而Cancel按鈕總是在下方或右方?同樣原因,Cancel按鈕的等價按鍵通常是Esc,而選中按鈕的等價按鈕通常是Enter.保持一致。
l.3 靈活性
· 狀態跳轉：靈活的軟件實現同一任務有多種選擇方式；
· 狀態終止和跳過：具有容錯處理能力；
· 數據輸入和輸出：用戶希望有多種方法輸入數據和查看結果.例如,在寫字板插入文字可用鍵盤輸入,粘貼,從6種文件格式讀入,作爲對象插入,或者用鼠標從其他程序拖動。
l.4 舒適性
· 恰當：軟件外觀和感覺應該與所做的工作和使用者相符；
· 錯誤處理：程序應該在用戶執行嚴重錯誤的操作之前提出警告,並允許用戶恢復由於錯誤操作導致丟失的數據，如大家認爲undo /redo是當然的；
· 性能：快不見得是好事，要讓用戶看得清程序在做什麼，它是有反應的。
二、功能測試
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應用系統的圖形可以包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。Web應用系統的圖片尺寸要儘量地小，並且要能清楚地說明某件事情，一般都鏈接到某個具體的頁面。
（2）驗證所有頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，一般採用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應用系統的安全性測試區域主要有：
（1）現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。
（2）Web應用系統是否有超時的限制，也就是說，用戶登陸後在一定時間內（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。
（3）爲了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。
（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。
（5）服務器端的腳本常常構成安全漏洞，這些漏洞又常常被黑客利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。