Web系統測試中的重點

Web測試不一樣於單純的軟件，可是Web的應用和更新也愈來愈普遍和頻繁。通常軟件的發佈週期以月或以年計算，而Web應用的發佈週期以天計算甚至以小時計算。Web測試人員必須處理更短的發佈週期，測試人員和測試管理人員面臨着從測試傳統的C/S結構和框架環境到測試快速改變的Web應用系統的轉變。

　　1、功能測試

　　一、連接測試

　　連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面。首先，測試全部連接是否按指示的那樣確實連接到了該連接的頁面；其次，測試所連接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。連接測試能夠自動進行，如今已經有許多工具能夠採用。連接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的全部頁面開發完成以後進行連接測試。

　　二、表單測試

　　當用戶給Web應用系統管理員提交信息時，就須要使用表單操做，例如用戶註冊、登錄、信息提交等。在這種狀況下，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。若是表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。

　　三、Cookies測試

　　Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。

　　四、設計語言測試

　　Web設計語言版本的差別能夠引發客戶端或服務器端嚴重的問題，例如使用哪一種版本的HTML等。當在分佈式環境中開發時，開發人員都不在一塊兒，這個問題就顯得尤其重要。除了HTML的版本問題外，不一樣的腳本語言，例如Java、javascript、 ActiveX、VBScript或Perl等也要進行驗證。

　　五、數據庫測試

　　在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，可使用SQL對信息進行處理。在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。

　　2、性能測試

　　一、鏈接速度測試

　　用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。

　　二、負載測試

　　負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？

　　三、壓力測試

　　負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。 

　　3、可用性測試

　　一、導航測試

　　導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？

　　在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

　　二、圖形測試

　　在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：

　　（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。

　　（2）驗證全部頁面字體的風格是否一致。

　　（3）背景顏色應該與字體顏色和前景顏色相搭配。

　　（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮。

　　三、內容測試

　　內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。信息的正確性是指信息是可靠的仍是誤傳的。例如，在商品價格列表中，錯誤的價格可能引發財政問題甚至致使法律糾紛；信息的準確性是指是否有語法或拼寫錯誤。這種測試一般使用一些文字處理軟件來進行，例如使用Microsoft Word的"拼音與語法檢查"功能；信息的相關性是指是否在當前頁面能夠找到與當前瀏覽信息相關的信息列表或入口，也就是通常Web站點中的所謂"相關文章列表"。

　　四、總體界面測試

　　總體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個總體感。例如：當用戶瀏覽Web應用系統時是否感到溫馨，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？對總體界面的測試過程，實際上是一個對最終用戶進行調查的過程。通常Web應用系統採起在主頁上作一個調查問卷的形式，來獲得最終用戶的反饋信息。對全部的可用性測試來講，都須要有外部人員（與Web應用系統開發沒有聯繫或聯繫不多的人員）的參與，最好是最終用戶的參與。

　　4、客戶端兼容性測試

　　一、平臺測試

　　市場上有不少不一樣的操做系統類型，最多見的有Windows、Unix、Macintosh、Linux等。Web應用系統的最終用戶究竟使用哪種操做系統，取決於用戶系統的配置。這樣，就可能會發生兼容性問題，同一個應用可能在某些操做系統下能正常運行，但在另外的操做系統下可能會運行失敗。所以，在Web系統發佈以前，須要在各類操做系統下對Web系統進行兼容性測試。

　　二、瀏覽器測試

　　瀏覽器是Web客戶端最核心的構件，來自不一樣廠商的瀏覽器對Java，、javascript、 ActiveX、 plug-ins或不一樣的HTML規格有不一樣的支持。例如，ActiveX是Microsoft的產品，是爲Internet Explorer而設計的，javascript是Netscape的產品，Java是Sun的產品等等。另外，框架和層次結構風格在不一樣的瀏覽器中也有不一樣的顯示，甚至根本不顯示。不一樣的瀏覽器對安全性和Java的設置也不同。測試瀏覽器兼容性的一個方法是建立一個兼容性矩陣。在這個矩陣中，測試不一樣廠商、不一樣版本的瀏覽器對某些構件和設置的適應性。

　　5、安全性測試

　　Web應用系統的安全性測試區域主要有：

　　（1）如今的Web應用系統基本採用先註冊，後登錄的方式。所以，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，能夠試多少次的限制，是否能夠不登錄而直接瀏覽某個頁面等。

