web端測試總結

時間 2019-11-08

標籤 web 測試總結欄目 HTML 简体版

原文原文鏈接

一、數值型輸入框：javascript

條件：demcial(x,y) ,界面顯示小數點到y位

一般要檢查如下幾點：

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

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

（3）空格檢查：中文空格、英文空格、輸入空白（NULL）

（4）特殊字符："~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能致使系統錯誤的字符 —— 禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交

（5）複製粘貼：word中的特殊功能，經過剪貼板拷貝到輸入框，分頁符，分節符相似公式的上下標等、數值的特殊符號如∑，㏒，㏑，∏，+，-等

（6）正數值：輸入正整數、正小數、正分數

（7）負數值：輸入負整數、負小數、負分數

（8）小數點檢查：輸入的小數點多於一個、輸入數字只有一個小數點，小數點左邊>(x-y)個有效位、輸入數字只有一個小數點，小數點右邊>Y個有效位、輸入數字只有一個小數點，小數位數小於<y個有效位、輸入數字只有一個小數點，小數位數＝y個有效位

（9）輸入字母或漢字

（10）首位爲0的整數：首位爲0的整數如0一、02

（11）科學計數法檢查：科學計數法是否支持1.0E2

（12）混合輸入：全角數字與半角數字、數字與字母混合、16進制，8進制數值、貨幣型輸入（容許小數點後面幾位）

（13）末位爲0的整數：末位爲0的整數如10，20，30

（14）末位爲0的小數：末位爲0的小數如1.10，1.200

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

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

二、普通文本輸入框（textfield）：

（1）空格檢查：輸入爲空白或中英文空格（輸入的字符間有空格、字符前有空格、字符後有空格、字符先後有空格）

（2）邊界值：最大值、最小值、最大值+一、最小值-1 、輸入超長字符好比把整個文章拷貝過去）

（3）輸入字母或漢字或數字

（4）特殊字符："~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能致使系統錯誤的字符 —— 禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交

（5）安全性檢查：輸入特殊字符串（null,NULL, ,javascript,<script>,</script>,<title>,<html>,<td>,\n）、輸入腳本函數(<script>alert("abc")</script>)、doucment.write("abc")、<b>hello</b>），不能直接輸入就copy，測試文本框可否執行

（6）特殊數字的斷定：如輸入"10101010"二進制字符系統的判斷與報錯

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

三、字符型輸入框：

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

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

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

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

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

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

四、搜索框輸入框：

條件：輸入標題和內容中的關鍵詞，若是有匹配的就顯示出結果，沒有匹配就不顯示，容許輸入任意字符

一般要檢查如下幾點：

（1）空格檢查：輸入爲空白或中英文空格（輸入的字符間有空格、字符前有空格、字符後有空格、字符先後有空格）

（2）長度檢查：最小長度、最大長度、最小長度-一、最大長度+一、輸入超長字符好比把整個文章拷貝過去（若是有的話）
（3）特殊字符："~!@#$%^&*()_+{}|[]\:"<>?;',./?;:'-=等可能致使系統錯誤的字符 —— 禁止直接輸入特殊字符時，嘗試使用粘貼拷貝查看是否能正常提交
（4）存在的數據：輸入存在的搜索內容
（5）不存在的數據：輸入不存在的搜索內容

（6）輸入字母或漢字或數字

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

若有必要再測如下幾點：

一、在輸入框處雙擊鼠標是否出現下拉菜單記憶已搜索過的內容
二、在輸入框單擊鼠標左鍵,是否有光標出現
三、在輸入框單擊鼠標左鍵,是否有光標出現，光標出現後使用"Tab"鍵後,"搜索"按鈕是否出現選定TIP
四、在輸入框點擊鼠標右鍵是否出現Menu,Menu內容依次爲"撤消"、"複製"、"粘貼"、"刪除"、"全選"(具體狀況視實際狀況而定)
五、檢查以上Menu出現的選擇模塊是否可正常使用
六、在輸入框輸入任意長度字母、數字、漢字,雙擊鼠標左鍵,觀察輸入項目可否被所有選中
七、輸入正則表達式

八、用快捷鍵或鼠標粘貼內容看，測試搜索框是否能執行

五、多行文本框（textview）：

（1）容許回車換行

（2）保存後再顯示可以保存輸入的格式和內容

（3）僅輸入回車換行，檢查可否正確保存（若能，檢查保存結果；若不能，查看是否有正常提示）

