當前位置:首頁 » 網頁前端 » web界面載入測試
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

web界面載入測試

發布時間: 2023-08-12 03:02:01

Ⅰ 我想用手機測試自己寫的web頁面,該怎麼做

一、IOS 移動端 (Safari開發者工具)

手機端:設置 → Safari → 高級 → Web 檢查器 → 開。
mac端:Safari → 偏好設置 → 高級 → 在菜單欄中顯示「開發」菜單。
在 OS X 中啟動 Safari 之後,以 USB 電纜正常接入 iOS 設備,並在此移動設備上啟動 Safari。此時點擊計算機上的 Safari 菜單中的「開發」,可以看到有 iOS 設備的名稱顯示,其子菜單項即為移動設備上 Safari 的所有標簽頁,點擊任意一個開始調試。
便捷,簡單,還可以調試外殼包裹的瀏覽器如微信。
備註:順便提一下,要調試不同版本的ios,可以進xcode 進行下載不同的系統包(當然是在沒有設備的情況下,土豪略過)
二、安卓移動端

1、chrome 調試方法
首先確保手機上和PC機上裝有最新版本的chrome瀏覽器,其次是將手機的開發者選項打開並允許調試,然後將數據線將兩台設備連接起來。在PC機上打開chorme,輸入chrome://inspect ,然後在手機上打開chrome,然後手機會彈框詢問是否允許調試,當然確定啦。有時候手機鎖屏會斷開,請拔掉usb重來。
點擊inspect打開DevTools後,你可以選中頁面中的DOM元素,同時設備中對應元素也高亮顯示,也可使用DevTools中的Inspect Element 選中目標元素,可以實時與移動設備頁面交互,方便的定位問題所在,進行代碼調試,就能像pc端一樣愉快的玩耍了。如果有問題,請檢查chrome版本。

作者:愛吃西紅柿的魚
鏈接:http://www.hu.com/question/37361845/answer/71674280
來源:知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權,非商業轉載請註明出處。

chrome的調試一般只可以調試chrome頁面,但是其官方文檔說還可以調試WebViews:
「On your computer, the chrome://inspect page displays every connected device, along with its open tabs and debug-enabled WebViews.」
需要說明調試WebView需要滿足安卓系統版本為Android 4.4+,並且需要再你的APP內配置相應的代碼,在WebView類中調用靜態方法,如下:
if (Build.VERSION.SDK_INT >=Build.VERSION_CODES.KITKAT) {
WebView.(true);
}

