Web測試方法大全

時間：2023-05-07 06:18:01 | 來源：網(wǎng)站運營

時間：2023-05-07 06:18:01 來源：網(wǎng)站運營

Web測試方法大全：在Web工程過程中，基于Web系統(tǒng)的測試、確認(rèn)和驗收是一項重要而富有挑戰(zhàn)性的工作?；赪eb的系統(tǒng)測試與傳統(tǒng)的軟件測試不同，它不但需要檢查和驗證是否按照設(shè)計的要求運行，而且還要測試系統(tǒng)在不同用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進(jìn)行安全性和可用性測試。然而，Internet和Web媒體的不可預(yù)見性使測試基于Web的系統(tǒng)變得困難。因此，我們必須為測試和評估復(fù)雜的基于Web的系統(tǒng)研究新的方法和技術(shù)。

本文將 web 測試分為 6 個部分：




功能測試




性能測試（包括負(fù)載/壓力測試）




用戶界面測試




兼容性測試




安全測試




接口測試

1

功能測試

1.1

鏈接測試

鏈接是Web應(yīng)用系統(tǒng)的一個主要特征，它是在頁面之間切換和指導(dǎo)用戶去一些不知道地址的頁面的主要手段。鏈接測試可分為三個方面。首先，測試所有鏈接是否按指示的那樣確實鏈接到了該鏈接的頁面；其次，測試所鏈接的頁面是否存在；最后，保證Web應(yīng)用系統(tǒng)上沒有孤立的頁面，所謂孤立頁面是指沒有鏈接指向該頁面，只有知道正確的URL地址才能訪問。

1.2

表單測試

當(dāng)用戶通過表單提交信息的時候，都希望表單能正常工作。

如果使用表單來進(jìn)行在線注冊，要確保提交按鈕能正常工作，當(dāng)注冊完成后應(yīng)返回注冊成功的消息。如果使用表單收集配送信息，應(yīng)確保程序能夠正確處理這些數(shù)據(jù)，最后能讓顧客收到包裹。要測試這些程序，需要驗證服務(wù)器能正確保存這些數(shù)據(jù)，而且后臺運行的程序能正確解釋和使用這些信息。

當(dāng)用戶使用表單進(jìn)行用戶注冊、登陸、信息提交等操作時，我們必須測試提交操作的完整性，以校驗提交給服務(wù)器的信息的正確性。例如：用戶填寫的出生日期與職業(yè)是否恰當(dāng)，填寫的所屬省份與所在城市是否匹配等。如果使用了默認(rèn)值，還要檢驗?zāi)J(rèn)值的正確性。如果表單只能接受指定的某些值，則也要進(jìn)行測試。例如：只能接受某些字符，測試時可以跳過這些字符，看系統(tǒng)是否會報錯。

1.3

數(shù)據(jù)校驗

如果系根據(jù)業(yè)務(wù)規(guī)則需要對用戶輸入進(jìn)行校驗，需要保證這些校驗功能正常工作。例如，省份的字段可以用一個有效列表進(jìn)行校驗。在這種情況下，需要驗證列表完整而且程序正確調(diào)用了該列表(例如在列表中添加一個測試值，確定系統(tǒng)能夠接受這個測試值)。

在測試表單時，該項測試和表單測試可能會有一些重復(fù)。

1.4

cookies測試

Cookies通常用來存儲用戶信息和用戶在某應(yīng)用系統(tǒng)的操作，當(dāng)一個用戶使用Cookies訪問了某一個應(yīng)用系統(tǒng)時，Web服務(wù)器將發(fā)送關(guān)于用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來創(chuàng)建動態(tài)和自定義頁面或者存儲登陸等信息。

　如果Web應(yīng)用系統(tǒng)使用了Cookies，就必須檢查Cookies是否能正常工作。測試的內(nèi)容可包括Cookies是否起作用，是否按預(yù)定的時間進(jìn)行保存，刷新對Cookies有什么影響等。如果在 cookies 中保存了注冊信息，請確認(rèn)該 cookie能夠正常工作而且已對這些信息已經(jīng)加密。如果使用 cookie 來統(tǒng)計次數(shù)，需要驗證次數(shù)累計正確。

1.5

數(shù)據(jù)庫測試

在Web應(yīng)用技術(shù)中，數(shù)據(jù)庫起著重要的作用，數(shù)據(jù)庫為Web應(yīng)用系統(tǒng)的管理、運行、查詢和實現(xiàn)用戶對數(shù)據(jù)存儲的請求等提供空間。在Web應(yīng)用中，最常用的數(shù)據(jù)庫類型是關(guān)系型數(shù)據(jù)庫，可以使用SQL對信息進(jìn)行處理。

