網站測試流程、要求及測試報告

基於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應用系統的轉變。 

　　網站測試流程、要求及測試報告 
一個網站基本完工後，需要通過下面三步測試纔可以交活。 
一、 製作者測試，包括美工測試頁面、程序員測試功能。在做完後第一時間內有製作者本人進行測試。 
a) 頁面 包括首頁、二級頁面、三級頁面的頁面在各種常用分辨率下有無錯位；圖片上有沒有錯別字；各連接是否是死連接；各欄目圖片與內容是否對應等 
b) 功能 達到客戶要求；數據庫連接正確；各個動態生成連接正確；傳遞參數格式、內容正確；試填測試內容沒有報錯；頁面顯示正確 
二、 全面測試 根據交工標準和客戶要求，由專人進行全面測試 
也是包括頁面和程序兩方面，而且要結合起來測，保證填充足夠的內容後不會導致頁面變形。另外要檢查是否有錯別字，文字內容是否有常識錯誤。 
三、 發佈測試 網站發佈到主服務器之後的測試，主要是防止環境不同導致的錯誤 



軟件缺陷的原則 
軟件缺陷區別於軟件bug,它是在測試過程中出現的對系統有影響的,但是在設計中沒有的或者對修改後的bug測試和開發人員有不同意見等 
軟件未達到產品說明書標明的功能。 
軟件出現了產品說明書指明不會出現的錯誤。 
軟件功能超出產品說明書指明範圍。 
軟件未達到產品說明書雖未指出但應達到的目標。 
軟件測試員認爲軟件難以理解、不易使用、運行速度緩慢，或者最終用戶認爲不好。 



測試的主要方面： 

一、功能測試 

對於網站的測試而言，每一個獨立的功能模塊需要單獨的測試用例的設計導出，主要依據爲《需求規格說明書》及《詳細設計說明書》，對於應用程序模塊需要設計者提供基本路徑測試法的測試用例。 

1、鏈接測試 
　　 鏈接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。鏈接測試可分爲三個方面： 

1）測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面； 

2）測試所鏈接的頁面是否存在； 

3）保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。 

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

Xenu------主要測試鏈接的正確性的工具 
可惜的是對於動態生成的頁面的測試會出現一些錯誤。 

2、表單測試 

當用戶給Web應用系統管理員提交信息時，就需要使用表單操作，例如用戶註冊、登陸、信息提交等。在這種情況下，我們必須測試提交操作的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。如果使用了默認值，還要檢驗默認值的正確性。如果表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統是否會報錯。 

要測試這些程序，需要驗證服務器能正確保存這些數據，而且後臺運行的程序能正確解釋和使用這些信息。 

B/S結構實現的功能可能主要的就在這裏，提交數據，處理數據等如果有固定的操作流程可以考慮自動化測試工具的錄製功能，編寫可重複使用的腳本代碼，可以在測試、迴歸測試時運行以便減輕測試人員工作量。 

我們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要測試方法爲：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。 

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應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由於網絡速度或程序設計問題等引起的，針對這兩種情況，可分別進行測試。 

二、性能測試 

網站的性能測試對於網站的運行而言異常重要，但是目前對於網站的性能測試做的不夠，我們在進行系統設計時也沒有一個很好的基準可以參考，因而建立網站的性能測試的一整套的測試方案將是至關重要的。 
網站的性能測試主要從三個方面進行：連接速度測試、負荷測試(Load)和壓力測試(Stress), 

連接速度測試指的是打開網頁的響應速度測試。負荷測試指的是進行一些邊界數據的測試，壓力測試更像是惡意測試，壓力測試傾向應該是致使整個系統崩潰。 

1、連接速度測試 

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

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

2、負載測試 

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

3、壓力測試 

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

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

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

採用的測試工具： 

性能測試可以採用相應的工具進行自動化測試，我們目前採用如下工具 
ab -----Apache 的測試工具 
OpenSTA—開發系統測試架構 