（4）輸入類型：可輸入的類型（漢字、字母、數字）

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

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

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

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

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

六、日期型輸入框：

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

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

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

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

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

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

查詢：

一、功能實現：

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

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

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

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

（5）輸入系統主存在的與之匹配的條件

（6）查詢條件輸入爲空，系統中如何處理

（7）查詢條件是否有重置功能

二、組合測試：

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

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

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

四、提示信息：不符合要求的地方是否有錯誤提示

七、某功能模塊的增刪改查

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

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

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

增長——>刪除

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

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

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

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

修改——>刪除

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

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

考慮的測試點：

新增：

0）新增，是否能夠正常跳轉正確的頁面；正確跳轉後，頁面展現是否符合設計

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

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

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

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

5）提示信息：不符合要求的地方是否有錯誤提示

6）特殊鍵：1）是否支持Tab鍵 2）是否支持回車鍵

修改：

0）修改，是否能夠正常跳轉正確的頁面；正確跳轉後，頁面展現是否符合設計

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

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

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

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

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

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

7）若有多選或全選按鈕，是否能夠多選或全選進行修改操做，如不能，是否有提示

8）提示信息：不符合要求的地方是否有錯誤提示

9）特殊鍵：1）是否支持Tab鍵 2）是否支持回車鍵

刪除：

1）若是結果列表中沒有記錄或沒有選擇任何一條記錄，點擊刪除按鈕，是否有提示

2）刪除某條信息時，應該有確認提示

3）是否能連續刪除多條數據

4）當只有一條數據時，是否能夠刪除成功

5）刪除一條數據後，是否能夠添加相同的數據

6）如系統支持批量刪除，注意刪除的信息是否正確

7）若有全選，注意是否把全部的數據刪除

8）刪除數據時，要注意相應查詢頁面的數據是否及時更新

9）如刪除的數據與其餘業務數據關聯，要注意其關聯性，若可刪除，其餘業務數據是否更新爲清空

10）如刪除的數據與其餘業務數據關聯展現，要判斷其關聯展現可否進行刪除

11）特殊鍵：1）是否支持Tab鍵 2）是否支持回車鍵

查詢：

一、功能實現：

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

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

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

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

（5）輸入系統主存在的與之匹配的條件

（6）查詢條件輸入爲空，系統中如何處理

（7）查詢條件是否有重置功能

二、組合測試：

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

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

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

四、提示信息：不符合要求的地方是否有錯誤提示

八、註冊模塊：

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

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

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

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

（5）註冊時，用戶名密碼輸入類型檢查

（6）註冊時，用戶名密碼長度檢查（最小長度、最大長度、最小長度-一、最大長度+1）

（7）註冊時，用戶名密碼爲空/空格檢查

（8）註冊時，用戶名密碼特殊字符檢查

（9）註冊時，用戶名密碼非法數據檢查

（10）註冊時，用戶名密碼正常輸入，可否註冊成功

（11）快速重複點擊註冊按鈕屢次，系統會否報錯

（12）不一樣電腦端：a電腦登陸，而後複製網址，而後b電腦打開這個網址，可否訪問，如不能訪問，是否有提示

九、登錄模塊：

（1）正確的用戶名、密碼

（2）正確的用戶名、錯誤的密碼

（3）錯誤的用戶名、正確的密碼

（4）錯誤的用戶名、密碼

（5）用戶名、密碼都爲空格

（6）用戶名爲空格、密碼不爲空格

（7）用戶名不爲空格、密碼爲空格

（8）用戶名、密碼都爲空

（9）用戶名爲空，密碼不爲空

（10）用戶名不爲空、密碼爲空

（11）正確的用戶名、密碼，可是不區分大小寫

（12）用戶名和密碼包含特殊字符

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

（14）已刪除的用戶名和密碼，可否登陸

（15）不一樣電腦端登陸：a電腦登陸，而後複製網址（地址中可能包括你的登陸後的信息 cookie之類的），而後b電腦打開這個網址，可否登陸訪問，如不能訪問，是否有提示

（16）未註冊的用戶名和密碼

（17）複製粘貼正確的用戶名、密碼

（18）快速重複點擊登錄按鈕屢次，系統會否報錯

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

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

（21）是否支持多地登陸，若是不支持，是否有提示

（22）登陸成功後，可否正常跳轉指定的頁面

（23）瀏覽器安F12查看密碼是明文仍是加密後發送在請求中

10、某功能模塊的刷新、導出、文件下載功能

文件下載：

