網站測試的主要方法

 

1、功能測試

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

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、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要進行驗證。

5、數據庫測試

　　在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，可使用SQL對信息進行處理。

　　在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。

2、性能測試

　　網站的性能測試對於網站的運行而言異常重要，可是目前對於網站的性能測試作的不夠，咱們在進行系統設計時也沒有一個很好的基準能夠參考，於是創建網站的性能測試的一整套的測試方案將是相當重要的。

　　網站的性能測試主要從三個方面進行：鏈接速度測試、負荷測試(Load)和壓力測試(Stress),

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

1、鏈接速度測試

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

　　另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。

2、負載測試

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

3、壓力測試

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

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

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

　　採用的測試工具：

　　性能測試能夠採用相應的工具進行自動化測試，咱們目前採用以下工具

ab -----Apache 的測試工具

OpenSTA—開發系統測試架構

 

3、接口測試

　　在不少狀況下，web 站點不是孤立。Web 站點可能會與外部服務器通信，請求數據、

　　驗證數據或提交訂單。

1、 服務器接口

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

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

2、 外部接口

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

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

3、錯誤處理

　　最容易被測試人員忽略的地方是接口錯誤處理。一般咱們試圖確認系統可以處理全部錯

　　誤，但卻沒法預期系統全部可能的錯誤。嘗試在處理過程當中中斷事務，看看會發生什麼狀況?

　　訂單是否完成?嘗試中斷用戶到服務器的網絡鏈接。嘗試中斷 web 服務器到信用卡驗證服

　　務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤?是否已對信用卡進行收費?若是

　　用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致

　　電用戶進行訂單確認。

4、可用性測試

　　可用性/易用性方面目前咱們只能採用手工測試的方法進行評判，並且缺少一個很好的評判基準進行，此一方面須要你們共同討論。

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應用系統開發沒有聯繫或聯繫不多的人員)的參與，最好是最終用戶的參與。

 

5、兼容性測試

　　須要驗證應用程序能夠在用戶使用的機器上運行。若是您用戶是全球範圍的，須要測試各類操做系統、瀏覽器、視頻設置和 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的設置也不同。

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

採用測試工具：

　　經過白盒測試或者黑盒測試導出的測試用例，採用相應的工具進行測試，能夠採用OpenSTA進行測試，此測試工具能夠採用不一樣的瀏覽器進行測試。

3.視頻測試

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

4.Modem/鏈接速率測試

　　是否有這種狀況，用戶使用 28.8 modem下載一個頁面須要 10 分鐘，但測試人員在測

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

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

五、打印機測試

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

六、組合測試

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

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

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

　　那麼只需在該瀏覽器上進行測試。若是全部的人都使用 T1 專線，可能不須要測試下載施加。

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

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

　　系統能在全部機器上運行，這樣就不會限制未來的發展和變更。

6、安全測試

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

1、 目錄設置

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

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

2.登陸

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

3.Session

Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內(例如15分鐘)沒有點擊任何頁面，是否須要從新登錄才能正常使用。

4.日誌文件

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

5.加密

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

6.安全漏洞

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

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

　　工具以下

SAINT------- Security Administrator’s Integrated Network Tool

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

7、代碼合法性測試

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

一、程序代碼合法性檢查

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

二、顯示代碼合法性檢查

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

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

Javascrīpt、Css也能夠在網上下載相應的測試工具。

8、 文檔測試

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

1)完整.是否有遺漏和丟失，徹底嗎? 單獨使用是否包含所有內容

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

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

4)一致.產品功能能描述是否自相矛盾,與其餘功能有沒有衝突

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

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

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

8)可測試性.特性可否測試? 測試員創建驗證操做的測試程序是否提供足夠的信息?

二、 產品說明書用語檢查清單

1)說明。 對問題的描述一般表現爲粉飾沒有仔細考慮的功能----可歸結於前文所述的屬性.從產品說明書上找出這樣的用語,仔細審視它們在文中是怎樣使用的.產品說明書可能會爲其掩飾和開脫,也可能含糊其詞----不管是哪種狀況均可視爲軟件缺陷.

2)老是,每一種,全部,沒有,從不.若是看到此類絕對或確定的,切實認定的敘述,軟件測試員就能夠着手設計針鋒相對的案例.

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

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

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

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

7)已處理,已拒絕,已忽略,已消除.這些廉潔可能會隱藏大量須要說明的功能.

8)若是...那麼...(沒有不然).找出有"若是...那麼..."而缺乏配套的"不然"結構的陳述.想想"若是"沒有發生會怎樣.

　　相關的測試工具

OpenSTA

　　主要作性能測試的負荷及壓力測試，使用比較方便，能夠編寫測試腳本，也能夠先行自動生成測試腳本，然後對於應用測試腳本進行測試。

SAINT

　　網站安全性測試，可以對於指定網站進行安全性測試，並能夠提供安全問題的解決方案。

CSE HTML Validator

　　一個有用的對於HTML代碼進行合法性檢查的工具

Ab(Apache Bench)

Apache自帶的對於性能測試方面的工具，功能不是不少，可是很是實用。

Crash-me

Mysql自帶的測試數據庫性能的工具，可以測試多種數據庫的性能。