web測試計劃（流程）

一．概要

1 目的

本文件編寫目的在於規範基於網站的系統測試，區別於傳統的軟體測試，本文對網站測試的流程與規範進行全面概述，以利於網站開發工作的質量和開發時間，幫助測試人員快速瞭解測試流程，進行測試活動。

2 適用範圍

適用於所有基於WEB的網站測試的專案。

3 網站測試的簡要說明

網站的開發與部署是為更多更廣泛的使用者提供資訊服務，其針對性廣、適用性強，故其效能要求與傳統的軟體不同，其系統的測試也與傳統的軟體測試不同。它不僅需要驗證系統各個模組的功能是否與使用者需求符合，還要測試系統在不同軟硬體平臺和不同的瀏覽器端的相容性問題。還有使用者的安全性和可用性測試。

Web網站的特點：網路集約型、內容驅動性、持續演化性、即時性、安全性、美觀性。

二．基本流程

1．專案立項

專案立項階段是使用者與專案經理針對專案進行敲定，確定專案雙方的職能及相關責任。在此過程中測試人員很多時候都不怎麼會參與進來，其實測試經理或組長是可以以參與者的身份參與進來，瞭解專案的相關事宜。

2.需求分析階段

需求分析階段測試人員對業務關係進行了解，分析需求點。很多測試人員的測試工作都是從這一階段開始。需求分析評審對專案需求分析的結果進行評審，評審團根據公司人員分配來定，一般包含使用者、專案經理、開發人員、測試人員等，不要低於5人。

3.測試計劃階段

測試計劃階段：測試組長就要根據《使用者需求手冊》或《測試需求分析書》開始編寫《測試計劃》，其中包括人員，軟體硬體資源，測試點，整合順序，進度安排和風險識別等內容。評審團根據公司人員分配來定，一般應包含專案經理、測試人員等，不要低於5人。

4.測試設計階段

此階段要對測試工作提出測試方案，測試方案一般由對需求很熟的高資深的測試工程師設計，測試方案要求根據《需求分析》和《測試計劃》上的每個需求點設計出包括需求點簡介，測試思路和詳細測試方法三部分的方案。《測試方案》編寫完成後也需要進行評審。評審人員不要低於5人。

5.測試方案階段

此階段對測試進行詳細設計，主要針對測試用例和規程的設計。測試用例是根據《測試方案》來編寫的，通過測試方案階段，測試人員對整個系統需求有了詳細的理解。這時開始編寫用例才能保證用例的可執行和對需求的覆蓋。測試用例需要包括測試項，用例級別，預置條件，操作步驟和預期結果。其中操作步驟和預期結果需要編寫詳細和明確。測試用例應該覆蓋測試方案，而測試方案又覆蓋了測試需求點，這樣才能保證客戶需求不遺漏。同樣，測試用例也需要評審。評審人員最好不要低於5人。

6.測試執行階段

執行測試用例，對執行結果進行合理管理，及時提交有質量的Bug。

7.結果分析與測試報告

針對測試結果測試人員應該分析相應的結果產生原因，並提交相應的測試報告。

三．測試範圍

1. 功能測試

1.1基本功能模組測試

根據《使用者需求說明手冊》和《需求分析說明書》，分析各個功能模組。針對各個功能模組進行相關功能的測試。

1.2 WEB功能測試

1.2.1連結測試

什麼是連結？

連結是Web 網站的一個主要特徵，它是在頁面之間切換和引導使用者去一些未知地址頁面的主要手段。

連結測試的內容：

測試所有連結是否按指示的那樣確實連結到了應該連結的頁面；

測試所連結的頁面是否存在；

保證Web 網站上沒有孤立的頁面。所謂孤立頁面是指沒有連結指向該頁面，只有知道正確的URL 地址才能訪問。

連結測試可以手動進行，也可以自動進行。

連結測試必須在整合測試階段完成，也就是說，在整個Web 網站的所有頁面開發完成之後進行連結測試。

主要測試網站的連結是否正常，其中包括測試連結頁面的正確性、頁面是否存在、是否存在孤立頁面。

常用測試工具有Xenu（測試連結的正確性的工具）。

1.2.2表單測試

什麼是表單？

表單就是一些需要線上顯示和填寫的表格。