以上配置方法適用於安卓應用內所有的WebView情形。
安卓WebView是否可調試並不取決於應用中manifest的標志變數debuggable,如果你想只在debuggable為true時候允許WebView遠程調試,請使用以下代碼段:
if (Build.VERSION.SDK_INT>= Build.VERSION_CODES.KITKAT) {
if (0 != (getApplicationInfo().flags &=ApplicationInfo.FLAG_DEBUGGABLE{
WebView.(true);
}
}

我這里只寫了個大概,如果有其他問題或者欲查看詳細文檔,看下面鏈接(自備梯子):
https://developer.chrome.com/devtools/docs/remote-debugging

注意:同樣的你也可以在電腦上裝安卓的虛擬機,推薦Genymotion ,一樣的,想測什麼版本,就自己下rom ,當然土豪當我沒說。

2、UC開發者瀏覽器
由於不推薦移動端使用UC(大家應該自覺抵制移動端毒瘤),所以我只簡單說一下,如果是在有興趣,請自行查看: 開發者中心_UC優視︱UC瀏覽器︱全球第一大手機瀏覽器,用戶超過5億人︱手機瀏覽器
它的調試方法與chrome差異不大。

3、使用 Weinre 調試

該方法是比較老的一種方法,對於其他的調試方法來說屬於刀耕火種型的。weinre是一個調試包,本身提供一個JavaScript,需要你在項目文件中加入該js。首先安裝Weinre,我們用nodejs安裝之,使用-g全局命令,以便可以在各個目錄下訪問
npm install -g weinre

安裝weinre之後再設置監聽本機的ip:

然後打開返回的地址的說明文檔,然後把返回的js寫入到調試的文檔中,注意我箭頭所指向的地方。
這樣訪問頁面的時候,載入這個 JS,就會被 Weinre 監聽到進行控制。
小提示:這個 JS 後面的 #anonymous 起到一個標識作用,為了區別,我們可以將其修改成 #test 放到頁面中。這時候,我們的 Inspect 面板的地址就不是 http://172.16.0.2:8080/client/#anonymous 了,而是 http://172.16.0.2:8080/client/#test 。
當我們訪問頁面的時候,就會出現在監聽列表中,如果有多個網頁,你可以從列表中選擇一個。然後就可以使用後面的 Elements、Console 等面板來進行調試操作了:

Weinre 非常靈活,只需要在頁面中載入這個 JS,然後訪問即可,因此 WebView 可以用這種方法調試,一些低版本的 Android、iOS 也可以支持,Window Phone 也是可以用的。在調試移動設備時你可能需要在本地搭建一個區域網 IP 的伺服器,將設備與本機網路連接成一個區域網,用移動設備訪問這個網頁即可。
當然 Weinre 也不是萬能的,相比 Chrome 的調試工具,它缺少 JavaScript debug 以及 Profiles 等常用功能,但是它兼容性強,可以實現基礎調試功能。

4、mihtool 測試
MIHTool 是國人開發的,基於 Weinre,用於 iOS 設備的前端開發測試。
與Weinre 的調試方式大體一樣,即開啟一個伺服器,然後將 JS 插入到頁面中,訪問進行調試。
MIHTool 將這個過程簡化了,它是一個 APP,可以直接安裝到你的 iOS 設備裡面,然後內置一個簡單的瀏覽器可以打開你的測試頁面,當它開啟時,會自動向頁面中插入 Weinre 的 JS,並告知 Weinre 控制台 URL 等信息,讓你可以訪問進行調試。
它還提供了一個公共的 Weinre 調試服務,生成類似 MIHTool Web Inspector 這樣的鏈接,打開即可調試,非常方便,就是有些卡。
5、移動設備在線測試
移動端設備如此之多,小公司或者團隊,沒有這么多資金和精力購買如此多的測試設備進行測試。於是就有人買了這些設備,連接起來,提供在線調試服務。
一般就是他的真實手機設備打開,然後截屏出來供預覽。
比如:BrowserStack 等,當然一般比較卡。

三、總結

調試方法很多,層出不窮,關鍵是要看自己是否順手和熟練,關鍵在於按時按量的完成開發任務。
關鍵在於平時多積累跨坑姿勢,少寫一點不兼容的代碼,調試就舒心一點。

如果這還不滿足的話,可以查看更多資料:

移動端前端開發調試: http://yujiangshui.com/multidevice-frontend-debug/
移動開發真機調試: 移動開發真機調試
remote_inspect_web_on_real_device: jieyou/remote_inspect_web_on_real_device · GitHub
remote-debugging: https://developer.chrome.com/devtools/docs/remote-debugging
移動端Web開發調試之Chrome遠程調試(Remote Debugging):移動端Web開發調試之Chrome遠程調試(Remote Debugging)

------------2015/12/2 補充 BrowserSync 部分-------------
很多朋友再說為什麼不寫Browser-sync,還有給差評的,說實話吧,我之前不了解那個東西。花了點時間看了一下,找到了他們的官網:Browsersync - Time-saving synchronised browser testing 覺得還挺有趣的哈。
然後就用了,覺得還行,真的會省很多工夫,入門也快,差不多就5分鍾快速入門,前端的輪子都這樣。。。
1、首先安裝 BrowserSync
npm install -g browser-sync

2、啟動 BrowserSync,原理應該是那種檢測文件變化,然後在服務端 websocket 通知瀏覽器變動,再載入新的變動文件,在不支持websocket 的瀏覽器上就輪訓服務端的變化,在載入新文件。我只是簡單的抓包看了下,也不知道說對了沒有。233
此時分兩種情況,一種是靜態:
// 監聽css文件
browser-sync start --server --files "css/*.css"
// 監聽css和html文件
browser-sync start --server --files "css/*.css, *.html"

二種是動態:
// 主機名可以是ip或域名
browser-sync start --proxy "主機名" "css/*.css"

然後就上手了啊,就這么簡單。。
還有gulp 配合哦。具體就看文檔了:Browsersync + Gulp.js

總結,前端變化日新月異,一個月不學,感覺就落後了啊

-----------------我是分割線---------------

這里是 @於江水 大神的原文,之所以圈他一下,因為我的這個文檔從他那兒粘貼了很多,這個是他的原文:--> 移動端前端開發調試 。
上面的更多資料部分,我也講其放在第一個,不過之前的鏈接放錯了,不是原博客鏈接,現在已更正。

這是我整理的,每一個我都真正的動手實現了的,關於安卓webview的調試部分我還補充了點我找到的資料 --> 移動端前端開發真機調試攻略

Ⅱ 我想用手機測試自己寫的web頁面,該怎麼做

我來說個簡單的辦法
開發好頁面,先用谷歌瀏覽器的手機屏幕模擬功能看一下
去xampp官網下一下這個軟體,在本地建一個簡單的伺服器,然後把自己的頁面放到伺服器上打開,你的頁面路徑應該類似於http://192.168.1.2/xampp/demo/index.html這種樣子
打開網路隨便輸一個二維碼生成器,把上面的地址粘進去生成二維碼
拿出手機打開微信或其他能掃碼的瀏覽器掃碼預覽就可以了
想看修改代碼後的樣子重復第3步和第4步
注意點:你輸入的網址前面的ip一定而且肯定是你自己電腦的ip地址,默認的情況下,地址是http://localhost/……,一定記得把localhost替換成你本地的ip,不然你掃碼是掃不出來的。

Ⅲ web的功能測試怎樣測試

首先,查找需求說明、網站設計等相關文檔,分析測試需求。
制定測試計劃,確定測試范圍和測試策略,一般包括以下幾個部分:功能性測試;界面測試;性能測試;資料庫測試;安全性測試;兼容性測試

設計測試用例:
功能性測試可以包括,但不限於以下幾個方面:
鏈接測試。鏈接是否正確跳轉,是否存在空頁面和無效頁面,是否有不正確的出錯信息返回。
提交功能的測試。
多媒體元素是否可以正確載入和顯示。
多語言支持是否能夠正確顯示選擇的語言等。

界面測試可以包括但不限於一下幾個方面:
頁面是否風格統一,美觀
頁面布局是否合理,重點內容和熱點內容是否突出
控制項是否正常使用
對於必須但未安裝的控制項,是否提供自動下載並安裝的功能
文字檢查

性能測試一般從以下三個方面考慮:
壓力測試;負載測試;強度測試

資料庫測試要具體決定是否需要開展。資料庫一般需要考慮連結性,對數據的存取操作,數據內容的驗證等方面。

安全性測試:
基本的登錄功能的檢查
是否存在溢出錯誤,導致系統崩潰或者許可權泄露
相關開發語言的常見安全性問題檢查,例如SQL注入等
如果需要高級的安全性測試,確定獲得專業安全公司的幫助,外包測試,或者獲取支持

兼容性測試,根據需求說明的內容,確定支持的平台組合:
瀏覽器的兼容性;
操作系統的兼容性;
軟體平台的兼容性;
資料庫的兼容性

開展測試,並記錄缺陷。合理的安排調整測試進度,提前獲取測試所需的資源,建立管理體系(例如,需求變更、風險、配置、測試文檔、缺陷報告、人力資源等內容)。
定期評審,對測試進行評估和總結,調整測試的內容。

敲黑板!重點:推薦大家使用自動化測試工具TestWriter(測功能、測兼容性、測回歸的零編碼自動化測試工具 ),吼吼~

Ⅳ 【web測試】界面測試(UI)

簡稱UI測試,測試功能模塊界面上看到的所有元素(包括文字、控制項等)顏色風格是否統一,布局是否合理、美觀,符合用戶習慣等等

核實用戶與軟體之間的交互,確保用戶界面會通過測試對象的功能來為用戶提供相應的訪問或瀏覽功能

如:頁面基調顏色刺眼;用戶登入頁面比較難於找到;文字中出現錯別字;頁面圖片范圍太廣
缺陷影響:用戶友好性、人性化、易操作性

進入一個頁面測試,首先是檢查title、頁面排版、欄位等,而不是馬上進入文本框校驗

(1)頁面名稱title是否正確
(2)文字格式統一性,字體屬性是否正確
(3)元素大小是否合適,元素內容是否顯示正確、易懂、友好
(4)排版是否整齊,界面元素是否對齊方式統一
(5)列表項顯示欄位是否齊全,列表項欄位名稱是否跟表單統一
(6)同一頁面,是否出現欄位名稱相同、值取不同的問題。
(7)數據載入情況。

(1)文案:字體、字型大小、格式、規范(標題和正文、中英文換行、錯別字、大小寫、全半形標點);
(2)圖片:類型、大小、尺寸、是否變形;
(3)布局:尺寸大小、位置合理、排序規律、對齊方式
(4)控制項:對話框、文本框、滑動滾輪、上下微調按鈕、選項按鈕
(5)快捷鍵:是否重復、如何切換、是否沖突、和系統常用快捷鍵沖突、和其他軟體快捷鍵沖突、常用鍵盤鍵

Ⅳ Web測試的主要內容和測試方法有哪些


測試分類:


1、界面測試

1)給用戶的整體感:舒適感;憑感覺能找到想要找的信息;設計風格是否一致

2)各控制項的功能