0）選擇結果列表中某個文件，點擊下載，是否能夠正常下載

1）若是結果列表中沒有記錄或沒有選擇任何一條記錄，點擊下載按鈕，是否有提示

2）若有多選或全選按鈕，是否能夠多選或全選進行下載操做，如不能，是否有提示

3）下載文件後，檢查下載路徑是否有下載的文件，下載文件對不對

4）下載方式是否正確

5）下載文件後，查看下載文件是否保存成功

刷新：

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

導出：

0）若是結果列表中沒有記錄或沒有選擇任何一條記錄，直接點擊導出按鈕，是否有提示

1）結果列表中有記錄，未選擇條件，點擊導出按鈕，是否導出成功，導出的數據和結果列表是否一致

2）結果列表中有記錄，選擇條件，點擊導出按鈕，是否導出成功，導出的數據和結果列表是否一致

3）結果列表中有記錄，點擊導出按鈕，導出的數據<=1萬，是否能夠正常導出，系統會否拋錯

4）結果列表中有記錄，點擊導出按鈕，導出的數據>萬，是否能夠正常導出，系統會否拋錯

11、某功能模塊的第一頁、上一頁、下一頁、最後一頁功能

第一頁：

1）當前數據頁面在第一頁時，上一頁和第一頁的按鈕是否須要置灰，能否點擊

2）當前頁面不在第一頁且當前的數據頁數大1頁時，上一頁和第一頁的按鈕可否正常顯示，能否點擊

1）當前數據頁面在第一頁時，上一頁和第一頁的按鈕是否須要置灰，能否點擊

2）當前頁面不在第一頁時，上一頁和第一頁的按鈕可否正常顯示，能否點擊

1）當前數據頁面在最後一頁時，下一頁和最後一頁的按鈕是否須要置灰，能否點擊
2）當前頁面不在最後一頁且當前的頁數大於1頁時，下一頁和最後一頁的按鈕可否正常顯示，能否點擊

最後一頁：

1）當前數據頁面在最後一頁時，下一頁和最後一頁的按鈕是否須要置灰，能否點擊
2）當前頁面不在最後一頁且當前數據的頁數大於1頁時，下一頁和最後一頁的按鈕可否正常顯示，能否點擊

十二、查詢結果列表

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

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

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

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

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

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

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

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

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

1三、文件上傳

文件上傳-命名檢查：

1）符合命名規範、文件類型大小都合適的文件上傳

2）不符合命名規範、文件類型大小都合適的文件上傳

3）符合命名長度規範、文件類型大小都合適的文件上傳

4）不符合命名長度規範、文件類型大小都合適的文件上傳

5）文件命名長度的名稱過長。html

6）文件命名長度的名稱達到最大長度（中文，英文或混在一塊兒）上傳後名稱顯示，頁面排版-----------頁面顯示正常java

7）文件名稱中包含特殊字符-------------根據需求而定jquery

8）文件名稱全爲中文--------------------根據需求而定web

9）文件名稱全爲英文--------------------根據需求而定ajax

10）文件名稱爲中、英混合-----------------根據需求而定正則表達式

文件上傳-文件路徑檢查：

1）文件類型大小都合適，手動輸入正確且不存在的文件路徑上傳

2）文件類型大小都合適，手動輸入錯誤的文件路徑上傳

3）文件類型大小都合適，手動輸入正確且存在的文件路徑上傳

4）選擇自動帶出來的文件路徑上傳

5）按F12篡改爲正確的文件路徑上傳

6）按F12篡改爲錯誤的文件路徑上傳

文件上傳-文件名稱、內容檢查：

1）文件類型大小都合適，手動輸入正確且不存在的文件名稱上傳

2）文件類型大小都合適，手動輸入錯誤的文件名稱上傳

3）文件類型大小都合適，手動輸入正確且存在的文件名稱上傳

4）文件類型大小都合適，文件內容相同，名稱不一樣的文件上傳

5）文件類型大小都合適，文件內容不一樣，名稱相同的文件上傳

6）文件類型大小都合適視頻，文件內容相同，名稱相同，上傳數據庫

7）文件類型大小都合適，文件內容不一樣，名稱不一樣，上傳瀏覽器

文件上傳-文件類型檢查：

1）符合文件類型、大小合適的文件上傳

2）不符合文件類型、大小合適的文件上傳

文件上傳-文件大小檢查：

1）符合文件類型、大小<=限制大小的文件上傳

2）符合文件類型、大小>限制大小的文件上傳

