Web測試

一、功能測試

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

　　1、連結測試

　　連結是Web應用系統的一個主要特征，它是在頁面之間切換和指導使用者去一些不知道位址的頁面的主要手段。連結測試可分為三個方面：

　　1)測試所有連結是否按訓示的那樣确實連結到了該連結的頁面;

　　2)測試所連結的頁面是否存在;

　　3)保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連結指向該頁面，隻有知道正确的URL位址才能通路。

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

　　2、表單測試

　　當使用者給Web應用系統管理者送出資訊時，就需要使用表單操作，例如使用者注冊、登陸、資訊送出等。在這種情況下，我們必須測試送出操作的完整性，以校驗送出給伺服器的資訊的正确性。例如：使用者填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否比對等。如果使用了預設值，還要檢驗預設值的正确性。如果表單隻能接受指定的某些值，則也要進行測試。例如：隻能接受某些字元，測試時可以跳過這些字元，看系統是否會報錯。

　　要測試這些程式，需要驗證伺服器能正确儲存這些資料，而且背景運作的程式能正确解釋和使用這些資訊。

　　B/S結構實作的功能可能主要的就在這裡，送出資料，處理資料等如果有固定的操作流程可以考慮自動化測試工具的錄制功能，編寫可重複使用的腳本代碼，可以在測試、回歸測試時運作以便減輕測試人員工作量。

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

　　3、Cookies測試

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

　　如果Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工作而且對這些資訊已經加密。測試的内容可包括Cookies是否起作用，是否按預定的時間進行儲存，重新整理對Cookies有什麼影響等。

　　4、設計語言測試

　　Web設計語言版本的差異可以引起用戶端或伺服器端嚴重的問題，例如使用哪種版本的HTML等。當在分布式環境中開發時，開發人員都不在一起，這個問題就顯得尤為重要。除了HTML的版本問題外，不同的腳本語言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或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應用系統崩潰，接着當系統重新啟動時獲得存取權。壓力測試的區域包括表單、登陸和其他資訊傳輸頁面等。

三、接口測試

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

　　驗證資料或送出訂單。

　　1、 伺服器接口

　　第一個需要測試的接口是浏覽器與伺服器的接口。測試人員送出事務，然後檢視伺服器

　　記錄，并驗證在浏覽器上看到的正好是伺服器上發生的。測試人員還可以查詢資料庫，确認事務資料已正确儲存。

　　2、 外部接口

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

　　為的發生。測試的時候，要使用 web 接口發送一些事務資料，分别對有效信用卡、無效信用卡和被盜信用卡進行驗證。如果商店隻使用 Visa 卡和 Mastercard 卡， 可以嘗試使用 Discover 卡的資料。(簡單的用戶端腳本能夠在送出事務之前對代碼進行識别，例如 3 表示 AmericanExpress，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應用系統提供資訊的正确性、準确性和相關性。

　　資訊的正确性是指資訊是可靠的還是誤傳的。例如，在商品價格清單中，錯誤的價格可能引起财政問題甚至導緻法律糾紛;資訊的準确性是指是否有文法或拼寫錯誤。這種測試通常使用一些文字處理軟體來進行，例如使用MicrosoftWord的"拼音與文法檢查"功能;資訊的相關性是指是否在目前頁面可以找到與目前浏覽資訊相關的資訊清單或入口，也就是一般Web站點中的所謂"相關文章清單"。

　　4、整體界面測試

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

　　對整體界面的測試過程，其實是一個對最終使用者進行調查的過程。一般Web應用系統采取在首頁上做一個調查問卷的形式，來得到最終使用者的回報資訊。

　　對所有的可用性測試來說，都需要有外部人員(與Web應用系統開發沒有聯系或聯系很少的人員)的參與，最好是最終使用者的參與。

五、相容性測試

　　需要驗證應用程式可以在使用者使用的機器上運作。如果您使用者是全球範圍的，需要測試各種作業系統、浏覽器、視訊設定和modem 速度。最後，還要嘗試各種設定的組合。

1、平台測試

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

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

2、浏覽器測試

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

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

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 NetworkTool

　　此工具能夠測出網站系統的相應的安全問題，并且能夠給出安全漏洞的解決方案，不過是一些較為常見的漏洞解決方案。

七、代碼合法性測試

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

　　1、程式代碼合法性檢查

　　程式代碼合法性檢查主要标準為《intergrp小組程式設計規範》，目前采用由SCM管理者進行規範的檢查，未來期望能夠有相應的工具進行測試。

　　2、顯示代碼合法性檢查

　　顯示代碼的合法性檢查，主要分為Html、Javascrīpt、Css代碼檢查，目前采用

　　HTML代碼檢查------采用CSE HTML Validator進行測試

　　Javascrīpt、Css也可以在網上下載下傳相應的測試工具。

八、 文檔測試

　　l、産品說明書屬性檢查清單

　　1)完整.是否有遺漏和丢失，完全嗎? 單獨使用是否包含全部内容

　　2)準确.既定解決方案正确嗎? 目标明确嗎? 有沒有錯誤?

　　3)精确、不含糊、清晰.描述是否一清二楚? 還是自說自話?容易看懂和了解嗎?

　　4)一緻.産品功能能描述是否自相沖突,與其他功能有沒有沖突

　　5)貼切.描述功能的陳述是否必要?有沒有多餘資訊? 功能是否原來的客戶要求?

　　6)合理.在特定的預算和進度下,以現有人力,物力和資源能否實作?

　　7)代碼無關.是否堅持定義産品,而不是定義其所信賴的軟體設計,架構和代碼

　　8)可測試性.特性能否測試? 測試員建立驗證操作的測試程式是否提供足夠的資訊?

　　2、 産品說明書用語檢查清單

　　1)說明。 對問題的描述通常表現為粉飾沒有仔細考慮的功能----可歸結于前文所述的屬性.從産品說明書上找出這樣的用語,仔細審視它們在文中是怎樣使用的.産品說明書可能會為其掩飾和開脫,也可能含糊其詞----無論是哪一種情況都可視為軟體缺陷.

　　2)總是,每一種,所有,沒有,從不.如果看到此類絕對或肯定的,切實認定的叙述,軟體測試員就可以着手設計針鋒相對的案例.

　　3)當然,是以,明顯,顯然,必然.這些話意圖誘使接受假定情況.不要中了圈套.

　　4)某些,有時,常常,通常,慣常,經常,大多,幾乎.這些話太過模糊."有時"發生作用的功能無法測試.

　　5)等等,諸如此類,依此類推.以這樣的詞結束的功能清單無法測試.功能清單要絕對或者解釋明确,以免讓人迷惑,不知如何推論.

　　6)良好,迅速,廉價,高效,小,穩定.這些是不确定的說法,不可測試.如果在産品說明書中出現,就必須進一步指明含義.