在使用了數(shù)據(jù)庫的Web應(yīng)用系統(tǒng)中，一般情況下，可能發(fā)生兩種錯誤，分別是數(shù)據(jù)一致性錯誤和輸出錯誤。數(shù)據(jù)一致性錯誤主要是由于用戶提交的表單信息不正確而造成的，而輸出錯誤主要是由于網(wǎng)絡(luò)速度或程序設(shè)計問題等引起的，針對這兩種情況，可分別進(jìn)行測試。

1.6

應(yīng)用程序特定的功能需求

最重要的是，測試人員需要對應(yīng)用程序特定的功能需求進(jìn)行驗證。嘗試用戶可能進(jìn)行的所有操作：新增、修改、刪除、查詢等等。這是用戶之所以使用網(wǎng)站的原因，一定要確認(rèn)網(wǎng)站能像廣告宣傳的那樣神奇。

2

性能測試

2.1

連接速度測試

用戶連接到Web應(yīng)用系統(tǒng)的速度根據(jù)上網(wǎng)方式的變化而變化，他們或許是電話撥號，或是寬帶上網(wǎng)。當(dāng)下載一個程序時，用戶可以等較長的時間，但如果僅僅訪問一個頁面就不會這樣。如果Web系統(tǒng)響應(yīng)時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，如果響應(yīng)速度太慢，用戶可能還沒來得及瀏覽內(nèi)容，就需要重新登陸了。而且，連接速度太慢，還可能引起數(shù)據(jù)丟失，使用戶得不到真實的頁面。

2.2

負(fù)載壓力測試

在這里的負(fù)載/壓力和功能測試中的不同,他是系統(tǒng)測試的內(nèi)容,是基本功能已經(jīng)通過后進(jìn)行的.可以在集成測試階段,亦可以在系統(tǒng)測試階段進(jìn)行。




使用負(fù)載測試工具進(jìn)行,虛擬一定數(shù)量的用戶看一看系統(tǒng)的表現(xiàn),是否滿足定義中的指標(biāo)。負(fù)載測試一般使用工具完成，loadrunner，webload，was，ewl，e-test等，主要的內(nèi)容都是編寫出測試腳本，腳本中一般包括用戶一般常用的功能，然后運行，得出報告。負(fù)載測試技術(shù)在各種極限情況下對產(chǎn)品進(jìn)行測試 (如很多人同時使用該軟件，或者反復(fù)運行該軟件)，以檢查產(chǎn)品的長期穩(wěn)定性。例如，使用壓力測試工具對web服務(wù)器進(jìn)行壓力測試. 本項測試可以幫助找到一些大型的問題，如死機、崩損、內(nèi)存泄漏等，因為有些存在內(nèi)存泄漏問題的程序，在運行一兩次時可能不會出現(xiàn)問題，但是如果運行了成千上萬次，內(nèi)存泄漏得越來越多，就會導(dǎo)致系統(tǒng)崩滑。

3

用戶界面測試




界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設(shè)計良好的界面能夠引導(dǎo)用戶自己完成相應(yīng)的操作，起到向?qū)У淖饔谩Ｍ瑫r界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。設(shè)計合理的界面能給用戶帶來輕松愉悅的感受和成功的感覺，相反由于界面設(shè)計的失敗，讓用戶有挫敗感，再實用強大的功能都可能在用戶的畏懼與放棄中付諸東流。目前界面的設(shè)計引起軟件設(shè)計人員的重視的程度還遠(yuǎn)遠(yuǎn)不夠，直到最近網(wǎng)頁制作的興起，才受到專家的青睞。而且設(shè)計良好的界面由于需要具有藝術(shù)美的天賦而遭拒絕。

3.1

窗口：







窗口是否基于相關(guān)的輸入和菜單命令適當(dāng)?shù)卮蜷_？




窗口能否改變大小、移動和滾動？

窗口中的數(shù)據(jù)內(nèi)容能否用鼠標(biāo)、功能鍵、方向鍵和鍵盤訪問？




當(dāng)被覆蓋并重新調(diào)用后，窗口能否正確地再生？

需要時能否使用所有窗口相關(guān)的功能？

所有窗口相關(guān)的功能是可操作的嗎？

是否有相關(guān)的下拉式菜單、工具條、滾動條、對話框、按鈕、圖標(biāo)和其他控制可為窗口使用，并適當(dāng)?shù)仫@示？