3）文件上傳時，存儲空間已滿

4）文件大小超過存儲剩餘空間

文件上傳-其它功能檢查：

1）修改選擇但未上傳的文件，可否上傳

2）文件類型和大小都合適，選擇一個打開的文件，可否上傳

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

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

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

6）選擇符合要求的文件上傳

7）上傳成功的文件、名稱顯示----------顯示正常（根據需求）

8）查看，下載上傳成功的文件--------上傳的圖片可查看或下載（根據需求）

9）刪除上傳成功的文件-------------可刪除（根據需求）

10）替換上傳成功的文件-------------可替換（根據需求）

11）上傳文件是否支持中文名稱--------根據需求而定

1四、業務流程測試（主要功能測試），通常這種狀況都須要造測試數據進行模擬

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

1五、返回鍵檢查

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

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

1六、直接URL連接檢查

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

網站測試的主要方面

1 功能測試（包含基本功能測試和數據準確性校驗）

對於網站的測試而言，每個獨立的功能模塊須要單獨的測試用例的設計導出，主要依據爲《需求規格說明書》及《詳細設計說明書》，對於應用程序模塊須要設計者提供基本路徑測試法的測試用例。

B/S結構實現的功能可能主要的就在於提交數據，處理數據等，若是有固定的操做流程能夠考慮自動化測試工具的錄製功能，編寫可重複使用的腳本代碼，能夠在測試、迴歸測試時運行以便減輕測試人員工做量。

連接測試（根據需求是否須要指導用戶使用）

連接是web應用系統的一個很重要的特徵，主要是用於頁面之間切換跳轉，指導用戶去一些不知道地址的頁面的主要手段，連接測試通常關注三點：

（1）連接是否按照既定指示那樣，確實連接到了該連接的界面

（2）測試該連接所連接的頁面是否真的存在

（3）保證系統中沒有單獨存在的頁面（即沒有連接指向，只能經過正確的URL地址才能訪問）

連接測試能夠自動進行，如今已經有許多工具能夠採用。連接測試必須在集成測試階段完成，也就是說，在整個Web應用系統的全部頁面開發完成以後進行連接測試。

Xenu------主要測試連接的正確性的工具，惋惜的是對於動態生成的頁面的測試會出現一些錯誤。

表單測試

1）當用戶給Web應用系統管理員提交信息時，就須要使用表單操做，例如用戶註冊、登錄、信息提交等。在這種狀況下，咱們必須測試提交操做的完整性，以校驗提交給服務器的信息的正確性。

例如：用戶填寫的出生日期與職業是否恰當，填寫的所屬省份與所在城市是否匹配等。若是使用了默認值，還要檢驗默認值的正確性。

若是表單只能接受指定的某些值，則也要進行測試。例如：只能接受某些字符，測試時能夠跳過這些字符，看系統是否會報錯。

2）要測試這些程序，須要驗證服務器能正確保存這些數據，並且後臺運行的程序能正確解釋和使用這些信息。

3）B/S結構實現的功能可能主要的就在這裏，提交數據，處理數據等若是有固定的操做流程能夠考慮自動化測試工具的錄製功能，編寫可重複使用的腳本代碼，能夠在測試、迴歸測試時運行以便減輕測試人員工做量。

4）咱們對UM子系統中各個功能模塊中的各項功能進行逐一的測試，主要測試方法爲：邊界值測試、等價類測試，以及異常類測試。測試中要保證每種類型都有2個以上的典型數值的輸入，以確保測試輸入的全面性。

cookie測試（若是web應用系統使用cookie）

1）Cookies一般用來存儲用戶信息和用戶在某應用系統的操做，當一個用戶使用Cookies訪問了某一個應用系統時，Web服務器將發送關於用戶的信息，把該信息以Cookies的形式存儲在客戶端計算機上，這可用來建立動態和自定義頁面或者存儲登錄等信息。

2）若是Web應用系統使用了Cookies，就必須檢查Cookies是否能正常工做並且對這些信息已經加密。若是使用 cookie 來統計次數，須要驗證次數累計正確。測試的內容可包括Cookies是否起做用，是否按預約的時間進行保存，刷新對Cookies有什麼影響等。

設計語言測試

1）Web設計語言版本的差別能夠引發客戶端或服務器端嚴重的問題，例如使用哪一種版本的HTML等。

2）當在分佈式環境中開發時，開發人員都不在一塊兒，這個問題就顯得尤其重要。