2、功能測試

1)刪除/增加某一項:是否對其他項造成影響,這些影響是否都正確

2)列表默認值檢查

3)檢查按鈕功能是否正確:新建、編輯、刪除、關閉、返回、保存、導入、上一頁、下一頁、頁面跳轉、重置(常見錯誤)

4)字元串長度檢查:超出長度

5)字元類型檢查

6)標點符號檢查:空格、各種引號、Enter鍵

7)特殊字元:常見%、「、」

8)中文字元:是否亂碼

9)檢查信息完整:查看信息,查看所填信息是否完整更新;更新信息,更新信息與添加信息是否一致

10)信息重復:需唯一信息處,比如重復的名字或ID、重名是否區分大小寫、加空格

11)檢查刪除功能:不選擇任何信息,按Delete,看如何處理;選擇一個或多個進行刪除;多頁選、翻頁選刪除;刪除是否有提示

12)檢查添加和修改是否一致:添加必填項,修改也該必填;添加為什麼類型,修改也該什麼類型

13)檢查修改重名:修改時把不能重名的項改為已存在的內容

14)重復提交表單:一條已經成功提交的記錄,返回後再提交

15)檢查多次使用返回鍵:返回到原來頁面,重復多次

16)搜索檢查:存在或不存在內容,看搜索結果是否正確;多個搜索條件,同時輸入合理和不合理條件;特殊字元