顯示多個窗口時，窗口的名稱是否被適當(dāng)?shù)乇硎荆?

活動窗口是否被適當(dāng)?shù)丶恿粒?

如果使用多任務(wù)，是否所有的窗口被實時更新？

多次或不正確按鼠標(biāo)是否會導(dǎo)致無法預(yù)料的副作用？

窗口的聲音和顏色提示和窗口的操作順序是否符合需求？

窗口是否正確地被關(guān)閉？

3.2




4




兼容性測試

4.1

平臺測試

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

　　因此，在Web系統(tǒng)發(fā)布之前，需要在各種操作系統(tǒng)下對Web系統(tǒng)進(jìn)行兼容性測試。

4.2

瀏覽器測試

瀏覽器是Web客戶端最核心的構(gòu)件，來自不同廠商的瀏覽器對Java，、JavaScript、 ActiveX、 plug-ins或不同的HTML規(guī)格有不同的支持。例如，ActiveX是Microsoft的產(chǎn)品，是為Internet Explorer而設(shè)計的，JavaScript是Netscape的產(chǎn)品，Java是Sun的產(chǎn)品等等。另外，框架和層次結(jié)構(gòu)風(fēng)格在不同的瀏覽器中也有不同的顯示，甚至根本不顯示。不同的瀏覽器對安全性和Java的設(shè)置也不一樣。

　測試瀏覽器兼容性的一個方法是創(chuàng)建一個兼容性矩陣。在這個矩陣中，測試不同廠商、不同版本的瀏覽器對某些構(gòu)件和設(shè)置的適應(yīng)性。

4.3

分辨率測試

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

5




安全測試

主要是測試系統(tǒng)在沒有授權(quán)的情況下，內(nèi)部或者外部用戶對系統(tǒng)進(jìn)行攻擊或者惡意破壞時如何進(jìn)行處理，是否仍能保證數(shù)據(jù)的安全。測試人員可以學(xué)習(xí)一些黑客技術(shù)，來對系統(tǒng)進(jìn)行攻擊。

5.1

登錄

有些站點需要用戶進(jìn)行登錄，以驗證他們的身份。這樣對用戶是方便的，他們不需要每次都輸入個人資料。你需要驗證系統(tǒng)阻止非法的用戶名/口令登錄，而能夠通過有效登錄。用戶登錄是否有次數(shù)限制? 是否限制從某些 IP 地址登錄? 如果允許登錄失敗的次數(shù)為3，你在第三次登錄的時候輸入正確的用戶名和口令，能通過驗證嗎? 口令選擇有規(guī)則限制嗎?

是否可以不登陸而直接瀏覽某個頁面？

Web應(yīng)用系統(tǒng)是否有超時的限制，也就是說，用戶登陸后在一定時間內(nèi)（例如15分鐘）沒有點擊任何頁面，是否需要重新登陸才能正常使用。

6

接口測試

數(shù)據(jù)一般通過接口輸入和輸出，所以接口測試是白盒測試的第一步。每個接口可能有多個輸入?yún)?shù)，每個參數(shù)有“典型值”、“邊界值”、“異常值”之分，所以輸入的組合數(shù)可能并不少。根據(jù)接口的定義，可以推斷某種輸入應(yīng)當(dāng)產(chǎn)生什么樣的輸出。輸出包括函數(shù)的返回值和輸出參數(shù)。如果實際輸出與期望的輸出不一致，那么說明程序有錯誤。

6.1

服務(wù)器接口

第一個需要測試的接口是瀏覽器與服務(wù)器的接口。測試人員提交事務(wù)，然后查看服務(wù)器記錄，并驗證在瀏覽器上看到的正好是服務(wù)器上發(fā)生的。測試人員還可以查詢數(shù)據(jù)庫，確認(rèn)事務(wù)數(shù)據(jù)已正確保存。

6.2

外部接口

有些 web 系統(tǒng)有外部接口。例如，網(wǎng)上商店可能要實時驗證信用卡數(shù)據(jù)以減少欺詐行為的發(fā)生。測試的時候，要使用 web 接口發(fā)送一些事務(wù)數(shù)據(jù)，分別對有效信用卡、無效信用卡和被盜信用卡進(jìn)行驗證。

6.3

錯誤處理

