主噴WEB測試

在Web工程過程當中，基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工做。基於Web的系統測試與傳統的軟件測試不一樣，它不但須要檢查和驗證是否按照設計的要求運行，並且還要測試系統在不一樣用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。然而，Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。所以，咱們必須爲測試和評估複雜的基於Web的系統研究新的方法和技術。
本文將 web 測試分爲 6 個部分：

1.     功能測試

2.       性能測試（包括負載/壓力測試）

3.       用戶界面測試

4.       兼容性測試
5.       安全測試
6.       接口測試 

本文的目的是覆蓋 web 測試的各個方面，未就某一主題進行深刻說明。
1 功能測試
1.1 連接測試
連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面。首先，測試全部連接是否按指示的那樣確實連接到了該連接的頁面；其次，測試所連接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。 
連接測試能夠自動進行，如今已經有許多工具能夠採用。連接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的全部頁面開發完成以後進行連接測試。
採起措施：採用自動檢測網站連接的軟件來進行。
推薦軟件：
Xenu Link Sleuth 免費 綠色免安裝軟件
HTML Link Validator 共享（30天試用）
1.2 表單測試 
當用戶經過表單提交信息的時候，都但願表單能正常工做。
如 果使用表單來進行在線註冊，要確保提交按鈕能正常工做，當註冊完成後應返回註冊成功的消息。若是使用表單收集配送信息，應確保程序可以正確處理這些數據， 最後能讓顧客能讓客戶收到包裹。要測試這些程序，須要驗證服務器能正確保存這些數據，並且後臺運行的程序能正確解釋和使用這些信息。
當 用戶使用表單進行用戶註冊、登錄、信息提交等操做時，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業 是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。若是表單只能接受指定的某些值，則也要進行測試。例如：只能 接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。
1.3 數據校驗
若是系根據業務規則須要對用戶輸入進行校驗，須要保證這些校驗功能正常工做。例如，省份的字段能夠用一個有效列表進行校驗。在這種狀況下，須要驗證列表完整並且程序正確調用了該列表(例如在列表中添加一個測試值，肯定系統可以接受這個測試值)。
在測試表單時，該項測試和表單測試可能會有一些重複。
1.2和1.3的採起措施：第一個完整的版本採用手動檢查，同時造成WinRunner（QTP）腳本；迴歸測試以及升級版本主要靠WinRunner（QTP）自動回放測試。
1.4 cookies測試
Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。 
  若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。若是在 cookies 中保存了註冊信息，請確認該 cookie可以正常工做並且已對這些信息已經加密。若是使用 cookie 來統計次數，須要驗證次數累計正確。
採起措施：
     1 採用黑盒測試：採用上面提到的方法進行測試
2 採用查看cookies的軟件進行（初步的想法）
能夠選擇採用的軟件
IECookiesView v1.50 
Cookies Manager v1.1
1.5 數據庫測試
在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，可使用SQL對信息進行處理。
在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。
採起措施：暫時沒有更好的測試方法
     考慮結合到1.2和1.3的測試中
1.6 應用程序特定的功能需求
最重要的是，測試人員須要對應用程序特定的功能需求進行驗證。嘗試用戶可能進行的全部操做：下訂單、更改訂單、取消訂單、覈對訂單狀態、在貨物發送以前更改送貨信息、在線支付等等。這是用戶之因此使用網站的緣由，必定要確認網站能像廣告宣傳的那樣神奇。
採起措施：深入理解需求說明文檔
1.7 設計語言測試 
Web設計語言版本的差別能夠引發客戶端或服務器端嚴重的問題，例如使用哪一種版本的HTML等。當在分佈式環境中開發時，開發人員都不在一塊兒，這個問題就顯得尤其重要。除了HTML的版本問題外，不一樣的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。
暫時沒有方法測試，能夠多參考一點討論組內的更新信息

2 性能測試 
2.1 鏈接速度測試
用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。 
另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。 
2.2 負載測試 
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？ 
2.3 壓力測試
負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。 
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。***經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。
壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。
負載/壓力測試應該關注什麼
測試須要驗證系統可否在同一時間響應大量的用戶，在用戶傳送大量數據的時候可否響應，系統可否長時間運行。可訪問性對用戶來講是極其重要的。若是用戶獲得「系統忙」的信息，他們可能放棄，並轉向競爭對手。系統檢測不只要使用戶可以正常訪問站點，在不少狀況下，可能會有***試圖經過發送大量數據包來***服務器。出於安全的緣由，測試人員應該知道當系統過載時，須要採起哪些措施，而不是簡單地提高系統性能。
瞬間訪問高峯
若是您的站點用於公佈×××的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內可以響應上百萬的請求。負載測試工具可以模擬 X 個用戶同時訪問測試站點。
每一個用戶傳送大量數據
網上書店的多數用戶可能只訂購 1-5 書，可是大學書店可能會訂購 5000 本有關心理學介紹的課本? 或者一個祖母爲她的 50 個兒孫購買聖誕禮物(固然每一個孩子都有本身的郵件地址) 系統能處理單個用戶的大量數據嗎?
長時間的使用
若是站點用於處理鮮花訂單，那麼至少但願它在母親節前的一週內能持續運行。若是站點提供基於 web 的 email 服務，那麼點最好能持續運行幾個月，甚至幾年。可能須要使用自動測試工具來完成這種類型的測試，由於很難經過手工完成這些測試。你能夠想象組織100 我的同時點擊某個站點。可是同時組織 100000 我的呢。一般，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。並且，測試工具安裝完成以後，再次使用的時候，只要點擊幾下。
採起措施：採用測試工具WAS、ACT協助進行測試