17)輸入信息的位置

18)上傳下載文件檢查:功能是否實現,

上傳:上傳文件是否能打開、格式要求、系統是否有解釋信息、將不能上傳的文件格式修改後綴為可上傳的文件格式;

下載:下載是否能打開、保存、格式要求

19)必填項檢查:必填項未填寫;是否有提示,如加*;對必填項提示返回後,焦點是否自動定位到必填項

20)快捷鍵檢查:是否支持快捷鍵Ctrl+C、Ctrl+V、backspace;對不允許做輸入的欄位(如:下拉選項),對快捷方式是否也做了限制

21)Enter鍵檢查:輸入結束後按Enter鍵,系統如何處理

22)刷新鍵檢查:按瀏覽器刷新鍵如何處理

23)回退鍵檢查:按瀏覽器回退鍵如何處理

24)空格檢查:輸入項輸入一個或多個空格

25)輸入法半形全形檢查:比如,浮點型,輸入全形小數點「。」或「. 」,如4. 5;全形空格

26)密碼檢查:輸入加密方式的極限字元;密碼盡可能長

27)用戶檢查:不同種類管理員用戶的不同許可權,是否可以互相刪除、管理、編輯;一般用戶的許可權;注銷功能,老用戶注銷再注冊,是否為新用戶

