再次總結

　　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/images"。然後在瀏覽器地址欄中手工輸入該路徑，發現該站點所有圖片的列表。這可能沒什麼關係。我進入下一級目錄 "…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 頁面質量有很高的期望。在很多情況下，就像業務功能一樣，頁面用於維護和發展公共關係，所以第一印象非常重要。