3 用戶界面測試 
3.1 導航測試 
導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？
在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。 
導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。 
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。 
3.2 圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有： 
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。
（2）驗證全部頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮，最好能使圖片的大小減少到 30k 如下
（5）最後，須要驗證的是文字迴繞是否正確。若是說明文字指向右邊的圖片，應該確保該圖片出如今右邊。不要由於使用圖片而使窗口和段落排列古怪或者出現孤行。
一般來講，使用少量或儘可能不使用背景是個不錯的選擇。若是您想用背景，那麼最好使用單色的，和導航條一塊兒放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。
3.3內容測試 
內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。
信息的正確性是指信息是可靠的仍是誤傳的。例如，在商品價格列表中，錯誤的價格可能引發財政問題甚至致使法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試一般使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關性是指是否在當前頁面能夠找到與當前瀏覽信息相關的信息列表或入口，也就是通常Web站點中的所謂"相關文章列表"。
對 於開發人員來講，可能先有功能而後纔對這個功能進行描述。你們坐在一塊兒討論一些新的功能，而後開始開發，在開發的時候，開發人員可能不注重文字表達，他們 添加文字可能只是爲了對齊頁面。不幸的是，這樣出來的產品可能產生嚴重的誤解。所以測試人員和公關部門一塊兒檢查內容的文字表達是否恰當。不然，公司可能陷 入麻煩之中，也可能引發法律方面的問題。測試人員應確保站點看起來更專業些。過度地使用粗體字、大字體和下劃線可能會讓用戶感到不舒服。在進行用戶可用性 方面的測試時，最好先請圖形設計專家對站點進行評估。你可能不但願看到一篇處處是黑體字的文章，因此相信您也但願本身的站點能更專業一些。最後，須要肯定 是否列出了相關站點的連接。不少站點但願用戶將郵件發到一個特定的地址，或者從某個站點下載瀏覽器。可是若是用戶沒法點擊這些地址，他們可能會以爲很迷 惑。
3.4 表格測試 
須要驗證表格是否設置正確。用戶是否須要向右滾動頁面才能看見產品的價格？把價格放在左邊，而把產品細節放在右邊是否更有效? 每一欄的寬度是否足夠寬，表格裏的文字是否都有折行？是否有由於某一格的內容太多，而將整行的內容拉長?
3.5 總體界面測試 
總體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個總體感。例如：當用戶瀏覽Web應用系統時是否感到溫馨，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？ 
對總體界面的測試過程，實際上是一個對最終用戶進行調查的過程。通常Web應用系統採起在主頁上作一個調查問卷的形式，來獲得最終用戶的反饋信息。
對全部的用戶界面測試來講，都須要有外部人員（與Web應用系統開發沒有聯繫或聯繫不多的人員）的參與，最好是最終用戶的參與。
採起措施：手動測試，參與人員最好有外部人員

4 兼容性測試 
4.1 平臺測試
市場上有不少不一樣的操做系統類型，最多見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪種操做系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操做系統下能正常運行，但在另外的操做系統下可能會運行失敗。 
所以，在Web系統發佈以前，須要在各類操做系統下對Web系統進行兼容性測試。 
4.2 瀏覽器測試 
瀏覽器是Web客戶端最核心的構件，來自不一樣廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不一樣的HTML規格有不一樣的支持。例如，ActiveX是Microsoft的產品，是爲Internet Explorer而設計的，JavaScript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不一樣的瀏覽器中也有不一樣的顯示，甚至根本不顯示。不一樣的瀏覽器對安全性和Java的設置也不同。
測試瀏覽器兼容性的一個方法是建立一個兼容性矩陣。在這個矩陣中，測試不一樣廠商、不一樣版本的瀏覽器對某些構件和設置的適應性。 
4.3 分辨率測試
頁面版式在 640x400、600x800 或 1024x768 的分辨率模式下是否顯示正常? 字體是否過小以致於沒法瀏覽? 或者是太大? 文本和圖片是否對齊?
4.4 Modem/鏈接速率
是否有這種狀況，用戶使用 28.8 modem下載一個頁面須要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最後，須要確認圖片不會太大。
4.5 打印機
用 戶可能會將網頁打印下來。所以網也在設計的時候要考慮到打印問題，注意節約紙張和油墨。有很多用戶喜歡閱讀而不是盯着屏幕，所以須要驗證網頁打印是否正 常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不同。測試人員至少須要驗證訂單確認頁面打印是正常的。
4.6 組合測試
最後須要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，可是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻沒法使用 Lynx 來瀏覽。若是是內部使用的 web 站點，測試可能會輕鬆一些。若是公司指定使用某個類型的瀏覽器，那麼只需在該瀏覽器上進行測試。若是全部的人都使用 T1 專線，可能不須要測試下載施加。(但須要注意的是，可能會有員工從家裏撥號進入系統) 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。可是，理想的狀況是，系統能在全部機器上運行，這樣就不會限制未來的發展和變更。
採起措施：根據實際狀況，採起等價劃分的方法，列出兼容性矩陣