　　（2）Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。

　　（3）爲了保證Web應用系統的安全性，日誌文件是相當重要的。須要測試相關信息是否寫進了日誌文件、是否可追蹤。

　　（4）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

　　（5）服務器端的腳本經常構成安全漏洞，這些漏洞又經常被黑客利用。因此，還要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。

　　6、總結

　　本文從功能、性能、可用性、客戶端兼容性、安全性等方面討論了基於Web的系統測試方法。基於Web的系統測試與傳統的軟件測試既有相同之處，也有不一樣的地方，對軟件測試提出了新的挑戰。基於Web的系統測試不但須要檢查和驗證是否按照設計的要求運行，並且還要評價系統在不一樣用戶的瀏覽器端的顯示是否合適。重要的是，還要從最終用戶的角度進行安全性和可用性測試。

     7、測試方法

    7.一、輸入框

一、字符型輸入框：

（1）字符型輸入框：英文全角、英文半角、數字、空或者空格、特殊字符「~！@#￥%……&*？[]{}」特別要注意單引號和&符號。禁止直接輸入特殊字符時，使用「粘貼、拷貝」功能嘗試輸入。

（2）長度檢查：最小長度、最大長度、最小長度-一、最大長度+一、輸入超工字符好比把整個文章拷貝過去。

（3）空格檢查：輸入的字符間有空格、字符前有空格、字符後有空格、字符先後有空格

（4）多行文本框輸入：容許回車換行、保存後再顯示可以保存輸入的格式、僅輸入回車換行，檢查可否正確保存（若能，檢查保存結果，若不能，查看是否有正常提示）、

