WEB測試方法

時間 2019-11-26

標籤 web 測試方法欄目 HTML 简体版

原文原文鏈接

WEB測試方法html

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

功能測試

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

用戶界面測試

兼容性測試

安全測試

接口測試
1
功能測試
1.1
連接測試
連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面。首先，測試全部連接是否按指示的那樣確實連接到了該連接的頁面；其次，測試所連接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。
1.2
表單測試
當用戶經過表單提交信息的時候，都但願表單能正常工做。
若是使用表單來進行在線註冊，要確保提交按鈕能正常工做，當註冊完成後應返回註冊成功的消息。若是使用表單收集配送信息，應確保程序可以正確處理這些數據，最後能讓顧客收到包裹。要測試這些程序，須要驗證服務器能正確保存這些數據，並且後臺運行的程序能正確解釋和使用這些信息。
當用戶使用表單進行用戶註冊、登錄、信息提交等操做時，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。若是表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。
1.3
數據校驗
若是系根據業務規則須要對用戶輸入進行校驗，須要保證這些校驗功能正常工做。例如，省份的字段能夠用一個有效列表進行校驗。在這種狀況下，須要驗證列表完整並且程序正確調用了該列表(例如在列表中添加一個測試值，肯定系統可以接受這個測試值)。
在測試表單時，該項測試和表單測試可能會有一些重複。
1.4
cookies測試
Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。
　若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。若是在 cookies 中保存了註冊信息，請確認該 cookie可以正常工做並且已對這些信息已經加密。若是使用 cookie 來統計次數，須要驗證次數累計正確。
1.5
數據庫測試
在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，可使用SQL對信息進行處理。
在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。
1.6
應用程序特定的功能需求
最重要的是，測試人員須要對應用程序特定的功能需求進行驗證。嘗試用戶可能進行的全部操做：新增、修改、刪除、查詢等等。這是用戶之因此使用網站的緣由，必定要確認網站能像廣告宣傳的那樣神奇。
2
性能測試
2.1
鏈接速度測試
用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。
另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。
2.2
負載壓力測試
在這裏的負載\壓力和功能測試中的不一樣,他是系統測試的內容,是基本功能已經經過後進行的.能夠在集成測試階段,亦能夠在系統測試階段進行。

使用負載測試工具進行,虛擬必定數量的用戶看一看系統的表現,是否知足定義中的指標。負載測試通常使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的內容都是編寫出測試腳本，腳本中通常包括用戶通常經常使用的功能，而後運行，得出報告。負載測試技術在各類極限狀況下對產品進行測試 (如不少人同時使用該軟件，或者反覆運行該軟件)，以檢查產品的長期穩定性。例如，使用壓力測試工具對web服務器進行壓力測試. 本項測試能夠幫助找到一些大型的問題，如死機、崩損、內存泄漏等，由於有些存在內存泄漏問題的程序，在運行一兩次時可能不會出現問題，可是若是運行了成千上萬次，內存泄漏得愈來愈多，就會致使系統崩滑。
3
用戶界面測試

界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。並且設計良好的界面可以引導用戶本身完成相應的操做，起到嚮導的做用。同時界面如同人的面孔，具備吸引用戶的直接優點。設計合理的界面能給用戶帶來輕鬆愉悅的感覺和成功的感受，相反因爲界面設計的失敗，讓用戶有挫敗感，再實用強大的功能均可能在用戶的畏懼與放棄中付諸東流。目前界面的設計引發軟件設計人員的重視的程度還遠遠不夠，直到最近網頁製做的興起，才受到專家的青睞。並且設計良好的界面因爲須要具備藝術美的天賦而遭拒絕。
3.1
窗口：

窗口是否基於相關的輸入和菜單命令適當地打開？

窗口可否改變大小、移動和滾動？
窗口中的數據內容可否用鼠標、功能鍵、方向鍵和鍵盤訪問？

當被覆蓋並從新調用後，窗口可否正確地再生？
須要時可否使用全部窗口相關的功能？
全部窗口相關的功能是可操做的嗎？
是否有相關的下拉式菜單、工具條、滾動條、對話框、按鈕、圖標和其餘控制可爲窗口使用，並適當地顯示？
顯示多個窗口時，窗口的名稱是否被適當地表示？
活動窗口是否被適當地加亮？
若是使用多任務，是否全部的窗口被實時更新？
屢次或不正確按鼠標是否會致使沒法預料的反作用？
窗口的聲音和顏色提示和窗口的操做順序是否符合需求？
窗口是否正確地被關閉？
3.2

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 的分辨率模式下是否顯示正常? 字體是否過小以致於沒法瀏覽? 或者是太大? 文本和圖片是否對齊?
5

安全測試
主要是測試系統在沒有受權的狀況下，內部或者外部用戶對系統進行攻擊或者惡意破壞時如何進行處理，是否仍能保證數據的安全。測試人員能夠學習一些黑客技術，來對系統進行攻擊。
5.1
登陸
有些站點須要用戶進行登陸，以驗證他們的身份。這樣對用戶是方便的，他們不須要每次都輸入我的資料。你須要驗證系統阻止非法的用戶名/口令登陸，而可以經過有效登陸。用戶登陸是否有次數限制? 是否限制從某些 IP 地址登陸? 若是容許登陸失敗的次數爲3，你在第三次登陸的時候輸入正確的用戶名和口令，能經過驗證嗎? 口令選擇有規則限制嗎?
是否能夠不登錄而直接瀏覽某個頁面？
Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。
6
接口測試
數據通常經過接口輸入和輸出，因此接口測試是白盒測試的第一步。每一個接口可能有多個輸入參數，每一個參數有「典型值」、「邊界值」、「異常值」之分，因此輸入的組合數可能並很多。根據接口的定義，能夠推斷某種輸入應當產生什麼樣的輸出。輸出包括函數的返回值和輸出參數。若是實際輸出與指望的輸出不一致，那麼說明程序有錯誤。
6.1
服務器接口
第一個須要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，而後查看服務器記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還能夠查詢數據庫，確認事務數據已正確保存。
6.2
外部接口
有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減小欺詐行爲的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。
6.3
錯誤處理
最容易被測試人員忽略的地方是接口錯誤處理。一般咱們試圖確認系統可以處理全部錯誤，但卻沒法預期系統全部可能的錯誤。嘗試在處理過程當中中斷事務，看看會發生什麼狀況？訂單是否完成？嘗試中斷用戶到服務器的網絡鏈接。嘗試中斷 web 服務器到信用卡驗證服務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤？是否已對信用卡進行收費？若是用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致電用戶進行訂單確認。
7
測試點
7.1
文本框的測試
測試方法：
　a,輸入正常的字母或數字。
　b,輸入已存在的文件的名稱；
　c,輸入超長字符。例如在「名稱」框中輸入超過容許邊界個數的字符，假設最多255個字符，嘗試輸入 256個字符，檢查程序可否正確處理；
　d,輸入默認值，空白，空格；
　e,若只容許輸入字母，嘗試輸入數字；反之；嘗試輸入字母；
　f,利用複製，粘貼等操做強制輸入程序不容許的輸入數據；
　g,輸入特殊字符集，例如，NUL及\n等；
　h,輸入超過文本框長度的字符或文本，檢查所輸入的內容是否正常顯示；
　i,輸入不符合格式的數據，檢查程序是否正常校驗，如，程序要求輸入年月日格式爲yy/mm/dd，實際輸入yyyy/mm/dd，程序應該給出錯誤提示
7.2
命令按鈕測試web