3）除了HTML的版本問題外，不一樣的腳本語言，例如Java、JavaScript、 ActiveX、VBScript或Perl等也要進行驗證。

數據庫測試

1）在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。

在Web應用中，最經常使用的數據庫類型是關係型數據庫，可使用SQL對信息進行處理。

2）在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。

數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。

2 安全性測試（轉）

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

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

　　document.write("abc")

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

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

4）驗證碼更新問題

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

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

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

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

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

3 界面測試和易用性測試

1）界面測試

主要包括如下幾個方面的內容：

（1）站點地圖和導航條：位置是否合理、是否能夠導航等內容佈局--佈局是否合理；簡介說明--說明文字是否合理，位置是否正確

（2）背景/色調：是否正確、美觀，是否符合用戶需求

（3）頁面：在窗口中的顯示是否正確、美觀（在調整瀏覽器窗口大小時，屏幕刷新是否正確）；表單樣式--大小，格式，是否對提交數據進行驗證（若是在頁面部分進行驗證的話）等

（4）鏈接：鏈接的形式、位置是否易於理解等

web測試的主要頁面元素：

（1）頁面元素的容錯性列表（如輸入框、時間列表或日曆）

（2）頁面元素清單（爲實現功能，是否將所須要的元素所有都列出來了，如按鈕、單選框、複選框、列表框、超鏈接、輸入框等等）

（3）頁面元素的容錯性是否存在

（4）頁面元素的容錯性是否正確

（5）頁面元素基本功能是否實現（如文字特效、動畫特效、按鈕、超鏈接）

（6）頁面元素的外形、擺放位置（如按鈕、列表框、核選框、輸入框、超鏈接等）

（7）頁面元素是否顯示正確（主要針對文字、圖形、簽章）

（8）元素是否顯示（元素是否存在）

（9）頁面元素清單（爲實現功能，是否將所須要的元素所有都列出來了，如按鈕、單選框、複選框、列表框、超鏈接、輸入框等等）

測試技術

一、經過頁面走查，瀏覽肯定使用的頁面是否符合需求，能夠結合兼容性測試對不用分辨率下頁面顯示效果，若是有影響應該交給設計人員提出解決方案。

二、能夠結合數據定義文檔查看錶單項的內容，長度等信息。

三、對於動態生成的頁面最好也能進行瀏覽查看。如Servelet部分能夠結合編碼規範，進行代碼走查。是否支持中文，若是數據用XM，封裝要作的工做會多一點等。

2）易用性測試

易用性測試七大要素：符合標準和規範,靈活性,正確性,直觀性,溫馨性,實用性,一致性

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

二、界面佈局是否整齊、協調（保證所有顯示出來的，儘可能不要使用滾動條）
三、界面操做、標題描述是否恰當（描述有歧義、注意是否有錯別字）
四、操做是否符合人們的常規習慣（有沒有把類似的功能的控件放在一塊兒，方便操做）
五、提示界面是否符合規範，有無中英文混合（不該該顯示英文的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九、檢查本地化是否經過：英文版不該該有中文信息，英文翻譯準確，專業
30、控件字體和大小是否一致，有無錯別字

4 兼容性測試

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

包括操做系統兼容和應用軟件兼容，可能還包括硬件兼容，好比涉及到ajax、jquery、javascript等技術的，都要考慮到不一樣瀏覽器下的兼容性問題。

5 性能測試（轉）

一、鏈接速度測試（鏈接速度測試指的是打開網頁的響應速度測試）

用戶鏈接到Web應用系統的速度根據上網方式的變化而變化，他們或許是電話撥號，或是寬帶上網。

當下載一個程序時，用戶能夠等較長的時間，但若是僅僅訪問一個頁面就不會這樣。若是Web系統響應時間太長（例如超過5秒），用戶就會因沒有耐心等待而離開。

另外，有些頁面有超時的限制，若是響應速度太慢，用戶可能還沒來得及瀏覽內容，就須要從新登錄了。

並且，鏈接速度太慢，還可能引發數據丟失，使用戶得不到真實的頁面。