28)系統數據檢查:數據隨業務過程、狀態的變化保持正確,不能因為某個過程出現垃圾數據,也不能因為某個過程而丟失數據。

29)系統可恢復性檢查:以各種方式把系統搞癱,測試系統是否可以迅速恢復

30)確認提示檢查:系統更新、刪除操作:是否有提示、取消操作;提示是否准確;事前、事後提示

31)數據注入檢查:對資料庫注入,特殊字元,對SQL語句進行破壞

32)時間日期檢查:時間、日期、時間驗證:日期范圍是否符合實際業務;對於不符合實際業務的日期是否有限制

33)多瀏覽器驗證

3、性能測試

1)壓力測試:實際破壞一個Web應用系統,測試系統的反應,測試系統的限制和故障恢復能力

2)負載測試:在某一負載級別上的性能,包括某個時刻同時訪問Web的用戶數量、在線數據處理的數量

3)強度測試:測試對象在性能行為異常或極端條件下(如資源減少或用戶過多)的可接受性,以此驗證系統軟硬體水平

4)資料庫容量測試:通過存儲過程往資料庫表中插入一定數量的數據,看是否能及時顯示

5)預期指標的性能測試:在需求分析和設計階段會提出一些性能指標,對於預先確定的性能要求要首先進行測試

6)獨立業務性能測試:對核心業務模塊做用戶並發測試,包括同一時刻進行完全一樣的操作、同一時刻使用完全一樣的功能

7)組合業務性能測試:模擬多用戶的不同操作,最接近實際用戶使用情況,按用戶實際的實際使用人數比例來模擬各個模塊的組合並發情況

8)疲勞強度性能測試:系統穩定運行情況下,以一定負載壓力來長時間運行系統的測試

9)網路性能測試:准確展示帶寬、延遲、負載、埠的變化是如何影響用戶的相應時間的

10)大數據量性能測試:實時大數據量,模擬用戶工作時的實時大數據量;極限狀態下的測試,系統使用一段時間,積累一段數據量時能否正常運行,以及對前面兩種進行結合

11)伺服器性能測試:在進行用戶並發性能測試、疲勞強度、大數據量性能測試時,完成對伺服器性能的監控,並進行評估

12)一些特殊的測試:配置測試、內存泄漏的一些特殊測試

4、可用性測試(介面測試)

1)整體界面測試

2)多媒體測試

3)導航測試

5、客戶端兼容性

平台測試:windows;unix;macintosh;linux

瀏覽器測試:不同廠商的瀏覽器對Java、Javascript、ActiveX、plug-ins或不同的HTML的規格

不同的支持;框架和層次結構在不同瀏覽器也不同的顯示

6、安全性

安全性測試要求:

1)能夠對密碼試探工具進行防範

2)能夠防範對Cookie攻擊的常用手段

3)敏感數據保證不用明文傳輸