（5）安全性檢查：輸入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>）、輸入腳本函數(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>）

二、數值型輸入框：

（1）邊界值：最大值、最小值、最大值+一、最小值-1 

（2）位數：最小位數、最大位數、最小位數-1最大位數+一、輸入超長值、輸入整數 

（3）異常值、特殊字符：輸入空白（NULL）、空格或"~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能致使系統錯誤的字符、禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交、word中的特殊功能，經過剪貼板拷貝到輸入框，分頁符，分節符相似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等、

輸入負整數、負小數、分數、輸入字母或漢字、小數（小數前0點捨去的狀況，多個小數點的狀況）、首位爲0的數字如0一、0二、科學計數法是否支持1.0E二、全角數字與半角數字、數字與字母混合、16進制，8進制數值、貨幣型輸入（容許小數點後面幾位）、

（4）安全性檢查：不能直接輸入就copy

三、日期型輸入框：

（1）合法性檢查：(輸入0日、1日、32日)、月輸入[一、三、五、七、八、十、12]、日輸入[31]、月輸入[四、六、九、11]、日輸入[30][31]、輸入非閏年，月輸入[2]，日期輸入[2八、29]、輸入閏年，月輸入[2]、日期輸入[2九、30]、月輸入[0、一、十二、13]

 (2)異常值、特殊字符：輸入空白或NULL、輸入~！@#￥%……&*（）{}[]等可能致使系統錯誤的字符

（3）安全性檢查：不能直接輸入，就copy，是否數據檢驗出錯？

四、信息重複:在一些須要命名,且名字應該惟一的信息輸入重複的名字或ID,看系統有沒有處理,會否報錯,重名包括是否區分大小寫,以及在輸入內容的先後輸入空格,系統是否做出正確處理.

7.二、搜索功能

若查詢條件爲輸入框，則參考輸入框對應類型的測試方法

一、功能實現：

（1）若是支持模糊查詢，搜索名稱中任意一個字符是否能搜索到

（2）比較長的名稱是否能查到

（3）輸入系統中不存在的與之匹配的條件

（4）用戶進行查詢操做時，通常狀況是不進行查詢條件的清空，除非需求特殊說明。

二、組合測試：

（1）不一樣查詢條件之間來回選擇，是否出現頁面錯誤（單選框和多選框最容易出錯）

（2）測試多個查詢條件時，要注意查詢條件的組合測試，可能不一樣組合的測試會報錯。

 

7.3添加、修改功能

一、特殊鍵：（1）是否支持Tab鍵 （2）是否支持回車鍵

二、提示信息：（1）不符合要求的地方是否有錯誤提示

三、惟一性：（1）字段惟一的，是否能夠重複添加，添加後是否能修改成已存在的字段（字段包括區分大小寫以及在輸入的內容先後輸入空格，保存後，數據是否真的插入到數據庫中，注意保存後數據的正確性）

四、數據 正確性：

（1）對編輯頁的每一個編輯項進行修改，點擊保存，是否能夠保存成功，檢查想關聯的數據是否獲得更新。

（2）進行必填項檢查（便是否給出提示以及提示後是否依然把數據存到數據庫中；是否提示後出現頁碼錯亂等）

（3）是否可以連續添加（針對特殊狀況）

（4）在編輯的時候，注意編輯項的長度限制，有時在添加的時候有，在編輯的時候卻沒有（注意要添加和修改規則是否一致）

（5）對於有圖片上傳功能的編輯框，若不上傳圖片，查看編輯頁面時是否顯示有默認的圖片，若上傳圖片，查看是否顯示爲上傳圖片

（6）修改後增長數據後，特別要注意查詢頁面的數據是否及時更新，特別是在首頁時要注意數據的更新。

（7）提交數據時，連續屢次點擊，查看系統會不會連續增長几條相同的數據或報錯。

（8）若結果列表中沒有記錄或者沒選擇某條記錄，點擊修改按鈕，系統會拋異常。

 

7.四、刪除功能

一、特殊鍵：（1）是否支持Tab鍵 （2）是否支持回車鍵

二、提示信息：（1）不選擇任何信息，直接點擊刪除按鈕，是否有提示（2）刪除某條信息時，應該有確認提示

三、數據 實現：（1）是否能連續刪除多個產品（2）當只有一條數據時，是否能夠刪除成功 （3）刪除一條數據後，是否能夠添加相同的數據（4）如系統支持批量刪除，注意刪除的信息是否正確 （5）若有全選，注意是否把全部的數據刪除（6）刪除數據時，要注意相應查詢頁面的數據是否及時更新 （7）如刪除的數據與其餘業務數據關聯，要注意其關聯性（如刪除部門信息時，部門下游員工，則應該給出提示）（8）若是結果列表中沒有記錄或沒有選擇任何一條記錄，點擊刪除按鈕系統會報錯。

 

如：某一功能模塊具備最基本的增刪改查功能，則須要進行如下測試

單項功能測試（增長、修改、查詢、刪除）

增長——>增長——>增長 （連續增長測試）

增長——>刪除

增長——>刪除——>增長 （新增長的內容與刪除內容一致）

增長——>修改——>刪除

修改——>修改——>修改 （連續修改測試）

修改——>增長（新增長的內容與修改前內容一致）

修改——>刪除

修改——>刪除——>增長 （新增長的內容與刪除內容一致）

刪除——>刪除——>刪除 （連續刪除測試）

 

7.五、註冊、登錄模塊

一、註冊功能：

（1）註冊時，設置密碼爲特殊版本號，檢查登陸時是否會報錯

（2）註冊成功後，頁面應該以登錄狀態跳轉到首頁或指定頁面

（3）在註冊信息中刪除已輸入的信息，檢查是否能夠註冊成功。

二、登錄 功能：

（1）輸入正確的用戶名和正確的密碼

（2）輸入正確的用戶名和錯誤的密碼

（3）輸入錯誤的用戶名和正確的密碼

（4）輸入錯誤的用戶名和錯誤的密碼

（5）不輸入用戶名和密碼（均爲空格）

（6）只輸入用戶名，密碼爲空

（7）用戶名爲空，只輸入密碼

（8）輸入正確的用戶名和密碼，可是不區分大小寫

（9）用戶名和密碼包括特殊字符

（10）用戶名和密碼輸入超長值

（11）已刪除的用戶名和密碼

（12）登陸時，當頁面刷新或從新輸入數據時，驗證碼是否更新

 

7.六、上傳圖片測試

一、功能 實現：

（1）文件類型正確、大小合適

（2）文件類型正確，大小不合適

（3）文件類型錯誤，大小合適

（4）文件類型和大小都合適，上傳一個正在使用中的圖片

（5）文件類型大小都合適，手動輸入存在的圖片地址來上傳

（6）文件類型和大小都合適，輸入不存在的圖片地址來上傳

（7）文件類型和大小都合適，輸入圖片名稱來上傳

（8）不選擇文件直接點擊上傳，查看是否給出提示

（9）連續屢次選擇不一樣的文件，查看是否上傳最後一次選擇的文件

 

7.七、查詢結果列表

一、功能 實現：

（1）列表、列寬是否合理

（2）列表數據太寬有沒有提供橫向滾動

（3）列表的列名有沒有與內容對應

（4）列表的每列的列名是否描述的清晰

（5）列表是否把沒必要要的列都顯示出來

（6）點擊某列進行排序，是否會報錯（點擊查看每一頁的排序是否正確）

（7）雙擊或單擊某列信息，是否會報錯

 

7.八、返回鍵檢查

一、一條已經成功提交的記錄，返回後再提交，是否作了處理

二、檢查屢次使用返回鍵的狀況，在有返回鍵的地方，返回到原來的頁面屢次，查看是否會出錯

 

7.九、回車鍵檢查

一、在輸入結果後，直接按回車鍵，看系統如何處理，是否會報錯

 

7.十、刷新鍵檢查

一、在Web系統中，使用刷新鍵，看系統如何處理，是否會報錯

 

7.十一、直接URL連接檢查

一、在Web系統中，在地址欄直接輸入各個功能頁面的URL地址，看系統如何處理，是否可以直接連接查看（匿名查看），是否有權限控制，是否直接執行，並返回相應結果頁；

 

7.十二、界面和易用性測試

一、風格、樣式、顏色是否協調

二、界面佈局是否整齊、協調（保證所有顯示出來的，儘可能不要使用滾動條

三、界面操做、標題描述是否恰當（描述有歧義、注意是否有錯別字）

四、操做是否符合人們的常規習慣（有沒有把類似的功能的控件放在一塊兒，方便操做）

五、提示界面是否符合規範（不該該顯示英文的cancel、ok，應該顯示中文的肯定等）

六、界面中各個控件是否對齊

七、日期控件是否可編輯

八、日期控件的長度是否合理，以修改時能夠把時間所有顯示出來爲準

九、查詢結果列表列寬是否合理、標籤描述是否合理

十、查詢結果列表太寬沒有橫向滾動提示

十一、對於信息比較長的文本，文本框有沒有提供自動豎直滾動條

十二、數據錄入控件是否方便

1三、有沒有支持Tab鍵，鍵的順序要有條理，不亂跳

1四、有沒有提供相關的熱鍵

1五、控件的提示語描述是否正確

1六、模塊調用是否統一，相同的模塊是否調用同一個界面

1七、用滾動條移動頁面時，頁面的控件是否顯示正常

1八、日期的正確格式應該是XXXX-XX-XX或XXXX-XX-XX XX:XX:XX

1九、頁面是否有多餘按鈕或標籤

20、窗口標題或圖標是否與菜單欄的統一

2一、窗口的最大化、最小化是否能正確切換

2二、對於正常的功能，用戶能夠沒必要閱讀用戶手冊就能使用

2三、執行風險操做時，有確認、刪除等提示嗎

2四、操做順序是否合理

2五、正確性檢查：檢查頁面上的form, button, table, header, footer,提示信息，還有其餘文字拼寫，句子的語法等是否正確。

2六、系統應該在用戶執行錯誤的操做以前提出警告，提示信息.

2七、頁面分辨率檢查，在各類分辨率瀏覽系統檢查系統界面友好性。

2八、合理性檢查：作delete, update, add, cancel, back等操做後，查看信息回到的頁面是否合理。

2九、檢查本地化是否經過：英文版不該該有中文信息，英文翻譯準確，專業。

 

7.1三、兼容性測試

兼容性測試不僅是指界面在不一樣操做系統或瀏覽器下的兼容，有些功能方面的測試，也要考慮到兼容性，

包括操做系統兼容和應用軟件兼容，可能還包括硬件兼容

好比涉及到ajax、jquery、javascript等技術的，都要考慮到不一樣瀏覽器下的兼容性問題。

 

7.1四、連接測試

主要是保證連接的可用性和正確性，它也是網站測試中比較重要的一個方面。

可使用特定的工具如XENU來進行連接測試。

1導航測試
導航描述了用戶在一個頁面內操做的方式，在不一樣的用戶接口控制之間，例如按鈕、對話框、列表和窗口等；或在不一樣的鏈接頁面之間。經過考慮下列問題，能夠決定一個Web應用系統是否易於導航：導航是否直觀？Web系統的主要部分是否可經過主頁存取？Web系統是否須要站點地圖、搜索引擎或其餘的導航幫助？
在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。
導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。
Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。
2圖形測試
在Web應用系統中，適當的圖片和動畫既能起到廣告宣傳的做用，又能起到美化頁面的功能。一個Web應用系統的圖形能夠包括圖片、動畫、邊框、顏色、字體、背景、按鈕等。圖形測試的內容有：
（1）要確保圖形有明確的用途，圖片或動畫不要胡亂地堆在一塊兒，以避免浪費傳輸時間。Web應用系統的圖片尺寸要儘可能地小，而且要能清楚地說明某件事情，通常都連接到某個具體的頁面。
（2）驗證全部頁面字體的風格是否一致。
（3）背景顏色應該與字體顏色和前景顏色相搭配。
（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮，最好能使圖片的大小減少到30k如下
（5）最後，須要驗證的是文字迴繞是否正確。若是說明文字指向右邊的圖片，應該確保該圖片出如今右邊。不要由於使用圖片而使窗口和段落排列古怪或者出現孤行。
一般來講，使用少量或儘可能不使用背景是個不錯的選擇。若是您想用背景，那麼最好使用單色的，和導航條一塊兒放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。
 

7.1五、業務流程測試（主要功能測試）

業務流程，通常會涉及到多個模塊的數據，因此在對業務流程測試時，首先要保證單個模塊功能的正確性，其次就要對各個模塊間傳遞的數據進行測試，這每每是容易出現問題的地方，測試時必定要設計不一樣的數據進行測試。

7.1六、安全性測試

（1）SQL注入（好比登錄頁面）

（2）XSS跨網站腳本攻擊：程序或數據庫沒有對一些特殊字符進行過濾或處理，致使用戶所輸入的一些破壞性的腳本語句可以直接寫進數據庫中，瀏覽器會直接執行這些腳本語句，破壞網站的正常顯示，或網站用戶的信息被盜,構造腳本語句時，要保證腳本的完整性。

　　document.write("abc")

　　<script>alter("abc")</script>

（3）URL地址後面隨便輸入一些符號，並儘可能是動態參數靠後

（4）驗證碼更新問題

（5）如今的Web應用系統基本採用先註冊，後登錄的方式。所以，必須測試有效和無效的用戶名和密碼，要注意到是否大小寫敏感，能夠試多少次的限制，是否能夠不登錄而直接瀏覽某個頁面等。

（6）Web應用系統是否有超時的限制，也就是說，用戶登錄後在必定時間內（例如15分鐘）沒有點擊任何頁面，是否須要從新登錄才能正常使用。

（7）爲了保證Web應用系統的安全性，日誌文件是相當重要的。須要測試相關信息是否寫進了日誌文件、是否可追蹤。

（8）當使用了安全套接字時，還要測試加密是否正確，檢查信息的完整性。

（9）服務器端的腳本經常構成安全漏洞，這些漏洞又經常被黑客利用。因此，還要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。

 

7.1七、性能測試

1鏈接速度測試

用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒鐘），用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。

2負載測試
負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？

3壓力測試
負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。
進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。
壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。

 

備註：

一、負載/壓力測試應該關注什麼

測試須要驗證系統可否在同一時間響應大量的用戶，在用戶傳送大量數據的時候可否響應，系統可否長時間運行。可訪問性對用戶來講是極其重要的。若是用戶獲得「系統忙」的信息，他們可能放棄，並轉向競爭對手。系統檢測不只要使用戶可以正常訪問站點，在不少狀況下，可能會有黑客試圖經過發送大量數據包來攻擊服務器。出於安全的緣由，測試人員應該知道當系統過載時，須要採起哪些措施，而不是簡單地提高系統性能。

1）瞬間訪問高峯
若是您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內可以響應上百萬的請求。負載測試工具可以模擬X個用戶同時訪問測試站點。

2）每一個用戶傳送大量數據
網上書店的多數用戶可能只訂購1-5書，可是大學書店可能會訂購5000本有關心理學介紹的課本?或者一個祖母爲她的50個兒孫購買聖誕禮物(固然每一個孩子都有本身的郵件地址)系統能處理單個用戶的大量數據嗎?

3）長時間的使用
若是站點用於處理鮮花訂單，那麼至少但願它在母親節前的一週內能持續運行。若是站點提供基於web的email服務，那麼點最好能持續運行幾個月，甚至幾年。可能須要使用自動測試工具來完成這種類型的測試，由於很難經過手工完成這些測試。你能夠想象組織100我的同時點擊某個站點。可是同時組織100000我的呢。一般，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。並且，測試工具安裝完成以後，再次使用的時候，只要點擊幾下。
採起措施：採用性能測試工具WAS、ACT，LR等協助進行測試
 

 

7.1八、測試中應該注意的其餘狀況

一、在測試時，與網絡有關的步驟或者模塊必須考慮到斷網的狀況

二、每一個頁面都有相應的Title，不能爲空，或者顯示「無標題頁」

三、在測試的時候要考慮到頁面出現滾動條時，滾動條上下滾動時，頁面是否正常

四、URL不區分大小寫，大小寫不敏感

五、、對於電子商務網站，當用戶併發購買數量大於庫存的數量時，系統如何處理

六、測試數據避免單純輸入「123」、「abc「之類的，讓測試數據儘可能接近實際

七、進行測試時，儘可能不要用超級管理員進行測試，用新建的用戶進行測試。測試人員儘可能不要使用同一個用戶進行測試

八、提示信息：提示信息是否完整、正確、詳細

九、幫助信息：是否提供幫助信息，幫助信息的表現形式（頁面文字、提示信息、幫助文件），幫助信息是否正確、詳細

十、可擴展性：是否由升級的餘地，是否保留了接口

十一、穩定性：運行所需的軟硬件配置，佔用資源狀況，出現問題時的容錯性，對數據的保護

十二、運行速度：運行的快慢，帶寬佔用狀況

 8、測試工具

8.一、Web開發調試工具

　　技術沒有所謂的開發及測試的界限，工具亦是。Web開發調試工具怎可僅被開發使用，這些工具也是測試工程師的利器（此類工具的掌握可說是Web測試工做者必備的基本技能）。

　　瀏覽器調試

　　現在各類瀏覽器氾濫，但從內核上而言，瀏覽器的種類可分爲IE內核、谷歌內核（Webkit）、火狐內核；還有IE內核+Webkit內核，即雙核的瀏覽器。好比傲遊瀏覽器、360極速瀏覽器、搜狗高速瀏覽器等。因此，針對Web端B/S測試（網站or網頁應用等），主要會在IE、Chrome、FireFox這三個典型的瀏覽器上進行測試。下面就這三個瀏覽器的開發者調試工具或插件作下簡單的介紹。

　（三者的基礎功能和使用方式大同小異，熟悉前端及網絡技術就能較易學會其用法。） 

　8.二、UI自動化測試

　　說到軟件測試工具，不少人第一反應會是自動化測試工具。但其實工具只是輔助，重要的是對自動化的理解，什麼狀況下適合作自動化？自動化如何分層？對應的自動化測試原理又是什麼？貌似有點扯遠了，但我的認爲這點再怎麼強調也不爲過，會用自動化測試工具離真正意義上的自動化測試還差得遠呢

　　言歸正傳，再提自動化測試，不少人會想到模仿真人操做的自動化，對於Web測試，即UI自動化測試。若是早幾年，可能我會提到QTP，但如今真心不推薦，現在用QTP的企業少之又少（相似諾基亞現在的使用率），固然也不是說QTP很差（HP畢竟燒了那麼多錢），缺點在於它過於龐大，且附加條件過多（正版License價格你懂的、且僅可VBS寫腳本）。

　Selenium

　　Selenium 是ThoughtWorks公司編寫的用於Web應用程序測試的工具。開源；支持多平臺，Linux、Windows、Mac；支持的多瀏覽器包括IE、Mozilla Firefox、Google Chrome等。Selenium測試直接運行在瀏覽器中(WebDriver)，就像真正的用戶在操做同樣，可進行一系列的系統功能測試。官網：www.selenium.org 

　Selenium的強大之處在於提供了諸多語言的開源框架，如 C#、Java、Pyhon、Ruby、PHP等，如有這些開發語言的基礎，可較輕鬆地結合並定製出適合的測試框架（也需配合對應的單元測試框架如NUnit、JUnit、PyUnit等）

　Selenium IDE

　　一個Firefox插件，可錄製回放，並可生成用例腳本（建議不要直接使用生成的腳本）。錄製回放功能對於需重複一樣操做的測試仍是蠻方便的。

　PhantomJS

　　PhantomJS 是一個基於 WebKit 的服務器端 JavaScript API。它全面支持web而不需瀏覽器支持，其快速，原生支持各類Web標準： DOM 處理, CSS 選擇器, JSON, Canvas, 和 SVG。 PhantomJS 能夠用於頁面自動化， 網絡監測， 網頁截屏 ，以及無界面測試等。官網：http://phantomjs.org/

　　PhantomJS 是無界面測試，通俗來講就是不會起瀏覽器，這大大提升了運行的效率。

　　PhantomJS可結合Selenium一塊兒使用，發揮更大效用。

三、接口（API）自動化測試

　　單獨對測試接口（API）是很是有必要且有成效的。以前介紹的Web調試工具能方便地截獲接口，可查看對應的Request及Response等，可Replay，可查看對應接口的響應時間，甚至可作接口的性能測試（Fiddler功能支持）。只是上述說的這些工具 ，並不能把接口保存下來，自動運行並作驗證。

　　天然，咱們能夠自寫接口的自動化測試腳本，各語言也有各類現成的開源框架，但如果不熟悉開發語言的測試者，一樣也有很多接口自動化測試工具可供使用，推薦fiddler、PostMan及SoapUI這兩個工具。

3.1Fiddler

　　Fiddler是最強大最好用的Web調試工具，沒有之一 （遺憾的是隻能Windows下使用）。官網: www.fiddler2.com

　Fiddler能記錄全部客戶端和服務器的http和https請求，容許監視，設置斷點，甚至修改輸入輸出數據，Fiddler包含了一個強大的基於事件腳本的子系統，而且能使用.net語言進行擴展。

　　對HTTP 協議越瞭解，就能越掌握Fiddler的使用方法；越使用Fiddler，就越能幫助你瞭解HTTP協議。

3.2.PostMan

　　Postman如今是一個Chrome App（之前是Chrome的插件），官網：http://www.getpostman.com/ ；經過Chrome插件入口可輕鬆安裝Postman。

Postman的功能很是強大，能基本知足接口的自動化需求（有些高級功能需收費），詳情 可參考這篇：基於Postman的API自動化測試。

3.3.SoapUI

　　SoapUI是一個開源測試工具，經過soap/http來檢查、調用、實現Web Service的功能/負載/符合性測試。官網：https://www.soapui.org/

　　SoapUI 是一個完整的自動化測試解決方案。它提供了業界領先的技術和標準的支持，包含SOAP和REST的Web服務、JMS企業消息層，數據庫，以及豐富的互聯網應用等。

　　SoapUI 用戶操做界面直觀、易用，而實際功能十分強大且可擴展。詳細使用可參考官網文檔：https://www.soapui.org/open-source.html

　　SoapUI 還提供了命令行工具，方便加入至任務調度，或做爲構建過程當中的一個組成部分

四、性能測試

　　又有話說在前頭了，會用性能測試工具離真正意義上的性能測試差得遠得很！（仍是那句話，工具只是輔助，要明白爲什麼用、如何用、以及用好纔是關鍵~）

　　略無奈的是，不少作性能測試是這樣的：公司說讓他們對系統作個性能測試，因而就從網上找了點LoadRunner的使用說明並安裝（固然是破解版），目的就爲出份報告。對於一些大公司的專業性能測試人員來講，這個很好笑，但這種狀況是存在且廣泛的，一些所謂的專作性能測試的外包也是這麼忽悠的（碰到過的真事….）

4.1JMeter

　　Apache JMeter是Apache組織開發的基於Java的壓力測試工具。用於對軟件作壓力測試，它最初被設計用於Web應用測試，但後來擴展到其餘測試領域。

　　JMeter 能夠用於對服務器、網絡或對象模擬巨大的負載，來在不一樣壓力類別下測試它們的強度和分析總體性能。

4.2LoadRunner

　　HP老牌的性能測試工具，不得不說功能及其強大。

　　LoadRunner，是一種預測系統行爲和性能的負載測試工具。經過以模擬上千萬用戶實施併發負載及實時性能監測的方式來確認和查找問題，LoadRunner可以對整個企業架構進行測試。企業使用LoadRunner能最大限度地縮短測試時間，優化性能和加速應用系統的發佈週期。 LoadRunner可適用於各類體系架構的自動負載測試，能預測系統行爲並評估系統性能。