最容易被測試人員忽略的地方是接口錯誤處理。通常我們試圖確認(rèn)系統(tǒng)能夠處理所有錯誤，但卻無法預(yù)期系統(tǒng)所有可能的錯誤。嘗試在處理過程中中斷事務(wù)，看看會發(fā)生什么情況？訂單是否完成？嘗試中斷用戶到服務(wù)器的網(wǎng)絡(luò)連接。嘗試中斷 web 服務(wù)器到信用卡驗證服務(wù)器的連接。在這些情況下，系統(tǒng)能否正確處理這些錯誤？是否已對信用卡進(jìn)行收費？如果用戶自己中斷事務(wù)處理，在訂單已保存而用戶沒有返回網(wǎng)站確認(rèn)的時候，需要由客戶代表致電用戶進(jìn)行訂單確認(rèn)。

7

測試點

7.1

文本框的測試

測試方法：

　a,輸入正常的字母或數(shù)字。

　b,輸入已存在的文件的名稱；

　c,輸入超長字符。例如在“名稱”框中輸入超過允許邊界個數(shù)的字符，假設(shè)最多255個字符，嘗試輸入 256個字符，檢查程序能否正確處理；

　d,輸入默認(rèn)值，空白，空格；

　e,若只允許輸入字母，嘗試輸入數(shù)字；反之；嘗試輸入字母；

　f,利用復(fù)制，粘貼等操作強制輸入程序不允許的輸入數(shù)據(jù)；

　g,輸入特殊字符集，例如，NUL及/n等；

　h,輸入超過文本框長度的字符或文本，檢查所輸入的內(nèi)容是否正常顯示；

　i,輸入不符合格式的數(shù)據(jù)，檢查程序是否正常校驗，如，程序要求輸入年月日格式為yy/mm/dd，實際輸入yyyy/mm/dd，程序應(yīng)該給出錯誤提示

7.2

命令按鈕測試

測試方法：

　a,點擊按鈕正確響應(yīng)操作。如，單擊確定，正確執(zhí)行操作；單擊取消，退出窗口；

　b,對非法的輸入或操作給出足夠的提示說明，如，輸入月工作天數(shù)為32時，單擊“確定”后系統(tǒng)應(yīng)提示:天數(shù)不能大于31；

　c,對可能造成數(shù)據(jù)無法恢復(fù)的操作必須給出確認(rèn)信息，給用戶放棄選擇的機會；

7.3

單選按鈕的測試

測試方法：

　a,一組單選按鈕不能同時選中，只能選中一個。

b,逐一執(zhí)行每個單選按鈕的功能。分別選擇了“男”“女”后，保存到數(shù)據(jù)庫的數(shù)據(jù)應(yīng)該相應(yīng)的分別為“男”“女”；

c,一組執(zhí)行同一功能的單選按鈕在初始狀態(tài)時必須有一個被默認(rèn)選中，不能同時為空；

7.4

組合列表框的測試

測試方法：

　a,條目內(nèi)容正確，其詳細(xì)條目內(nèi)容可以根據(jù)需求說明確定；

b,逐一執(zhí)行列表框中每個條目的功能；

c,檢查能否向組合列表框輸入數(shù)據(jù)；

7.5

復(fù)選框的測試

測試方法：

　a,多個復(fù)選框可以被同時選中；

　b,多個復(fù)選框可以被部分選中；

　c,多個復(fù)選框可以都不被選中；

　d,逐一執(zhí)行每個復(fù)選框的功能；

7.6

列表框控件的測試

測試方法：

　a,條目內(nèi)容正確；同組合列表框類似，根據(jù)需求說明書確定列表的各項內(nèi)容正確，沒有丟失或錯誤；

　b,列表框的內(nèi)容較多時要使用滾動條；

　c,列表框允許多選時，要分別檢查shift選中條目，按ctrl選中條目和直接用鼠標(biāo)選中多項條目的情況；

7.7

滾動條控件的測試

要注意一下幾點：

　a,滾動條的長度根據(jù)顯示信息的長度或?qū)挾燃皶r變換，這樣有利于用戶了解顯示信息的位置和百分比，如，word中瀏覽100頁文檔，瀏覽到50頁時，滾動條位置應(yīng)處于中間；

　b,拖動滾動條，檢查屏幕刷新情況，并查看是否有亂碼；

　c,單擊滾動條；

　d,用滾輪控制滾動條；

　e,滾動條的上下按鈕。

7.8

各種控件在窗體中混和使用時的測試

　a,控件間的相互作用；

　b,tab鍵的順序，一般是從上到下，從左到右；

　c,熱鍵的使用，逐一測試；

　d,enter鍵和esc鍵的使用；

在測試中，應(yīng)遵循由簡入繁的原則，先進(jìn)行單個控件功能的測試，確保實現(xiàn)無誤后，再進(jìn)行多個控件的功能組合的測試。