二、負載測試(負荷測試指的是進行一些邊界數據的測試）——基本功能已經經過後進行的.能夠在集成測試階段,亦能夠在系統測試階段進行.

負載測試是爲了測量Web系統在某一負載級別上的性能，以保證Web系統在需求範圍內能正常工做。

負載級別能夠是某個時刻同時訪問Web系統的用戶數量，也能夠是在線數據處理的數量。

例如：Web應用系統能容許多少個用戶同時在線？若是超過了這個數量，會出現什麼現象？Web應用系統可否處理大量用戶對同一個頁面的請求？

負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。對負載工具的延伸使用能夠進行系統穩定性測試，系統極限測試。

由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。

三、壓力測試（壓力測試傾向應該是導致整個系統崩潰）——基本功能已經經過後進行的.能夠在集成測試階段,亦能夠在系統測試階段進行.

壓力測試是指實際破壞一個Web應用系統，測試系統的反應。

壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。

若是有負載平衡的話還要在服務器端打開監測工具,查看服務器CPU使用率,內存佔用狀況

若是有必要能夠模擬大量數據輸入,對硬盤的影響等等信息

若是有必要的話必須進行性能優化(軟硬件均可以).這裏的壓力測試針對的是某幾項功能

黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存儲權。

壓力測試的區域包括表單、登錄和其餘信息傳輸頁面等。

備註：

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

測試須要驗證系統可否在同一時間響應大量的用戶，在用戶傳送大量數據的時候可否響應，系統可否長時間運行。

可訪問性對用戶來講是極其重要的。若是用戶獲得「系統忙」的信息，他們可能放棄，並轉向競爭對手。

系統檢測不只要使用戶可以正常訪問站點，在不少狀況下，可能會有黑客試圖經過發送大量數據包來攻擊服務器。

出於安全的緣由，測試人員應該知道當系統過載時，須要採起哪些措施，而不是簡單地提高系統性能。

1）瞬間訪問高峯

若是您的站點用於公佈彩票的抽獎結果，最好使系統在中獎號碼公佈後的一段時間內可以響應上百萬的請求。

負載測試工具可以模擬X個用戶同時訪問測試站點。

2）每一個用戶傳送大量數據

網上書店的多數用戶可能只訂購1-5書，可是大學書店可能會訂購5000本有關心理學介紹的課本?

或者一個祖母爲她的50個兒孫購買聖誕禮物(固然每一個孩子都有本身的郵件地址)系統能處理單個用戶的大量數據嗎?

3）長時間的使用

若是站點用於處理鮮花訂單，那麼至少但願它在母親節前的一週內能持續運行。若是站點提供基於web的email服務，那麼點最好能持續運行幾個月，甚至幾年。

可能須要使用自動測試工具來完成這種類型的測試，由於很難經過手工完成這些測試。你能夠想象組織100我的同時點擊某個站點。

可是同時組織100000我的呢。一般，測試工具在第二次使用的時候，它創造的效益，就足以支付成本。

並且，測試工具安裝完成以後，再次使用的時候，只要點擊幾下。

採用的測試工具：

性能測試能夠採用相應的工具進行自動化測試，咱們目前採用以下工具：

Apache自帶的ab測試工具

OpenSTA—開發系統測試架構

Loadrunner—強大的性能測試工具

e-test、webload等

6 接口測試（轉）

在不少狀況下，web 站點不是孤立。Web 站點可能會與外部服務器通信，請求數據、驗證數據或提交訂單。

7 迴歸測試

過一段時間之後，再回過頭來對之前修復過的Bug從新進行測試，看該Bug 是否會從新出現。

迴歸測試技術能夠在測試的各個階段出現，不管是單元測試仍是集成測試仍是系統測試，是對之前問題進行驗證的過程。

迴歸測試的目的就是保證之前已經修復的Bug不會再出現。

實際上，許多Bug都是在迴歸測試時發現的，在此階段，咱們首先要檢查之前找到的Bug是否已經更正了。

值得注意的是，已經更正的Bug 也可能又回來了，有的Bug 通過修改以後可能又產生了新的Bug。

因此，迴歸測試可保證已更正的Bug再也不重現，不產生新的Bug。

web端測試中應該注意的其餘狀況：

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

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

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

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

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

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

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

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

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

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

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

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

存在風險及解決方法

說明：測試不能找出全部的問題，只是儘可能將問題在開發階段解決大多數的問題而已。

測試風險以下：

1）軟硬件的測試環境提供上也對測試結果有很大的影響

2）測試團隊的水平，經驗，合做效果等

3）整個開發流程對測試的重視程度，測試的進入時間等

4）因爲測試環境操做系統，網絡環境，帶寬等狀況可能產生的測試結果可能不一樣，這是須要經驗以及對測試環境的保護等方面下一些功夫

【參考連接】http://www.cnblogs.com/Jessy/p/3539638.html

（若有不足，請指點。後續更新）

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。