表單有一些標準操作，如確認、儲存、提交等。

主要測試表單的正確性和規範性，是否適合常用表單的使用習慣。

主要測試方法為：邊界值測試、等價類測試，以及異常類測試。

1.2.3Cookies測試

什麼是cookies？

Cookie是一個由網頁伺服器放在您硬碟上的非常小的文字檔案. 它本質上就像您的身份證明一樣，並且不能像程式碼那樣被執行或被用來散佈病毒。它只能被您使用並且只能由提供的伺服器讀取。

使用cookies的目的：

幫您節約時間。如果您自定義頁面，或註冊產品或服務。cookie記住您的身份.當下一次您再次訪問的時候，將顯示您需要的資訊，將幫您填入任何您已經回答過的問題。

Cookies測試

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

測試內容

Cookies是否能正常工作；

Cookies是否按預定的時間進行儲存；

重新整理對Cookies 有什麼影響等。

1.2.4設計語言測試

測試WEB設計語言使用的版本是否規範、是否統一，使用的指令碼語言是否規範、統一。

一般採用的時程式碼檢視法。

不同的Web 設計語言版本的差異可以引起客戶端或伺服器端嚴重的問題；

尤其在分散式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。

測試的語言，除了HTML 的版本問題外，不同的指令碼語言，例如使用Java、JavaScript、ActiveX、VBScript或Perl 等開發的應用程式也要在不同的版本上進行驗證。

1.2.5資料庫測試

資料校驗

根據業務規則，需要對使用者輸入進行校驗，則要保證這些校驗功能正常工作。

一般測試資料的一致性錯誤和輸出錯誤。資料一致性錯誤主要是由於使用者提交的表單資訊不正確而造成的，而輸出錯誤主要是由於網路速度或程式設計問題等引起的，針對這兩種情況，可分別進行測試。再就是資料的安全性測試，一般採用SQL隱碼攻擊的方法。

2．效能測試

網站的效能測試對於網站的執行而言異常重要，網站的效能測試主要從三個方面進行：連線速度測試、負載測試和壓力測試。

2.1連線速度測試

不管使用者使用那種方式的不同，系統都不能讓使用者可以等較長的時間。連線速度測試的目的，就是要保證在許可的時間內響應使用者的請求。

測試網站的連結速度，響應使用者的反應時間。

2.2負載測試

負載測試的目的：

負載測試是為了測量Web 系統在某一負載級別上的效能，以保證Web 系統在需求範圍內能正常工作。負載測試指的是進行一些邊界資料的測試，測量網站系統在某一負載級別上的效能，以保證網站系統在需求範圍內能正常工作。負載級別是某個時刻同時訪問Web系統的使用者數量。

常用自動化測試工具：LoadRunner。

2.3壓力測試

壓力測試傾向應該是致使整個系統崩潰測試出系統能承受的最大壓力而不會發生系統崩潰的現象。同時也是測試系統的限制和故障恢復能力，也就是測試網站系統會不會崩潰，在什麼情況下會崩潰。

壓力測試的內容：

壓力測試必須對 Web 服務應用以下四個基本條件進行有效的壓力測試：

重複（Repetition）；

併發（Concurrency）；

量級（Magnitude）；

隨機變化。

常用自動化測試工具：LoadRunner。

3. 可用性測試

可用性/易用性方面的測試一般採用手工測試的方法進行評判。

3.1導航測試

什麼是導航測試？

在不同的使用者介面控制之間，例如按鈕、對話方塊、列表和視窗等；

或在不同的連線頁面之間，

導航描述了使用者在一個頁面內操作的方式。

導航測試的內容：

測試網站的導航能力是否良好，比如頁面結構、導航、選單、連線等是否良好。

常採用手工對網頁進行瀏覽、根據一般使用者的瀏覽習慣來進行評判。

一般此過程讓終端使用者參與這種測試，效果將更加明顯。

導航是否直觀？

Web 系統的主要部分是否可以通過主頁訪問？

Web系統是否需要站點地圖、搜尋引擎或其他的導航器幫助？

測試Web 系統的頁面結構；

導航條、選單、連線的風格是否一致？

各種提示是否準確，確保使用者憑直覺就知道是否還有內容，內容在什麼地方。