4)能防範通過文件名猜測和查看html文件內容獲取重要信息

5)能保證在網站收到工具後在給定時間內恢復,重要數據丟失不超過1小時



web的性能測試工具:



隨著Web2.0技術的迅速發展,許多公司都開發了一些基於Web的網站服務,通常在設計開發Web應用系統的時候很難模擬出大量用戶同時訪問系統的實際情況。

因此,當Web網站遇到訪問高峰時,容易發生伺服器響應速度變慢甚至服務中斷。

為了避免這種情況,需要一種能夠真實模擬大量用戶訪問Web應用系統的性能測試工具進行壓力測試,來測試靜態HTML頁面的響應時間,甚至測試動態網頁(包括ASP、PHP、JSP等)的響應時間,為伺服器的性能優化和調整提供數據依據。


1、企業級自動化測試工具WinRunner



MercuryInteractive公司的WinRunner是一種企業級的功能測試工具,用於檢測應用程序是否能夠達到預期的功能及正常運行。



2、工業標准級負載測試工具Loadrunner

LoadRunner是一種預測系統行為和性能的負載測試工具



3、全球測試管理系統testdirector



TestDirector是業界第一個基於Web的測試管理系統,它可以在您公司內部或外部進行全球范圍內測試的管理。



4、功能測試工具RationalRobot



IBMRationalRobot是業界最頂尖的功能測試工具,它甚至可以在測試人員學習高級腳本技術之前幫助其進行成功的測試。

它集成在測試人員的桌面IBMRationalTestManager上,在這里測試人員可以計劃、組織、執行、管理和報告所有測試活動,包括手動測試報告。

這種測試和管理的雙重功能是自動化測試的理想開始。



5、單元測試工具xUnit系列



目前的最流行的單元測試工具是xUnit系列框架,常用的根據語言不同分為JUnit(java),CppUnit(C++),DUnit(Delphi),NUnit(.net),PhpUnit(Php)等等。

該測試框架的第一個和最傑出的應用就是由ErichGamma(《設計模式》的作者)和KentBeck(XP(ExtremeProgramming)的創始人)提供的開放源代碼的JUnit.



6、功能測試工具SilkTest



BorlandSilkTest2006屬於軟體功能測試工具,是Borland公司所提出軟體質量管理解決方案的套件之一。

這個工具採用精靈設定與自動化執行測試,無論是程序設計新手或資深的專家都能快速建立功能測試,並分析功能錯誤。



7、性能測試工具WAS



是由微軟的網站測試人員所開發,專門用來進行實際網站壓力測試的一套工具。

透過這套功能強大的壓力測試工具,您可以使用少量的Client端計算機模擬大量用戶上線對網站服務所可能造成的影響。



8、自動化白盒測試工具Jtest


Jtest是parasoft公司推出的一款針對java語言的自動化白盒測試工具,它通過自動實現java的單元測試和代碼標准校驗,來提高代碼的可靠性。

parasoft同時出品的還有C++test,是一款C/C++白盒測試工具。



9、功能和性能測試的工具JMeter



JMeter是Apache組織的開放源代碼項目,它是功能和性能測試的工具,100%的用java實現。



10、性能測試和分析工具WEBLOAD



webload是RadView公司推出的一個性能測試和分析工具,它讓web應用程序開發者自動執行壓力測試;webload通過模擬真實用戶的操作,生成壓力負載來測試web的性能。



(5)web界面載入測試擴展閱讀:


漏洞測試



企業網站做的越來越復雜、功能越來越強。不過這些都不是憑空而來的,是通過代碼堆積起來的。如果這個代碼只供企業內部使用,那麼不會帶來多大的安全隱患。

但是如果放在互聯網上使用的話,則這些為實現特定功能的代碼就有可能成為攻擊者的目標。

天眼舉一個簡單的例子。在網頁中可以嵌入SQL代碼。而攻擊者就可以利用這些SQL代碼來發動攻擊,來獲取管理員的密碼等等破壞性的動作。