5 安全測試
即便站點不接受信用卡支付，安全問題也是很是重要的。Web 站點收集的用戶資料只能在公司內部使用。若是用戶信息被***泄露，客戶在進行交易時，就不會有安全感。
5.1 目錄設置
Web 安全的第一步就是正確設置目錄。每一個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的全部內容。我服務的一個公司沒有執行這條規則。我選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/p_w_picpaths"。而後在瀏覽器地址欄中手工輸入該路徑，發現該站點全部圖片的列表。這可能沒什麼關係。我進入下一級目錄 "…com/objects" ，點擊 jackpot。 在該目錄下有不少資料，其中引發我注意的是已過時頁面。該公司每月都要更改產品價格，而且保存過時頁面。我翻看了一下這些記錄，就能夠估計他們的邊際利 潤以及他們爲了爭取一個合同還有多大的降價空間。若是某個客戶在談判以前查看了這些信息，他們在談判桌上確定處於上風。
5.2 SSL
不少站點使用 SSL 進行安全傳送。你知道你進入一個 SSL 站點是由於瀏覽器出現了警告消息，並且在地址欄中的 HTTP 變成 HTTPS。若是開發部門使用了SSL，測試人員須要肯定是否有相應的替代頁面(適用於3.0 如下版本的瀏覽器，這些瀏覽器不支持SSL。當用戶進入或離開安全站點的時候，請確認有相應的提示信息。是否有鏈接時間限制？超過限制時間後出現什麼狀況？
5.3 登陸
有些站點須要用戶進行登陸，以驗證他們的身份。這樣對用戶是方便的，他們不須要每次都輸入我的資料。你須要驗證系統阻止非法的用戶名/口令登陸，而可以經過有效登陸。用戶登陸是否有次數限制? 是否限制從某些 IP 地址登陸? 若是容許登陸失敗的次數爲3，你在第三次登陸的時候輸入正確的用戶名和口令，能經過驗證嗎? 口令選擇有規則限制嗎?  是否能夠不登錄而直接瀏覽某個頁面？
Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。
5.4 日誌文件
在後臺，要注意驗證服務器日誌工做正常。日誌是否記全部的事務處理? 是否記錄失敗的註冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務完成的時候都進行保存? 記錄IP 地址嗎? 記錄用戶名嗎?
5.5 腳本語言
腳本語言是常見的安全隱患。每種語言的細節有所不一樣。有些腳本容許訪問根目錄。其餘只容許訪問郵件服務器，可是經驗豐富的***能夠將服務器用戶名和口令發送給他們本身。找出站點使用了哪些腳本語言，並研究該語言的缺陷。還要須要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。最好的辦法是訂閱一個討論站點使用的腳本語言安全性的新聞組。 

6 接口測試
在不少狀況下，web 站點不是孤立。Web 站點可能會與外部服務器通信，請求數據、驗證數據或提交訂單。
6.1服務器接口
第一個須要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，而後查看服務器記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還能夠查詢數據庫，確認事務數據已正確保存。
這種測試能夠歸到功能測試中的表單測試和數據校驗測試中
6.2 外部接口
有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減小欺詐行爲的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。若是商店只使用 Visa 卡和 Mastercard 卡， 能夠嘗試使用 Discover 卡的數據。(簡單的客戶端腳本可以在提交事務以前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。)一般，測試人員須要確認軟件可以處理外部服務器返回的全部可能的消息。
這種狀況在遠程抄表中可能會體現到
6.3 錯誤處理
最容易被測試人員忽略的地方是接口錯誤處理。一般咱們試圖確認系統可以處理全部錯誤，但卻沒法預期系統全部可能的錯誤。嘗試在處理過程當中中斷事務，看看會發生什麼狀況？訂單是否完成？嘗試中斷用戶到服務器的網絡鏈接。嘗試中斷 web 服務器到信用卡驗證服務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤？是否已對信用卡進行收費？若是用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致電用戶進行訂單確認。
採起措施：在理解需求的基礎上，充分發揮想象力，儘可能比較全面的列出各類異常狀況。

7 結論
   不管你在測試 internet、intranet 或者是 extranet 應用程序，web 測試相對於非 web 測試來講都是更具挑戰性的工做。用戶對 web 頁面質量有很高的指望。在不少狀況下，就像業務功能同樣，頁面用於維護和發展公共關係，因此第一印象很是重要。