最好讓終端使用者參與導航測試，效果將更加明顯。

3.2圖形測試

什麼是圖形測試？

在Web 網站中，適當的圖片和動畫既能起到廣告宣傳的作用，又能起到美化頁面的功能。一個Web 網站的圖形可以包括圖片、動畫、邊框、顏色、字型、背景、按鈕等。圖形測試是網頁美觀測試的一部分，一般測試圖形是否有明確的用途、是否與頁面風格一致，還用圖片的大小與格式的測試。

圖形測試的內容：

(1) 要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一起，以免浪費傳輸時間。圖片尺寸要儘量地小，並且要能清楚地說明某件事情。

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

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

(4) 圖片的大小和質量也是一個很重要的因素，一般採用JPG 或GIF 壓縮。

常採用手工測試。

3.3內容測試

內容測試用來檢驗web網站系統提供資訊的正確性、準確性和相關性。如文字標題是否與文字內容符合，是否存在不需要的文字。

常採用介面瀏覽的方式。

3.4整體介面測試

測試整個網站系統的頁面結構設計是否符合使用者需求規範，是否給使用者的一個整體感。

一般常採用介面瀏覽的方式，最好是有終端使用者的參與。

例如，當使用者瀏覽Web 網站時，應考慮

是否感到舒適？

是否憑直覺就知道要找的資訊在什麼地方？

整個Web 應用系統的設計風格是否一致？

4. 安全性測試

4.1登入驗證

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

4.2緩衝區溢位

溢位攻擊是通過溢位來控制計算機的指令序列，讓計算機執行自己的惡意程式碼，是利用緩衝區溢位漏洞所進行的攻擊行動。緩衝區溢位是一種非常普遍、非常危險的漏洞。

4.3日誌檔案

為了保證網站系統的安全性，日誌檔案是至關重要的。需要測試相關資訊是否寫進了日誌檔案、是否可追蹤。

4.4安全漏洞

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

4.5跨站式指令碼攻擊（XSS）

跨站指令碼攻擊是指攻擊者編寫惡意指令碼利用網站漏洞從使用者那裡惡意盜取資訊。

4.6 目錄測試

4.7 SSL套接字測試

5. 配置和相容性測試

5.1平臺測試

採用不同的作業系統平臺對網站進行測試。

市場上有很多不同的作業系統型別，最常見的有Windows、Unix、Macintosh、Linux 等。Web 網站的終端使用者究竟使用哪一種作業系統，取決於使用者系統的配置。

平臺測試就是要測試相容性問題：

同一個應用可能在某些作業系統下能正常執行，但在另外的作業系統下可能會執行失敗。

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

5.2瀏覽器測試

使用不同的瀏覽器對網站進行瀏覽測試，檢視網站在不同瀏覽器中的相容性問題。

瀏覽器是Web系統客戶端最核心的軟體，來自不同廠商的瀏覽器對Java，、JavaScript、ActiveX、plug-ins 或不同的HTML 有不同的支援。

另外，框架和層次結構風格在不同的瀏覽器中也有不同的顯示，甚至根本不能顯示。不同的瀏覽器對安全性和Java 的設定也不一樣。

5.3解析度測試

對螢幕的解析度進行調節來檢視網站在不同解析度下的顯示效果，比如；解析度低時介面文字顯示太大，而

解析度高時又有些文字顯示時太小。

頁面版式在640x400、600x800 或1024x768 的

解析度模式下是否顯示正常?

5.4 連線速率測試

是否有這種情況，使用者使用28.8k modem 下載一個頁面需要10 分鐘，但測試人員在測試的時候使用的是T1 專線?

使用者在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。

5.5 組合測試

600x800 的解析度在MAC 機上可能不錯，但是在IBM 相容機上卻很難看。

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

如果所有的人都使用T1 專線，可能不需要測試下載、上載。

有些內部應用程式，開發部門可能在系統需求中宣告不支援某些系統而只支援一些那些已設定的系統。

理想的情況，系統能在所有機器上執行。

四．相關規範

1. 文件管理規範

2.相關管理工具

（注：該文章是網上一篇測試流程的文章上補充完成，對某些部分給予了詳細的說明，在此謝謝該篇文章的初建者）