有時候訪問某些網站還需要有某些特定的控制項。用戶在安裝這些控制項時,其實就有可能在安裝一個木馬(這可能訪問者與被訪問者都沒有意識到)。


為此在為網站某個特定功能編寫代碼時,就要主動出擊。從編碼的設計到編寫、到測試,都需要認識到是否存在著安全的漏洞。

天眼在日常過程中,在這方面對於員工提出了很高的要求。各個員工必須對自己所開發的功能負責。

已知的病毒、木馬不能夠在所開發的插件中有機可乘。通過這層層把關,就可以提高代碼編寫的安全性。

Ⅵ Web測試的主要內容和測試方法有哪些

1功能測試 2 1.1鏈接測試 2 1.2表單測試 2 1.3數據校驗 3 1.4 cookies測試 3
1功能測試 2
1.1鏈接測試 2
1.2表單測試 2
1.3數據校驗 3
1.4 cookies測試 3
1.5資料庫測試 3
1.6應用程序特定的功能需求 4
1.7設計語言測試 4
2性能測試 4
2.1連接速度測試 4
2.2負載測試 4
2.3壓力測試 5
3用戶界面測試 6
3.1導航測試 6
3.2圖形測試 6
3.3內容測試 7
3.4表格測試 7
3.5整體界面測試 7
4兼容性測試 8
4.1平台測試 8
4.2瀏覽器測試 8
4.3解析度測試 8
4.4 Modem/連接速率 9
4.5列印機 9
4.6組合測試 9
5安全測試 9
5.1目錄設置 9
5.2登錄 10
5.3日誌文件 10
5.4腳本語言 10
6介面測試 10
6.1伺服器介面 10
6.2外部介面 11
6.3錯誤處理 11
7結論 11
在Web工程過程中,基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作。基於Web的系統測試與傳統的軟體測試不同,它不但需要檢查和驗證是否按照設計的要求運行,而且還要測試系統在不同用戶的瀏覽器端的顯示是否合適。重要的是,還要從最終用戶的角度進行安全性和可用性測試。然而,Internet和Web媒體的不可預見性使測試基於Web的系統變得困難。因此,我們必須為測試和評估復雜的基於Web的系統研究新的方法和技術

Ⅶ 能介紹一下web測試的技術嗎

Web測試技術- -

由於Web應用與用戶直接相關,又通常需要承受長時間的大量操作,因此Web項目的功能和性能都必須經過可靠的驗證。這就要經過Web項目的全面測試。

Web測試通常通過界面測試、功能測試、性能測試幾個方面來進行。測試方法則根據測試內容的不同而不同。下面就這三個方面分別進行說明。

一、界面測試

界面測試就是對Web項目的界面部分進行正確性、靈活性、直觀性、一致性、舒適性等方面的驗證。這部分的測試看似簡單,但實際上包含的測試項目龐雜,又可間接對應用程序的准確性進行驗證,同時它的實用性與最終用戶直接相關,因此決不可低估它的地位。

界面測試包括的主要內容有:頁面的規范性、舒適性、正確性、直觀性、實用性、一致性幾個方面。

頁面的規范性主要是指布局、色調和美觀性的統一。這通常在項目初期確定,測試階段需要驗證最終頁面的實現是否與之前的確定方案相吻合。包括各個頁面元素的布局和位置是否合理、外形是否准確,色調是否正確美觀,CSS風格設置是否統一,等等。

頁面的正確性包括頁面元素的基本功能是否實現,是否具有完善的容錯處理,顯示方式是否正確,各項鏈接是否准確,各個腳本程序是否存在、准確,等等。

頁面的直觀性包括界面是否整潔鮮明、不擁擠,是否包括了冗餘功能,主要功能和操作流程是否突出,等等。