三、接口測試 
在很多情況下，web 站點不是孤立。Web 站點可能會與外部服務器通訊，請求數據、 

驗證數據或提交訂單。 

1、 服務器接口 
第一個需要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，然後查看服務器 

記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還可以查詢數據庫，確認事務數據已正確保存。 

2、 外部接口 
有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減少欺詐行 

爲的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店只使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的數據。(簡單的客戶端腳本能夠在提交事務之前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，測試人員需要確認軟件能夠處理外部服務器返回的所有可能的消息。 

3、錯誤處理 
最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認系統能夠處理所有錯 

誤，但卻無法預期系統所有可能的錯誤。嘗試在處理過程中中斷事務，看看會發生什麼情況？ 

訂單是否完成？嘗試中斷用戶到服務器的網絡連接。嘗試中斷 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應用系統開發沒有聯繫或聯繫很少的人員）的參與，最好是最終用戶的參與。 

五、兼容性測試 

需要驗證應用程序可以在用戶使用的機器上運行。如果您用戶是全球範圍的，需要測試各種操作系統、瀏覽器、視頻設置和 modem 速度。最後，還要嘗試各種設置的組合。 

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的設置也不一樣。 

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

採用測試工具： 

通過白盒測試或者黑盒測試導出的測試用例，採用相應的工具進行測試，可以採用OpenSTA進行測試，此測試工具可以採用不同的瀏覽器進行測試。 

3．視頻測試 

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

4．Modem/連接速率測試 
是否有這種情況，用戶使用 28.8 modem下載一個頁面需要 10 分鐘，但測試人員在測 

試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間， 

但卻不會耐心等待首頁的出現。最後，需要確認圖片不會太大。 

5、打印機測試 

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

6、組合測試 
最後需要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，但是在 IBM 兼容 

機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻無法使用 Lynx 來瀏覽。 

如果是內部使用的 web 站點，測試可能會輕鬆一些。如果公司指定使用某個類型的瀏覽器， 

那麼只需在該瀏覽器上進行測試。如果所有的人都使用 T1 專線，可能不需要測試下載施加。 

(但需要注意的是，可能會有員工從家裏撥號進入系統) 有些內部應用程序，開發部門可能 

在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。但是，理想的情況是， 

系統能在所有機器上運行，這樣就不會限制將來的發展和變動。 

六、安全測試 

Web應用系統的安全性測試區域主要有： 

1、 目錄設置 
Web 安全的第一步就是正確設置目錄。每個目錄下應該有 index.html 或 main.html 頁 

面，這樣就不會顯示該目錄下的所有內容。如果沒有執行這條規則。那麼選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/p_w_picpaths"。然後在瀏覽器地址欄中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什麼關係。但是進入下一級目錄 "…com/objects" ，點擊 jackpot。在該目錄下有很多資料，其中有些都是已過期頁面。如果該公司每個月都要更改產品價格信息，並且保存過期頁面。那麼只要翻看了一下這些記錄，就可以估計他們的邊際利潤以及他們爲了爭取一個合同還有多大的降價空間。如果某個客戶在談判之前查看了這些信息，他們在談判桌上肯定處於上風。 

2．登錄 

　 現在的Web應用系統基本採用先註冊，後登陸的方式。因此，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，可以試多少次的限制，是否可以不登陸而直接瀏覽某個頁面等。　 

3．Session 

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

4．日誌文件 

爲了保證Web應用系統的安全性，日誌文件是至關重要的。需要測試相關信息是否寫進了日誌文件、是否可追蹤。 

5．加密 

當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。 

6．安全漏洞 

服務器端的腳本常常構成安全漏洞，這些漏洞又常常被***利用。所以，還要測試沒有經過授權，就不能在服務器端放置和編輯腳本的問題。 

目前網絡安全問題日益重要，特別對於有交互信息的網站及進行電子商務活動的網站尤其重要。目前我們的測試沒有涵蓋網站的安全性的測試，我們擬定採用工具來測定， 

工具如下 
SAINT------- Security Administrator’s Integrated Network Tool 
此工具能夠測出網站系統的相應的安全問題，並且能夠給出安全漏洞的解決方案，不過是一些較爲常見的漏洞解決方案。 

七、代碼合法性測試 
代碼合法性測試主要包括2個部分：程序代碼合法性檢查與顯示代碼合法性檢查。 

1、程序代碼合法性檢查 
程序代碼合法性檢查主要標準爲《intergrp小組編程規範》，目前採用由SCM管理員進行規範的檢查，未來期望能夠有相應的工具進行測試。 

2、顯示代碼合法性檢查 
顯示代碼的合法性檢查，主要分爲Html、JavaScript、Css代碼檢查，目前採用 
HTML代碼檢查------採用CSE HTML Validator進行測試 
JavaScript、Css也可以在網上下載相應的測試工具。 

八、 文檔測試 
l、產品說明書屬性檢查清單 
1）完整.是否有遺漏和丟失，完全嗎？ 單獨使用是否包含全部內容 
2）準確.既定解決方案正確嗎？ 目標明確嗎？ 有沒有錯誤？ 
3）精確、不含糊、清晰.描述是否一清二楚？ 還是自說自話？容易看懂和理解嗎？ 
4）一致.產品功能能描述是否自相矛盾,與其他功能有沒有衝突 
5）貼切.描述功能的陳述是否必要？有沒有多餘信息？ 功能是否原來的客戶要求？ 
6）合理.在特定的預算和進度下,以現有人力,物力和資源能否實現？ 
7）代碼無關.是否堅持定義產品,而不是定義其所信賴的軟件設計,架構和代碼 
8）可測試性.特性能否測試？ 測試員建立驗證操作的測試程序是否提供足夠的信息？ 
2、 產品說明書用語檢查清單 
1）說明。 對問題的描述通常表現爲粉飾沒有仔細考慮的功能----可歸結於前文所述的屬性.從產品說明書上找出這樣的用語,仔細審視它們在文中是怎樣使用的.產品說明書可能會爲其掩飾和開脫,也可能含糊其詞----無論是哪一種情況都可視爲軟件缺陷. 
2）總是,每一種,所有,沒有,從不.如果看到此類絕對或肯定的,切實認定的敘述,軟件測試員就可以着手設計針鋒相對的案例. 
3）當然,因此,明顯,顯然,必然.這些話意圖誘使接受假定情況.不要中了圈套. 
4）某些,有時,常常,通常,慣常,經常,大多,幾乎.這些話太過模糊."有時"發生作用的功能無法測試. 
5）等等,諸如此類,依此類推.以這樣的詞結束的功能清單無法測試.功能清單要絕對或者解釋明確,以免讓人迷惑,不知如何推論. 
6）良好,迅速,廉價,高效,小,穩定.這些是不確定的說法,不可測試.如果在產品說明書中出現,就必須進一步指明含義. 
7）已處理,已拒絕,已忽略,已消除.這些廉潔可能會隱藏大量需要說明的功能. 
8）如果...那麼...(沒有否則).找出有"如果...那麼..."而缺少配套的"否則"結構的陳述.想一想"如果"沒有發生會怎樣. 

相關的測試工具 
OpenSTA 
主要做性能測試的負荷及壓力測試，使用比較方便，可以編寫測試腳本，也可以先行自動生成測試腳本，而後對於應用測試腳本進行測試。 
SAINT 
網站安全性測試，能夠對於指定網站進行安全性測試，並可以提供安全問題的解決方案。 
CSE HTML Validator 
一個有用的對於HTML代碼進行合法性檢查的工具 
Ab(Apache Bench) 
Apache自帶的對於性能測試方面的工具，功能不是很多，但是非常實用。 
Crash-me 
Mysql自帶的測試數據庫性能的工具，能夠測試多種數據庫的性能。