頁面的一致性包括各種快捷鍵和菜單選項是否與通用的習慣相符(比如F1為幫助信息、Tab鍵進行元素間跳轉等),包含術語和命令與命令行方式是否一致,按鈕位置是否符合習慣(如各種設置頁面均該包括確定和取消按鈕,且確定按鈕位置在前)等。

頁面的靈活性包括頁面是否具有完善的容錯處理方案,統一操作是否有符合不同用戶習慣的多種操作方式,處理結果是否有多種顯示方式,操作是否支持鍵盤滑鼠兩種方式,包含數據量大的時候是否支持查找或排序操作,頁面是否在各種解析度下均被支持,屏幕大小變化,等等。

頁面的舒適性包括界面操作邏輯是否合理、符合用戶習慣,在用戶操作錯誤時是否有合理的信息提示,等等。

以上各個方面的測試是可以同時進行的。方法通常是根據操作邏輯和頁面內容制定詳細的測試case文檔,按照各個case逐個走查。注意要case要覆蓋全部情況。頁面若針對多個不同的用戶群,應盡可能的由不同操作習慣的測試人員充當各種角色參與測試。

二、功能測試

界面的功能一般包括後台數據的增刪查改、用戶輸入輸出校驗、狀態信息的顯示和保存等,這些通常是通過CGI程序、Javascript程序、Cookies等來協同完成的。測試要根據目標功能對包含程序逐一進行驗證。

功能測試主要包含以下幾個部分:

是否能夠提供用戶正常的登錄,是否具有登錄失敗時的合理處理,是否具有登錄用戶的狀態信息存儲,以及密碼的差錯校驗和修改能力。

對於用戶輸入,是否具有合法性檢查,是以何種方式實現,這種方式是否適應所有情況和變化。若以javascript來實現,是否考慮了用戶禁用javascript程序時的情況。

若頁麵包含有Cookies,要驗證Cookie包含信息已經加密且信息准確。

對於每一個提交的表單,要驗證後台程序是否能夠准確接收和處理,以及是否包含了各種異常情況的處理。如果包含資料庫操作或文件讀寫操作,要保證資料庫工作正常,且後台程序對之具有完善的容錯能力。

這部分的測試方法很多,總體的功能驗證可以通過引入測試工具來進行。有一些工具可以模擬網頁表單的提交過程,測試人員只需要提前寫好表單輸入數據及預期輸出結果,便可以對一系列功能進行批量驗證。

三、性能測試

性能測試主要考慮伺服器端在負載壓力足夠大的情況下,是否能保證性能長期穩定。這需要對伺服器進行各種極限情況的測試,包括用戶數目、運行時間、反復啟停等情況的極限情況。這項測試通常能夠找出系統的內存泄露或邊界情況的問題。

性能測試通常通過工具來進行,如loadrunner、webload、was、ewl、E-Test等,主要方法都是先編寫出測試腳本,然後運行得出報告。這些工具基本都是利用線程技術模擬虛擬用戶來實現的。

四、測試工具

網上介紹較多的包括以下一些工具:

E-Test功能很強大,其實現採用的不是Post URL的方式,因此可以支持多內碼的測試數據,基本可以測試大部分的Web站點。

Microsoft Web Application Stress Tool利用腳本回放來代替手工勞動,驗證頁面表單對各種輸入的響應結果,同時也能夠提供一定的性能測試結果。

PureLoad是一個很好的性能測試工具,完全用Java寫成,可以測試各種C/S程序,如SMTP Server等。它和Microsoft Web Application Stress Tool都使用Post URL的方法測試Web項目,對大量使用JavaScript的頁面不太適合。

Linkbot是專門用來做頁面鏈接測試的工具。

MI公司的winrunner,compuware的qarun,Rational的SQA robot等可以用來做客戶端的功能測試和伺服器端的壓力性能測試。

也有一些工具是用來做測試流程管理的,比如Test Plan Control,test manager等等。