軟件測試點--經驗總結

時間 2019-11-30

原文原文鏈接

Web測試中關於登陸的測試

請問，你爲本身寫過的用例懷疑過嗎？javascript

　　前兩天聽一個朋友說他同事寫了100個用例，結果有92個是無效的，差點被公司開了，本人之前也寫過很多用例，但如今突然懷疑個人用例了，以爲愈來愈糊塗了，拿登錄框來講吧，我寫了7個用例，但總感受很差，在網上找了篇文章，分享下，但願對你們有幫助。html

快捷鍵的使用是否正常：java

1. TAB 鍵的使用是否正確程序員

2.上下左右鍵是否正確web

3.界面若是支持 ESC鍵看是否正常的工做sql

3.ENTER 鍵的使用是否正確切換時是否正常。shell

佈局美感數據庫

界面的佈局是否符合人的審美的標準編程

具體因人而異windows

輸入框的功能：

輸入合法的用戶名和密碼能夠成功進入

輸入合法的用戶名和不合法密碼不能夠進入，並給出合理的提示

輸入不合法的用戶名和正確密碼不能夠進入，並給出合理的提示

輸入不合法的用戶名和不正確的密碼不能夠進入，並給出合理的提示

不合法的用戶名有：不正確的用戶名，，使用了字符大於用戶名的限制

正經常使用戶名不容許的特殊字符空的用戶名，系統（操做系統和應用系統）的保留字符

不合法的密碼有：空密碼（除有特殊規定的），錯誤的密碼，字符大於密碼的限制

正常密碼不容許的特殊字符，系統（操做系統和應用系統）的保留字符

界面的連接：

對於界面有連接的界面，要測試界面上的全部的連接都正常或者給出合理的提示

補充

輸入框是否支持複製和黏貼和移動

密碼框顯示的不要是具體的字符，要是一些密碼的字符

驗證用戶名前有空格是否能夠進入，通常狀況能夠。

驗證用戶名是否區分大小寫。（有的軟件是區分大小寫的）

驗證必填項爲空，是否容許進入。

驗證登陸的次數是否有限制。從安全角度考慮，有些安全級別高的軟件會考慮這方面的限制。

搜索功能測試用例設計

對被測試點進行分解，把測試用例分解爲多個測試場景

場景編號	場景描述	預期結果
場景一	頁面檢查	正確
場景二	默認條件搜索	查詢結果正確
場景三	修改可選條件搜索	查詢結果正確
場景四	修改輸入條件搜索	查詢結果正確
場景五	修改區間條件搜索	查詢結果正確
場景六	組合可選、輸入條件搜索	查詢結果正確
場景七	操做後檢查搜索條件及查詢結果	查詢結果正確
場景八	錯誤、空記錄搜索	查詢結果爲空

測試步驟描述

按照已經分解的測試場景順序，逐個描述測試場景的測試步驟

測試場景一：

步驟編號	具體描述
1	進入搜索（高級搜索）頁面
2	界面共性測試
3	退出

測試場景二：

步驟編號	具體描述
1	進入搜索（高級搜索）頁面
2	點擊「搜索」按鈕，顯示查詢結果列表
3	檢查查詢結果列表，每頁顯示記錄條數正確、文字折行顯示正確、頁面佈局美觀
4	檢查查詢結果列表，列標題項、列顯示內容、排序方式符合需求定義
5	檢查查詢結果列表，符合默認查詢條件結果集
6	點擊查詢結果列表連接、複選框、全選框響應正確
7	退出

測試場景三：

步驟編號	具體描述
1	進入搜索（高級搜索）頁面
2	逐一選擇各個查詢條件可選項，如：「所有」、「類別1」等，點擊「搜索」，查詢結果正確
3	組合各個查詢條件可選項，如：價格＋產品，點擊「搜索」，查詢結果正確
4	退出

測試場景四：

步驟編號	具體描述
1	進入搜索（高級搜索）頁面
2	逐一輸入文本域條件，模糊查詢值，點擊「搜索」，查詢結果正確
3	逐一輸入文本域條件，徹底匹配值，點擊「搜索」，查詢結果正確
4	逐一輸入文本域條件，中文值，點擊「搜索」，查詢結果正確
5	逐一輸入文本域條件，字母大、小寫值，點擊「搜索」，查詢結果正確
6	逐一輸入文本域條件，數字類型值，點擊「搜索」，查詢結果正確
7	逐一輸入文本域條件，全角、半角值，點擊「搜索」，查詢結果正確
8	組合各個文本域查詢條件，點擊「搜索」，查詢結果正確
9	退出

翻頁功能測試用例

翻頁功能咱們常碰到的通常有如下幾個功能：

2、總頁數，當前頁數

3、指定跳轉頁

4、指定每頁顯示條數

固然，有一些是少於多少頁，所有以數字的形式顯示，多於多少頁後，纔出現下一頁的控件。本文暫且用以上四點來作爲通用的用例來設計吧。

對於1翻頁連接或按鈕的測試，主要要檢查的測試點有：

1、有無數據時控件的顯示狀況

2、在首頁時，首頁和上一頁是否能點擊

3、在尾頁時，下一頁和尾頁是否能點擊

4、在非首頁和非尾頁時，四個按鈕功能是否正確

5、翻頁後，列表中的記錄是否仍按照指定的排序列進行了排序

對於2總頁數，當前頁數，主要要檢查的測試點有：

1、總頁數是否等於總的記錄數/指定每頁條數

2、當前頁數是否正確

對於3指定跳轉頁，主要要檢查的測試點有：

1、是否能正常跳轉到指定的頁數

2、輸入的跳轉頁數非法時的處理

對於4指定每頁顯示條數，主要要檢查的測試點有：

1、是否有默認的指定每頁顯示條數

2、指定每頁的條數後，列表顯示的記錄數，頁數是否正確

3、輸入的每頁條數非法時的處理

分析完上面的測試點，應該能夠進行用例的設計了。

step 1: 列表無記錄

expect: 1、四個翻頁控件變灰不可點擊

2、列表有相應的無數據信息提示

3、不可指定頁數

4、不可指定跳轉頁

5、總頁數顯示爲0

6、當前頁數顯示爲0

step 2: 列表的記錄數<=指定的每頁顯示條數

expect: 1、四個翻頁控件變灰不可點擊

2、總頁數顯示爲1

3、當前頁數顯示爲1

step 3: 列表的記錄數>指定的每頁顯示條數

expect: 1、默認在首頁，當前頁數爲1

2、列表的數據按照指定的排序列正確排序

3、記錄數與數據庫相符

4、總頁數＝記錄數/指定的每頁顯示條數

step 4: 列表的記錄數>指定的每頁顯示條數，在首頁

expect: 1、首頁變灰不可點擊

2、上一頁變灰不可點擊

3、下一頁可點擊，從（每頁指定條數＋1）條記錄開始顯示，當前頁數+1

4、尾頁可點擊，顯示最後頁的記錄

step 5: 列表的記錄數>指定的每頁顯示條數，在中間的某頁

expect: 1、首頁可點擊，顯示1到每頁指定條數的記錄

3、下一頁可點擊，從後一頁的記錄

4、尾頁可點擊，顯示最後頁的記錄

5、列表的數據按照指定的排序列正確排序

6、當前頁數爲所在頁

step 6:列表的記錄數>指定的每頁顯示條數，在尾頁

expect: 1、首頁可點擊，顯示1到每頁指定條數的記錄

3、下一頁變灰不可點擊

4、尾頁變灰不可點擊

5、列表的數據按照指定的排序列正確排序

6、當前頁數爲最後一頁的頁數

step 7:輸入每頁顯示條數爲正整數

expect: 1、每頁顯示條數更新成指定的條數

2、超過指定的條數的記錄分頁顯示

3、總頁數更新成列表的記錄數/每頁顯示條數

step 8:輸入每頁顯示條數爲0

expect: 1、提示「每頁顯示條數必須爲大於1的整數」

2、提示後每頁顯示條數恢復爲上次生效的條數

step 9:輸入每頁顯示條數爲負數

expect: 1、提示每頁顯示條數必須爲大於1的整數

2、提示後每頁顯示條數恢復爲上次生效的條數

step 10:輸入每頁顯示條數長度超過數據庫指定的長度<<<maxlen>>>

expect: 1、提示每頁顯示條數不能超過<<<maxlen>>>位

2、提示後每頁顯示條數恢復爲上次生效的條數

step 11:輸入每頁顯示條數爲字符串，如中文翻頁數

expect: 1、提示每頁顯示條數必須爲大於1的整數

2、提示後每頁顯示條數恢復爲上次生效的條數

step 12:輸入每頁顯示條數爲特殊字符，如％

expect: 1、提示每頁顯示條數必須爲大於1的整數

2、提示後每頁顯示條數恢復爲上次生效的條數

step 13:輸入每頁顯示條數爲html字符串，如<br>

expect: 1、提示每頁顯示條數必須爲大於1的整數

2、提示後每頁顯示條數恢復爲上次生效的條數

step 14:輸入跳轉的頁數爲存在的頁數

expect: 1、正確跳轉到指定的頁數

step 15:輸入跳轉的頁數不存在或非法值

expect: 1、跳轉的頁數值置爲1，顯示第一頁的數據

以上的用例是將總頁數，當前頁數都揉進了翻頁控件的測試用例中了

輸入框的測試

最近在測試Web的輸入框的時候，總是不知道從何處下手，去網上搜羅了一些資料，固然網上對輸入框的測試資料少之又少，因此我做了一個簡單的總結，總的狀況有一下幾個方面：

1.驗證輸入與輸出的是否信息一致；

2.輸入框以前的標題是否正確；

3.對特殊字符的處理，尤爲是輸入信息須要發送到數據庫的。特殊字符包括：'（單引號）、"（雙引號）、[]（中括號）、（）（小括號）、{}（大括號）、；（分號）、<>（大於小於號）……

4.對輸入框輸入超過限制的字符的處理，通常非特殊的沒有做出限制的在255byte左右；

5.輸入框自己的大小、長度；

6.不一樣內碼的字符的輸入；

7.對空格、TAB字符的處理機制；

8.字符自己顯示的顏色；

9.密碼輸入窗口轉換成星號或其它符號；

10.密碼輸入框對其中的信息進行加密，防止採用破解星號的方法破解；

11.按下ctrl和alt鍵對輸入框的影響；

12.對於新增、修改、註冊時用的輸入框，有限制的，應該輸入時做出提示，指出不容許的或者標出容許的；

13.對於有約束條件要求的輸入框應當在條件知足時輸入框的狀態發生相應的改變，好比選了湖南就應該列出湖南下面的市，或者選了某些條件以後，一些輸入框會關閉或轉爲只讀狀態；

14.輸入類型；根據前面的欄位標題判斷該輸入框應該輸入哪些內容算是合理的。例如，是否容許輸入數字或字母，不容許輸入其餘字符等。

15.輸入長度；數據庫字段有長度定義，當輸入過長時，提交數據是否會出錯。

16.輸入狀態；當處於某種狀態下，輸入框是否處於可寫或非可寫狀態。例如，系統自動給予的編號等欄位做爲惟一標識，當再次處於編輯狀態下，輸入框欄位應處於不可寫狀態，若是可寫對其編輯的話，可能會形成數據重複引發衝突等。

暫時，就能想這麼多，看你們誰還有觀點，互相學習下！

17.若是是會進行數據庫操做的輸入框，還能夠考慮輸入SQL中的一些特殊符號如單引號等，有時會有意想不到的錯誤出現

18.輸入類型輸入長度是否容許複製粘貼爲空的狀況空格的考慮半角全角測試對於密碼輸入框要考慮顯示的內容是* 輸入錯誤時的提示信息及提示信息是否準確

19.能夠先了解你要測試的輸入框在軟件系統的某個功能中所扮演的角色，而後瞭解其具體的輸入條件，在將輸入條件按照有效等價類，無效等價類，邊界值等方法進行測試用例的設計。

20.關鍵字有大小寫混合的狀況；

21.關鍵字中含有一個或多個空格的狀況，包括前空格，中間空格（多個關鍵字），和後空格；

22.關鍵字中是否支持通配符的狀況（視功能而定）；

23.關鍵字的長度分別爲9、10、11個字符時的狀況；

24.關鍵字是valid，可是沒有匹配搜索結果的狀況；

25.輸入html的標籤會出現哪些問題？輸入&lt；html&gt；會出現什麼問題呢？（這條是我本身發現的，在網上也沒找到相似的東東，呵呵，你們湊合着看吧）

安全測試方面：

給出一些特別的關鍵字，好比 or 1=1，這樣的關鍵字若是不被處理就直接用到數據庫查詢中去，後果可想而知。

Web測試的經常使用的檢查點

1，頁面鏈接檢查每個鏈接是否都有對應的頁面，而且頁面之間切換正確。

2，相關性檢查刪除/增長一項是否會對其餘項產生影響，若是產生影響，這些影響是否都正確。

3，檢查按扭的功能是否正確如update，cancel，delete，save等功能是否正確。

4，字符串長度檢查輸入超過需求說明的字符串長度的內容，看系統是否檢查字符串長度，會不會出錯。

5，字符類型檢查在應該輸入指定類型的內容的地方輸入其餘類型的內容（如在應該輸入整形的地方輸入其餘字符類型），看系統是否檢查字符類型，是否報錯。

6，標點符號檢查輸入內容包括各類標點符號，特別是空格，各類引號，回車健，看系統是否處理正確。

7，中文字符處理在能夠輸入中文的系統輸入中文（簡體或繁體），看是否會出現亂碼或出錯。

8，檢查帶出信息的完整性在查看信息和update信息時，查看所填寫的信息是否所有帶出，帶出信息和添加的是否一致。

9，信息重複檢查在一些須要命名，且名字應該惟一的信息輸入重複的名字或id，看系統有沒有處理，是否報錯，重名包括是否區分大小寫，以及在輸入內容的先後輸入空格，系統是否做出正確處理。

10，檢查刪除功能在一些能夠一次刪除多個信息的地方，不選擇任何信息，按‘delete’，看系統如何處理，是否報錯，而後選擇一個或多個信息，進行刪除，看是否作正確處理。

11，檢查添加和修改的一致，檢查添加和修改信息的要求是否一致，例如添加要求必添的項，修改也應該必填，添加規定的整形的項，修改也必須爲整形。

12，檢查修改重名，修改時把不能重名的項改成已存在的內容看是否會處理，同時，也要注意，會不會報和本身重名的錯。

13，重複提交表單一條已經成功提交的記錄，back後再提交，看系統會如何處理。

14，檢查屢次使用back健的狀況在有back的地方，back，回到原來的頁面，再back，重複幾回，看是否會報錯。

15，search檢查在有search功能的地方輸入系統存在和不存在的內容，看search結果是否正確，若是能夠輸入多個search條件，能夠同時添加合理和不合理的條件，看系統處理是否正確。

16，輸入信息位置注意在光標停留的地方輸入信息時，光標和所輸入信息是否會跳到別的地方。

17，上傳和下載文件檢查上傳和下載文件的功能是否實現，上傳是否能打開。對上傳文件的格式有什麼規定，系統是否有解釋信息，並檢查系統是否可以作到。

18，必填項檢查應該填寫的項沒有填寫的時候系統是否都作了處理，對必填項是否提示信息，如在必填項前面加*.

19，快捷鍵檢查是否支持經常使用快捷，如Ctrl+C，Ctrl+V，BackSpace等，對一些不容許的輸入信息的字段，如選人，選日期對快捷方式是否作了限制。

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

性能測試

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

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

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

用戶及權限管理功能常規測試方法

1) 賦予一我的員相應的權限後，在界面上看此人員是否具備此權限，並以此人員身份登錄，驗證權限設置是否正確（可否超出所給予的權限）；

2) 刪除或修改已經登錄系統並正在進行操做的人員的權限，程序可否正確處理；

3) 從新註冊系統變動登錄身份後再登陸，看程序是否能正確執行，具備權限是否正確；

4) 在有工做組或角色管理的狀況下，刪除包含用戶的工做組或角色，程序可否正確處理；

5) 不一樣權限用戶登陸同一個系統，權限範圍是否正確；

6) 覆蓋系統全部權限設定；

7) 可否添加信息爲空的用戶(其中包括空用戶名及空口令、空用戶名非空口令、非空用戶名及空口令) ；

8) 可否添加長用戶名及長口令，若是容許，新用戶可否正確登陸；

9) 系統是否容許刪除系統管理員這一特殊用戶或修改系統管理員口令，刪除或修改後系統的實際狀況；

10) 登陸用戶可否修改本身的權限；

11) 添加用戶（有標識或編號）:標識相同，用戶名不一樣；標識相同，用戶名相同；標識不一樣，用戶名相同；標識不一樣，用戶名不一樣；

12) 登陸用戶可否修改本人（或其餘人）的信息，刪除本人（或其餘人）；

13) 修改用戶的信息（包括權限，口令，基本信息等），對其餘模塊的影響；

14) 修改用戶信息：修改後的用戶信息和已經存在的用戶信息相同；修改後的用戶信息和已經存在的用戶信息不一樣；

15) 不給用戶受權，是否容許登陸；

15) 改某些設置時，是否會影響具備上級權限及相同權限人員的設置；

16) 系統管理員修改了某些數據，以其餘人員身份登陸時數據是否改變；

17) 用戶可否同時屬於多個組，各個組的權限可否交叉；刪除後從新添加的用戶是否具備之前的權限；更改用戶各項屬性（包括權限）看對權限是否有影響。

WEB測試之兼容性測試

1. 軟件兼容性測試

兼容性測試是指待測試項目在特定的硬件平臺上，不一樣的應用軟件之間，不一樣的操做系統平臺上，在不一樣的網絡等環境中能正常的運行的測試。

兼容性測試的目的：待測試項目在不一樣的操做系統平臺上正常運行，包括待測試項目能在同一操做系統平臺的不一樣版本上正常運行；待測試項目能與相關的其餘軟件或系統的「和平共處」；待測試項目能在指定的硬件環境中正常運行；待測試項目能在不一樣的網絡環境中正常運行。

兼容性測試沒法作到徹底的質量保證，但對於一個項目來說，兼容性測試是必不可少的一個步驟。

2. Web兼容性測試的主要類型

Web兼容性測試主要是針對不一樣的操做系統平臺，瀏覽器，以及分辨率進行的測試。

2.1. 操做系統兼容性測試

常見的操做系統有Windows，Unix，Linux等，對於普通用戶來說，最經常使用的是Windows操做系統。Windows操做系統包括Windows XP，windows 2003，vista，Win2000/NT，Windows9x等等。用戶使用操做系統的類型，直接決定了咱們操做系統平臺兼容性測試的操做系統平臺數量，進行操做系統平臺的兼容性測試的主要目的就是保證咱們的待測試項目在該操做系統平臺下能正常運行。

對於一些特殊項目（好比定製項目），能夠指定某一類型的操做系統版本，這些都應該在需求規格說明書中指明，針對這些指明的操做系統版本必須進行兼容性測試。

大部分的其餘項目，是不指定操做系統版本的，針對這樣的項目，咱們應當針對當前的主流操做系統版本進行兼容性測試，在確保主流操做系統版本兼容性測試的前提下在對非主流操做系統版本進行測試，儘可能保證項目的操做系統版本的兼容性測試的完整性。

2.2. 瀏覽器兼容性測試

瀏覽器是Web系統中對核心的組成構件，來自不一樣廠家的瀏覽器對Javascrīpt、 ActiveX或不一樣的HTML規格有不一樣的支持，即便是同一廠家的瀏覽器，也存在不一樣的版本的問題。不一樣的瀏覽器對安全性和JAVA的設置也不同。

目前最爲經常使用的瀏覽器爲：IE 6.0 IE 7.0.但因爲操做習慣的問題，還有至關一部分用戶喜歡使用騰訊的TT，以及firefox瀏覽器，這些瀏覽器一樣也存在各個版本的問題。這個對於Web系統來說是一個至關大的挑戰。

對於一些特殊項目（好比定製項目），能夠指定某一類型的瀏覽器（包括版本），這些都必須在需求規格說明書中指明。針對這些指明的瀏覽器必須進行兼容性測試。但大部分的項目，是不能指定瀏覽器的，針對這樣的項目，那麼咱們必須針對當前的主流瀏覽器（含版本），在確保主流瀏覽器的兼容性測試經過的前提下，再對非主流瀏覽器（含版本）進行測試，儘可能保證項目的瀏覽器的兼容性測試的完整性。

2.3. 分辨率兼容性測試

分辨率的測試是爲了頁面版式在不一樣的分辨率模式下能正常顯示，字體符合要求而進行的測試。

用戶使用什麼模式的分辨率，對於咱們來說是未知的。一般狀況下，在咱們的需求規格說明書中會建議某些分辨率。對於測試來說，必須針對需求規格說明書中建議的分辨率進行專門的測試。如今常見的分辨率是1024×768，800×600。對於需求規格說明書中規定的分辨率，測試必須保證測試經過，但對於其餘分辨率，原則上也應該儘可能保證，但因爲這個在需求規格說明書中沒有加以約束，因此在必定程度上，開發每每會拒絕進行調整。對於需求規格說明書中沒有規定分辨率的項目，測試應該在完成主流分辨率的兼容性測試的前提下，儘量進行一些非主流分辨率的兼容性測試，在必定程度上保證大部分。

Web測試-sql注入

Web安全性測試—SQL注入

由於要對網站安全性進行測試，因此，學習了一些sql注入的知識。

在網上看一些sql注入的東東，因而想到了對網站的輸入框進行一些測試，原本是想在輸入框中輸入<script>alter("abc")<script>,可是輸入框有字符限制，只好輸入<script>,結果網站出大問題了，呵呵，終於又出現了個bug。

另外一個就是在URL最後隨意輸入一些字符或數字，結果，新聞模塊那出現了問題，暴露了網站的一些信息，又一個bug，高興下……

下面把今天看到的有關SQL注入方面的知識整理以下：

SQL注入是一種攻擊方式，在這種攻擊方式中，惡意代碼被插入到字符串中，而後將該字符串傳遞到SQL Server的實例以進行分析和執行。任何構成SQL語句的過程都應進行注入漏洞檢查，由於SQL Server將執行其接收到的全部語法有效的查詢。一個有經驗的、堅決的攻擊者甚至能夠操做參數化數據。

SQL注入的主要形式包括直接將代碼插入到與SQL命令串聯在一塊兒並使其得以執行的用戶輸入變量。一種間接的攻擊會將惡意代碼注入要在表中存儲或做爲元數據存儲的字符串。在存儲的字符串隨後串連到一個動態SQL命令中時，將執行該惡意代碼。

注入過程的工做方式是提早終止文本字符串，而後追加一個新的命令。因爲插入的命令可能在執行前追加其餘字符串，所以攻擊者將用註釋標記「--」來終止注入的字符串。執行時，此後的文本將被忽略。

如下腳本顯示了一個簡單的SQL注入。此腳本經過串聯硬編碼字符串和用戶輸入的字符串而生成一個SQL查詢：

var Shipcity;

ShipCity = Request.form. ("ShipCity");

var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

用戶將被提示輸入一個市縣名稱。若是用戶輸入Redmond，則查詢將由與下面內容類似的腳本組成：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'

可是，假定用戶輸入如下內容：

Redmond'; drop table OrdersTable--

此時，腳本將組成如下查詢：

SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'

分號(;)表示一個查詢的結束和另外一個查詢的開始。雙連字符(--)指示當前行餘下的部分是一個註釋，應該忽略。若是修改後的代碼語法正確，則服務器將執行該代碼。SQL Server處理該語句時，SQL Server將首先選擇OrdersTable中的全部記錄（其中ShipCity爲Redmond）。而後，SQL Server將刪除OrdersTable。

只要注入的SQL代碼語法正確，便沒法採用編程方式來檢測篡改。所以，必須驗證全部用戶輸入，並仔細檢查在您所用的服務器中執行構造SQL命令的代碼。本主題中的如下各部分說明了編寫代碼的最佳作法。

驗證全部輸入:

始終經過測試類型、長度、格式和範圍來驗證用戶輸入。實現對惡意輸入的預防時，請注意應用程序的體系結構和部署方案。請注意，設計爲在安全環境中運行的程序可能會被複制到不安全的環境中。如下建議應被視爲最佳作法：

若是一個用戶在須要郵政編碼的位置無心中或惡意地輸入了一個10 MB的MPEG文件，應用程序會作出什麼反應？

若是在文本字段中嵌入了一個DROP TABLE語句，應用程序會作出什麼反應？

測試輸入的大小和數據類型，強制執行適當的限制。這有助於防止有意形成的緩衝區溢出。

輸入字符在Transact-SQL中的含義

; 查詢分隔符。

' 字符數據字符串分隔符。

-- 註釋分隔符。

/* ... */ 註釋分隔符。服務器不對/*和*/之間的註釋進行處理。

xp_ 用於目錄擴展存儲過程的名稱的開頭，如xp_cmdshell。

Web測試中書寫用例時要考慮的檢查點

一般書寫Test Case時須要考慮的檢查點.

對於屏幕顯示來講包括：

檢查顯示的佈局；

檢查域和按鈕的順序；

檢查域的尺寸；

檢查字體的大小和風格；

檢查文本的含義；

檢查拼寫錯誤；

檢查屏蔽域；

檢查只讀域；

檢查圖片；

檢查按鈕的狀態；

檢查按鈕的尺寸；

檢查按鈕的圖標和名字；

檢查是否有重複的圖標；

檢查指針是否在第一個可輸入域；

檢查TAB鍵的次序；

對於域來講包括：

檢查可編輯性；

檢查域間的移動；

檢查分界條件；

檢查有效分界符；

檢查無效分界符；

檢查連續多個有效分界符；

檢查僅一個分界符輸入；

檢查多餘空格的截取；

檢查只讀域和屏蔽域在TAB時的狀態；

對於數字域來講包括：

檢查正數值；

檢查負數值；

檢查零值；

檢查小數點；

檢查特殊字符加數字；

檢查字母加數字；

檢查ASCII值；

檢查重複值；

檢查空值；

對於字符域來講包括：

檢查僅有字母；

檢查僅有數字；

檢查字母數字；

檢查容許的特殊字符；

檢查禁止的特殊字符；

檢查包含特殊字符的字母數字；

檢查ASCII值；

對於字母域來講包括：

檢查字母；

檢查數字值；

檢查字母數字值；

檢查特殊字符；

檢查ASCII值；

對於時間域來講包括：

檢查字符?和/；

檢查其餘特殊字符；

檢查字母數字值；

檢查正確的格式；

檢查錯誤的格式；

檢查錯誤的日期數字；

檢查正確的日期數字；

檢查日曆表；

手機電子郵件測試用例

序號	測試項目		測試方法		測試標準
1	電子郵件設置	IP地址設置	默認的爲010.000.000.172，本身設置必須設置爲010.000.000.172		若是須要手動設置必須設置成010.000.000.172
		撥號設置(GSM)\		默認爲17266，手動設置必須設置成17266	手動設置必須設置成17266
		節點設置(GPRS)		必須設置爲cmwap	必須設置爲cmwap
		用戶名設置		若是設置，必須設置爲WAP	若是設置必須設置爲WAP
		用戶密碼設置		若是用戶名作了設置，此項必須設置爲wap	若是用戶名作了設置，此項必須設置爲wap
		上網數據模式設置(GPRS/GSM)		選擇GPRS或GSM方式	若是有這兩項可選擇，必須可以使用。
		端口類型選擇		能夠選擇安全和不安全。	通常選擇不安全
2	用戶設置	賬戶設置		將用戶的郵箱地址、接收郵件服務器（POP3）、發送郵件服務器（SMTP）、郵箱賬戶名以及密碼設置完成	可以成功設置
		下載設置		設置好各個限制項目：如單個信件下載最大字節、所有信件下載最大字節等等	可以成功設置
3	編寫新郵件			選擇輸入法編寫文本，並選擇插入的附件（格式爲txt/gif/jpg/bmp等）	全部的輸入法都能實現，插入附件功能必須實現
4	發送郵件			編輯好郵件後，輸入對方的電子郵件，按確認鍵進行發送	郵件可以成功發送並要有保存提示或自動進入已發信箱（若是此功能已經設定）
5	刪除郵件			在郵件列表中，選擇某條郵件，按選項菜單，選擇刪除項，再按確認鍵。	可以刪除所選郵件
6	回覆郵件			在郵件列表中選擇某條郵件，在選項中選擇回覆，而後進行編輯，確認後發送。	可以實現郵件的回覆操做。
7	轉發郵件			在收件箱中選擇某條郵件，在選項中選擇轉發，而後進行編輯，並輸入第三方的郵箱地址或者從地址簿中選擇號碼，按確認鍵進行發送。	可以實現郵件的轉發。

記事本與日曆的測試用例

序號	測試項目		測試方法	斷定標準
1	記事本測試	新建	在記事本中新建一個文本文檔。	必須可以正常新建一個文檔。
		編輯	對新建文檔或者已有的文檔進行編輯。	必須可以編輯文檔，編輯時必須可以正確輸入漢字、英文、數字、字母、標點符號等。


		保存	保存已經編輯的文檔。	編輯完成後必須可以保存已編輯的內容。

		刪除	刪除已經保存的文檔。	必須可以刪除已經保存的文檔，刪除前必須有確認信息，刪除成功與否必須有相應的提示。


2	日程表測試	新建	在記事本中新建一個日程安排。	必須可以正常新建一個日程。
		編輯	對新建文檔或者已有的日程進行編輯。	必須可以編輯文檔，編輯時必須可以正確輸入漢字、英文、數字、字母、標點符號等。


		保存	保存已經編輯的日程。	編輯完成後必須可以保存已編輯的內容。

		刪除	刪除已經保存的日程。	必須可以刪除已經保存的文檔，刪除前必須有確認信息，刪除成功與否必須有相應的提示。


		日程提示設定	設定提示時間、提示模式。	必須可以設定日程提示的時間和提醒模式，設定完成後必須可以準時提醒。


		時間、日期設定	設定當前時間、日期。	必須可以設定當前的時間和日期，必須保證日程表裏的萬年曆時間準確無誤，至少保證日程表中每一年的每月（陽曆與農曆）的第一天與最後一天的正確性，另外對應的星期也必須準確。特別須要關注閏年。

Web測試總結
讓web站點崩潰最多見的七大緣由

磁盤已滿

致使系統沒法正常運行的最可能的緣由是磁盤已滿。一個好的網絡管理員會密切關注磁盤的使用狀況，隔必定的時間，就須要將磁盤上的一些負載轉存到備份存儲介質中（例如磁帶）。

日誌文件會很快用光全部的磁盤空間。Web服務器的日誌文件、SQL*Net的日誌文件、JDBC日誌文件，以及應用程序服務器日誌文件均與內存泄漏有同等的危害。能夠採起措施將日誌文件保存在與操做系統不一樣的文件系統中。日誌文件系統空間已滿時Web服務器也會被掛起，但機器自身被掛起的概率已大大減低。

C指針錯誤

用C或C++編寫的程序，如Web服務器API模塊，有可能致使系統的崩潰，由於只要間接引用指針（即，訪問指向的內存）中出現一個錯誤，就會致使操做系統終止全部程序。另外，使用了糟糕的C指針的Java模擬量（analog）將訪問一個空的對象引用。Java中的空引用一般不會致使馬上退出JVM，可是前提是程序員可以使用異常處理方法恰當地處理錯誤。在這方面，Java無需過多的關注，但使用 Java對可靠性進行額外的度量則會對性能產生一些負面影響。

內存泄漏

C/C++程序還可能產生另外一個指針問題：丟失對已分配內存的引用。當內存是在子程序中被分配時，一般會出現這種問題，其結果是程序從子程序中返回時不會釋放內存。如此一來，對已分配的內存的引用就會丟失，只要操做系統還在運行中，則進程就會一直使用該內存。這樣的結果是，曾佔用更多的內存的程序會下降系統性能，直到機器徹底中止工做，纔會徹底清空內存。

解決方案之一是使用代碼分析工具（如Purify）對代碼進行仔細分析，以找出可能出現的泄漏問題。但這種方法沒法找到由其餘緣由引發的庫中的泄漏，由於庫的源代碼是不可用的。另外一種方法是每隔一段時間，就清除並重啓進程。Apache的Web服務器就會因這個緣由建立和清除子進程。

雖然Java自己並沒有指針，但總的說來，與C程序相比， Java程序使用內存的狀況更加糟糕。在Java中，對象被頻繁建立，而直到全部到對象的引用都消失時，垃圾回收程序纔會釋放內存。即便運行了垃圾回收程序，也只會將內存還給虛擬機VM，而不是還給操做系統。結果是：Java程序會用光給它們的全部堆，從不釋放。因爲要保存實時（Just In Time，JIT）編譯器產生的代碼，Java程序的大小有時可能會膨脹爲最大堆的數倍之巨。

還有一個問題，狀況與此相似。從鏈接池分配一個數據庫鏈接，而沒法將已分配的鏈接還回給鏈接池。一些鏈接池有活動計時器，在維持一段時間的靜止狀態以後，計時器會釋放掉數據庫鏈接，但這不足以緩解糟糕的代碼快速泄漏數據庫鏈接所形成的資源浪費。

進程缺少文件描述符

若是已爲一臺Web服務器或其餘關鍵進程分配了文件描述符，但它卻須要更多的文件描述符，則服務器或進程會被掛起或報錯，直至獲得了所需的文件描述符爲止。文件描述符用來保持對開放文件和開放套接字的跟蹤記錄，開放文件和開放套接字是Web服務器很關鍵的組成部分，其任務是將文件複製到網絡鏈接。默認時，大多數shell有64個文件描述符，這意味着每一個從shell啓動的進程能夠同時打開64個文件和網絡鏈接。大多數shell都有一個內嵌的 ulimit命令能夠增長文件描述符的數目。

線程死鎖

由多線程帶來的性能改善是以可靠性爲代價的，主要是由於這樣有可能產生線程死鎖。線程死鎖時，第一個線程等待第二個線程釋放資源，而同時第二個線程又在等待第一個線程釋放資源。咱們來想像這樣一種情形：在人行道上兩我的迎面相遇，爲了給對方讓道，兩人同時向一側邁出一步，雙方沒法經過，又同時向另外一側邁出一步，這樣仍是沒法經過。雙方都以一樣的邁步方式堵住了對方的去路。假設這種狀況一直持續下去，這樣就不難理解爲什麼會發生死鎖現象了。

解決死鎖沒有簡單的方法，這是由於使線程產生這種問題是很具體的狀況，並且每每有很高的負載。大多數軟件測試產生不了足夠多的負載，因此不可能暴露全部的線程錯誤。在每一種使用線程的語言中都存在線程死鎖問題。因爲使用Java進行線程編程比使用C容易，因此 Java程序員中使用線程的人數更多，線程死鎖也就愈來愈廣泛了。能夠在Java代碼中增長同步關鍵字的使用，這樣能夠減小死鎖，但這樣作也會影響性能。若是負載太重，數據庫內部也有可能發生死鎖。

若是程序使用了永久鎖，好比鎖文件，並且程序結束時沒有解除鎖狀態，則其餘進程可能沒法使用這種類型的鎖，既不能上鎖，也不能解除鎖。這會進一步致使系統不能正常工做。這時必須手動地解鎖。

服務器超載

Netscape Web服務器的每一個鏈接都使用一個線程。Netscape Enterprise Web服務器會在線程用完後掛起，而不爲已存在的鏈接提供任何服務。若是有一種負載分佈機制能夠檢測到服務器沒有響應，則該服務器上的負載就能夠分佈到其它的 Web服務器上，這可能會導致這些服務器一個接一個地用光全部的線程。這樣一來，整個服務器組都會被掛起。操做系統級別可能還在不斷地接收新的鏈接，而應用程序（Web服務器）卻沒法爲這些鏈接提供服務。用戶能夠在瀏覽器狀態行上看到connected（已鏈接）的提示消息，但這之後什麼也不會發生。

解決問題的一種方法是將obj.conf參數RqThrottle的值設置爲線程數目之下的某個數值，這樣若是越過 RqThrottle的值，就不會接收新的鏈接。那些不能鏈接的服務器將會中止工做，而鏈接上的服務器的響應速度則會變慢，但至少已鏈接的服務器不會被掛起。這時，文件描述符至少應當被設置爲與線程的數目相同的數值，不然，文件描述符將成爲一個瓶頸。

數據庫中的臨時表不夠用

許多數據庫的臨時表（cursor）數目都是固定的，臨時表即保留查詢結果的內存區域。在臨時表中的數據都被讀取後，臨時表便會被釋放，但大量同時進行的查詢可能耗盡數目固定的全部臨時表。這時，其餘的查詢就須要列隊等候，直到有臨時表被釋放時才能再繼續運行。

這是一個不容易被程序員發覺的問題，但會在負載測試時顯露出來。但可能對於數據庫管理員（DataBase Administrator，DBA）來講，這個問題十分明顯。

此外，還存在一些其餘問題：設置的表空間不夠用、序號限制過低，這些都會致使表溢出錯誤。這些問題代表了一個好的DBA對用於生產的數據庫設置和性能進行按期檢查的重要性。並且，大多數數據庫廠商也提供了監控和建模工具以幫助解決這些問題。

另外，還有許多因素也極有可能致使Web站點沒法工做。如：相關性、子網流量超載、糟糕的設備驅動程序、硬件故障、包括錯誤文件的通配符、無心間鎖住了關鍵的表。

Web應用程序是否存在跨站點腳本漏洞

到目前爲止，對於跨站點腳本攻擊具備很大的威脅這一點你們並沒有異議。若是您很精通 XSS 而且只想看看有什麼好的測試方法可供借鑑，那麼請直接跳到本文的測試部分。若是您對此一無所知，請按順序認真閱讀！若是某個懷有惡意的人（攻擊者）能夠強迫某個不知情的用戶（受害者）運行攻擊者選擇的客戶端腳本，那麼便會發生跨站點腳本攻擊。「跨站點腳本」這個詞應該屬於用詞不當的狀況，由於它不只與腳本有關，並且它甚至不必定是跨站點的。因此，它就是一個在發現這種攻擊時起的一個名字，而且一直沿用至今。從如今開始，咱們將使用它常見的縮寫名稱「XSS」。

XSS 攻擊的過程涉及如下三方：

• 攻擊者

• 受害者

• 存在漏洞的網站（攻擊者能夠使用它對受害者採起行動）

在這三方之中，只有受害者會實際運行攻擊者的代碼。網站僅僅是發起攻擊的一個載體，通常不會受到影響。能夠用多種方式發起 XSS 攻擊。例如，攻擊者可經過電子郵件、IM 或其餘途徑向受害者發送一個通過經心構造的惡意 URL。當受害者在 Web 瀏覽器中打開該 URL 的時侯，網站會顯示一個頁面並在受害者的計算機上執行腳本。

XSS 漏洞是什麼樣的呢？

做爲一名 Web 開發人員或測試人員，您確定知道 Web 應用程序的技術基礎是由 HTTP 和 HTML 組成的。HTTP 協議是 HTML 的傳輸機制，可以使用代碼設計 Web 頁面佈局和生成頁面。

若是 Web 應用程序接受用戶經過 HTTP 請求（如 GET 或 POST）提交的輸入信息，而後使用輸出 HTML 代碼在某些地方顯示這些信息，即可能存在 XSS 漏洞。下面是一個最簡單的例子：

1. Web 請求以下所示：

GET http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title

2. 在發出請求後，服務器返回的 HTML 內容包括：

<h1>Section Title</h1>

能夠看到，傳遞給「title」查詢字符串參數的用戶輸入可能被保存在一個字符串變量中而且由 Web 應用程序插入到 <h1> 標記中。經過提供輸入內容，攻擊者能夠控制 HTML。

3. 如今，若是站點沒有在服務器端對用戶輸入加以過濾（由於老是能夠繞過客戶端控件），那麼惡意用戶即可以使用許多手段對此漏洞加以濫用：

攻擊者能夠經過擺脫 <h1> 標記來注入代碼：

http://www.somesite.com/page.asp?pageid=10&lang=en&title=Section%20Title</h1><script>alert(‘XSS%20attack’)</script>

這個請求的 HTML 輸出將爲：

<h1>Section Title</h1><script>alert(‘XSS attack’)</script>

即使是這個最簡單的例子，攻擊者也能夠利用此鏈接完成數不清的事情。讓咱們看看會有哪些潛在的威脅，而後討論一些更高級的測試方法。

XSS 攻擊的威脅有多麼嚴重？

因爲可以在生成的 Web 頁面中注入代碼，能想到的威脅有多麼嚴重，就能夠有多麼嚴重的威脅。攻擊者能夠使用 XSS 漏洞竊取 Cookie，劫持賬戶，執行 ActiveX，執行 Flash 內容，強迫您下載軟件，或者是對硬盤和數據採起操做。

只要您點擊了某些 URL，這一切便有可能發生。天天之中，在閱讀來自留言板或新聞組的受信任的電子郵件的時侯，您會多少次地單擊其中的 URL？

網絡釣魚攻擊一般利用 XSS 漏洞來裝扮成合法站點。能夠看到不少這樣的狀況，好比您的銀行給你發來了一封電子郵件，向您告知對您的賬戶進行了一些修改並誘使您點擊某些超連接。若是仔細觀察這些 URL，它們實際上可能利用了銀行網站中存在的漏洞，它們的形式相似於http://mybank.com/somepage?redirect=<script>alert(‘XSS’)</script>，這裏利用了「redirect」參數來執行攻擊。

若是您足夠狡猾的話，能夠將管理員定爲攻擊目標，您能夠發送一封具備以下主題的郵件：「求救！這個網站地址老是出現錯誤！」在管理員打開該 URL 後，即可以執行許多惡意操做，例如竊取他（或她）的憑證。

好了，如今咱們已經理解了它的危害性 -- 危害用戶，危害管理員，給公司帶來壞的公共形象。如今，讓咱們看看本文的重點 -- 測試您的網站是否存在這些問題。

測試 XSS 漏洞

多年以來，我一直是一名全職的安全顧問，已經作過無數次的這種測試了。我將好的測試計劃歸結爲兩個字：完全。對於你我來講，查找這些漏洞與可以有機會在 Bugtraq 或 Vulnwatch 上吹噓一番沒有任何關係；它只與如何出色完成負責的工做有關。若是這意味着對應用程序中全部的單個查詢字符串參數、cookie 值以及 POST 數據值進行檢查，那麼這隻能代表咱們的工做還不算太艱鉅。

顯然，一次完整的安全性檢查所涉及的內容一般遠遠超出尋找 XSS 漏洞那樣簡單；它須要創建總體的威脅模型，測試溢出漏洞、信息泄漏、錯誤處理、SQL 注入、身份驗證和受權錯誤。好在執行這樣完全的工做時，各個領域之間都存在重疊。好比，在測試 XSS 漏洞時，常常會同時找出錯誤處理或信息泄漏問題。

我假設您屬於某個負責對 Web 應用程序進行開發和測試的小組。在這個幸運的位置上，您能夠混合使用黑盒和白盒方法。每種方法都有它本身的優勢，結合使用時甚至能相互提供支持。

1. 按順序準備您的工具包

測試工做也能夠是自動化的，可是咱們在這裏只討論手動操做。手動測試的必備工具包括：

• Paros proxy (http://www.parosproxy.org)，用於截獲 HTTP 通訊數據

• Fiddler (http://www.fiddlertool.com/fiddler)，用於截獲 HTTP 通訊數據

• Burp proxy (http://www.portswigger.net/proxy/)

• TamperIE (http://www.bayden.com/dl/TamperIESetup.exe)，用於修改 GET 和 POST

咱們以上至少列出了三種 Web 代理軟件。也能夠尋找其餘不一樣的相似產品，由於每種產品都有它本身的獨到之處。下面，您須要在 Web 瀏覽器發出 HTTP 請求以前截獲這些請求，並修改它們以注入 XSS 測試代碼。上面全部這些工具均可以完成這項任務，某些工具還會顯示返回的 HTML 源代碼（若是您選擇了截獲服務器響應）。

截獲客戶端發出的 GET 和 POST 請求很是重要。這樣能夠繞過全部的客戶端 javascript. 輸入驗證代碼。我在這裏要提醒全部 Web 開發人員 -- 客戶端安全控制是靠不住的。應該老是在服務器端執行有效性驗證。

2. 肯定站點及其功能 -- 與開發人員和 PM 交流

繪製一些簡單的數據流圖表，對站點上的頁面及其功能進行描述。此時，能夠安排一些與開發人員和項目經理的會議來創建威脅模型。在會議上儘量對應用程序進行深刻探討。站點公開了 Web 服務嗎？是否有身份驗證表單？有留言板嗎？有用戶設置頁面嗎？確保列出了全部這些頁面。

3. 找出並列出全部由用戶提供輸入的點

對站點地圖進行進一步細化。我一般會爲此建立一個電子表格。對於每一個頁面，列出全部查詢字符串參數、cookie 值、自定義 HTTP 標頭、POST 數據值和以其餘形式傳遞的用戶輸入。不要忘記搜索 Web 服務和相似的 SOAP 請求，並找出全部容許用戶輸入的字段。

分別列出每一個輸入參數，由於下面須要獨立測試每一個參數。這多是最重要的一個步驟！若是閱讀下面的電子表格，您會看到我已經在示例站點中找出了一大堆這樣的東西。如 forwardURL 和 lang 這樣的查詢字符串。如 name、password、msgBody、msgTitle 和這樣的 POST 數據，甚至某些 Cookie 值。全部這些都是咱們感興趣的重要測試內容。

4. 認真思考並列出測試用例

使用已經獲得的電子表格並列出各類用來測試 XSS 漏洞的方法。咱們稍候將討論各類方法，可是如今先讓咱們看看個人電子表格的屏幕截圖，請注意，我列出了頁面上容許的每一個值以及每一個值的全部測試類型。這種記錄測試的方法僅是我本身的習慣，您能夠使用本身的方法。我喜歡記錄全部東西，以便我能知道已經作了哪些工做和哪些工做沒有作。

5. 開始測試並注意輸出結果

在查找漏洞的過程當中，最重要的部分並非您是否找到了漏洞。而是您是否真正知道究竟發生了哪些事情。對於 XSS，只需檢查 HTML 輸出並看看您輸入的內容在什麼地方。它在一個 HREF 標記中嗎？是否在 IFRAME. 標記中？它在 CLSID 標記中嗎？在 IMG SRC 中嗎？某些 Flash 內容的 PARAM NAME 是怎樣的？

我會檢查全部這些狀況，若是您對所輸入內容的目的十分了解，能夠調整您的測試來找出問題。這意味着您可能須要添加一個額外的封閉括號「>」來讓某個標記變得完整，或者添加一個雙引號來關閉標記內的一個元素。或者，您可能須要使用 URL 或 HTML 來編碼您的字符，例如將雙引號變爲 %22 或 "。

嗯，並不那麼容易，這個站點看來防範比較嚴密。如今該怎麼辦呢？

那麼，也許您的簡單測試用例 <script>alert(‘hi’)</script> 並不能產生指望中的警告對話框。仔細想一想這個問題並在可能的狀況下與開發人員進行交流。也許他們對輸入中的尖括號、單引號或圓括號進行了過濾。也許他們會過濾「script」這個詞。從新研究爲什麼輸入會產生這樣的輸出，並理解每一個值（查詢字符串、cookie、POST 數據）的做用。「pageId=10」這樣的查詢字符串值可能對輸出沒有影響，所以不值得花費時間測試它。有時，最好試着注入單個字符（例如尖括號、雙引號標記或者圓括號），看看應用程序是否過濾這些字符。而後，即可以知道您面對的過濾級別究竟如何。接着，能夠調整測試方法，對這些字符進行編碼並重試，或者尋找其餘注入辦法。

改變測試用例

我恐怕沒法充分對此進行說明：研究輸入的值會輸出什麼樣的 HTML 頁面很是重要。若是它們不能產生輸出，那麼不要在它們上面浪費時間。若是能夠，請進行研究，由於您須要根據輸出對測試進行相應的修改。我使用了各類變化形式來找出能接受和顯示腳本代碼的參數。由於這涉及太多內容，所以在這裏沒法一一進行討論，可是請務必注意如下幾種狀況：

1. >"'><script>alert(‘XSS')</script>

2. >%22%27><img%20src%3d%22javascript.:alert(%27XSS%27)%22>

3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>

4. AK%22%20style%3D%22background:url(javascript.:alert(%27XSS%27))%22%20OS%22

5. %22%2Balert(%27XSS%27)%2B%22

6. <table background="javascript.:alert(([code])"></table>

7. <object type=text/html data="javascript.:alert(([code]);"></object>

8. <body nload="javascript.:alert(([code])"></body>

有許多變化形式能夠嘗試。關鍵在於瞭解程序究竟使用何種方式處理輸入和顯示輸出頁面。如同這些例子所展現的，常見的變化形式常常是在腳本代碼前面加上「>」」，以嘗試封閉網站可能在輸出中生成的標記。還能夠對代碼進行 URL 編碼，嘗試繞過服務器端的輸入過濾功能。此外，由於尖括號「<>」一般會在輸入時被過濾和從輸出中刪除，因此還必須嘗試不須要尖括號的 XSS，例如」&{alert('XSS')};」

持久和動態

找出一個成功的 XSS 頗費周折，由於在開始時 XSS 攻擊可能並非那麼顯而易見的。隨便舉一個例子，若是向網站添加一條新留言並在「msgTitle」值中注入代碼，在提交數據後，您可能不會當即看到腳本代碼被執行。可是，當您訪問留言板的時侯，將會在 HTML 頁面中使用「msgTitle」值並將其做爲腳本代碼執行。這種狀況被稱做持久性 XSS 攻擊，若是包含腳本代碼的值將被保存到客戶端或者後端系統並在稍候的時間被執行，便會發生此種攻擊。

而與此相對的是動態 XSS 攻擊，這種攻擊會當即執行並只發生一次。好比，若是某個連接或 GET 請求在某個用來控制頁面輸出的查詢字符串中包含了腳本代碼，那麼在點擊連接後會當即顯示輸出。

總結

XSS 測試一般只是整個 Web 應用程序安全性審查工做的一小部分，可是在執行測試時必須細緻和完全。在多年的工做中，我一直強調使用電子表格或其餘方式來記錄站點的全部頁面，以及每一個頁面接受的輸入值（查詢字符串、cookie、POST 數據、SOAP），這是在測試前必須進行的一個重要步驟。與此同等重要的是，理解輸入以及它在輸出的 HTML 頁面上的呈現方式。若是您知道了應用程序處理輸入的方式，就會很是迅速地完成許多工做。不要浪費時間測試那些不會做爲輸出顯示的輸入。與開發人員和 PM 進行交流，並在開始測試前創建完善的威脅模型。

Web測試總結（全）

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

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

1. 功能測試

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

3. 用戶界面測試

4. 兼容性測試

5. 安全測試

6. 接口測試

本文的目的是覆蓋 web 測試的各個方面，未就某一主題進行深刻說明。

1 功能測試

1.1 連接測試

連接是Web應用系統的一個主要特徵，它是在頁面之間切換和指導用戶去一些不知道地址的頁面的主要手段。連接測試可分爲三個方面。首先，測試全部連接是否按指示的那樣確實連接到了該連接的頁面；其次，測試所連接的頁面是否存在；最後，保證Web應用系統上沒有孤立的頁面，所謂孤立頁面是指沒有連接指向該頁面，只有知道正確的URL地址才能訪問。

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

採起措施：採用自動檢測網站連接的軟件來進行。

推薦軟件：

Xenu Link Sleuth 免費綠色免安裝軟件

HTML Link Validator 共享（30天試用）

1.2 表單測試

當用戶經過表單提交信息的時候，都但願表單能正常工做。

若是使用表單來進行在線註冊，要確保提交按鈕能正常工做，當註冊完成後應返回註冊成功的消息。若是使用表單收集配送信息，應確保程序可以正確處理這些數據，最後能讓顧客能讓客戶收到包裹。要測試這些程序，須要驗證服務器能正確保存這些數據，並且後臺運行的程序能正確解釋和使用這些信息。

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

1.3 數據校驗

若是系根據業務規則須要對用戶輸入進行校驗，須要保證這些校驗功能正常工做。例如，省份的字段能夠用一個有效列表進行校驗。在這種狀況下，須要驗證列表完整並且程序正確調用了該列表(例如在列表中添加一個測試值，肯定系統可以接受這個測試值)。

在測試表單時，該項測試和表單測試可能會有一些重複。

1.2和1.3的採起措施：第一個完整的版本採用手動檢查，同時造成WinRunner（QTP）腳本；迴歸測試以及升級版本主要靠WinRunner（QTP）自動回放測試。

1.4 cookies測試

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

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

採起措施：

1 採用黑盒測試：採用上面提到的方法進行測試

2 採用查看cookies的軟件進行（初步的想法）

能夠選擇採用的軟件

IECookiesView v1.50

Cookies Manager v1.1

1.5 數據庫測試

在Web應用技術中，數據庫起着重要的做用，數據庫爲Web應用系統的管理、運行、查詢和實現用戶對數據存儲的請求等提供空間。在Web應用中，最經常使用的數據庫類型是關係型數據庫，能夠使用SQL對信息進行處理。

在使用了數據庫的Web應用系統中，通常狀況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。數據一致性錯誤主要是因爲用戶提交的表單信息不正確而形成的，而輸出錯誤主要是因爲網絡速度或程序設計問題等引發的，針對這兩種狀況，可分別進行測試。

採起措施：暫時沒有更好的測試方法

考慮結合到1.2和1.3的測試中

1.6 應用程序特定的功能需求

最重要的是，測試人員須要對應用程序特定的功能需求進行驗證。嘗試用戶可能進行的全部操做：下訂單、更改訂單、取消訂單、覈對訂單狀態、在貨物發送以前更改送貨信息、在線支付等等。這是用戶之因此使用網站的緣由，必定要確認網站能像廣告宣傳的那樣神奇。

採起措施：深入理解需求說明文檔

1.7 設計語言測試

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

暫時沒有方法測試，能夠多參考一點討論組內的更新信息

2 性能測試

2.1 鏈接速度測試

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

2.2 負載測試

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

2.3 壓力測試

負載測試應該安排在Web系統發佈之後，在實際的網絡環境中進行測試。由於一個企業內部員工，特別是項目組人員老是有限的，而一個Web系統能同時處理的請求數量將遠遠超出這個限度，因此，只有放在Internet上，接受負載測試，其結果纔是正確可信的。

進行壓力測試是指實際破壞一個Web應用系統，測試系統的反映。壓力測試是測試系統的限制和故障恢復能力，也就是測試Web應用系統會不會崩潰，在什麼狀況下會崩潰。黑客經常提供錯誤的數據負載，直到Web應用系統崩潰，接着當系統從新啓動時得到存取權。

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

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

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

瞬間訪問高峯

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

每一個用戶傳送大量數據

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

長時間的使用

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

採起措施：採用測試工具WAS、ACT協助進行測試

3 用戶界面測試

3.1 導航測試

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

在一個頁面上放太多的信息每每起到與預期相反的效果。Web應用系統的用戶趨向於目的驅動，很快地掃描一個Web應用系統，看是否有知足本身須要的信息，若是沒有，就會很快地離開。不多有用戶願意花時間去熟悉Web應用系統的結構，所以，Web應用系統導航幫助要儘量地準確。

導航的另外一個重要方面是Web應用系統的頁面結構、導航、菜單、鏈接的風格是否一致。確保用戶憑直覺就知道Web應用系統裏面是否還有內容，內容在什麼地方。

Web應用系統的層次一旦決定，就要着手測試用戶導航功能，讓最終用戶參與這種測試，效果將更加明顯。

3.2 圖形測試

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

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

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

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

（4）圖片的大小和質量也是一個很重要的因素，通常採用JPG或GIF壓縮，最好能使圖片的大小減少到 30k 如下

（5）最後，須要驗證的是文字迴繞是否正確。若是說明文字指向右邊的圖片，應該確保該圖片出如今右邊。不要由於使用圖片而使窗口和段落排列古怪或者出現孤行。

一般來講，使用少量或儘可能不使用背景是個不錯的選擇。若是您想用背景，那麼最好使用單色的，和導航條一塊兒放在頁面的左邊。另外，圖案和圖片可能會轉移用戶的注意力。

3.3內容測試

內容測試用來檢驗Web應用系統提供信息的正確性、準確性和相關性。

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

對於開發人員來講，可能先有功能而後纔對這個功能進行描述。你們坐在一塊兒討論一些新的功能，而後開始開發，在開發的時候，開發人員可能不注重文字表達，他們添加文字可能只是爲了對齊頁面。不幸的是，這樣出來的產品可能產生嚴重的誤解。所以測試人員和公關部門一塊兒檢查內容的文字表達是否恰當。不然，公司可能陷入麻煩之中，也可能引發法律方面的問題。測試人員應確保站點看起來更專業些。過度地使用粗體字、大字體和下劃線可能會讓用戶感到不舒服。在進行用戶可用性方面的測試時，最好先請圖形設計專家對站點進行評估。你可能不但願看到一篇處處是黑體字的文章，因此相信您也但願本身的站點能更專業一些。最後，須要肯定是否列出了相關站點的連接。不少站點但願用戶將郵件發到一個特定的地址，或者從某個站點下載瀏覽器。可是若是用戶沒法點擊這些地址，他們可能會以爲很迷惑。

3.4 表格測試

須要驗證表格是否設置正確。用戶是否須要向右滾動頁面才能看見產品的價格？把價格放在左邊，而把產品細節放在右邊是否更有效? 每一欄的寬度是否足夠寬，表格裏的文字是否都有折行？是否有由於某一格的內容太多，而將整行的內容拉長?

3.5 總體界面測試

總體界面是指整個Web應用系統的頁面結構設計，是給用戶的一個總體感。例如：當用戶瀏覽Web應用系統時是否感到溫馨，是否憑直覺就知道要找的信息在什麼地方？整個Web應用系統的設計風格是否一致？

對總體界面的測試過程，實際上是一個對最終用戶進行調查的過程。通常Web應用系統採起在主頁上作一個調查問卷的形式，來獲得最終用戶的反饋信息。

對全部的用戶界面測試來講，都須要有外部人員（與Web應用系統開發沒有聯繫或聯繫不多的人員）的參與，最好是最終用戶的參與。

採起措施：手動測試，參與人員最好有外部人員

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

4.4 Modem/鏈接速率

是否有這種狀況，用戶使用 28.8 modem下載一個頁面須要 10 分鐘，但測試人員在測試的時候使用的是 T1 專線? 用戶在下載文章或演示的時候，可能會等待比較長的時間，但卻不會耐心等待首頁的出現。最後，須要確認圖片不會太大。

4.5 打印機

用戶可能會將網頁打印下來。所以網也在設計的時候要考慮到打印問題，注意節約紙張和油墨。有很多用戶喜歡閱讀而不是盯着屏幕，所以須要驗證網頁打印是否正常。有時在屏幕上顯示的圖片和文本的對齊方式可能與打印出來的東西不同。測試人員至少須要驗證訂單確認頁面打印是正常的。

4.6 組合測試

最後須要進行組合測試。600x800 的分辨率在 MAC 機上可能不錯，可是在 IBM 兼容機上卻很難看。在 IBM 機器上使用 Netscape 能正常顯示，但卻沒法使用 Lynx 來瀏覽。若是是內部使用的 web 站點，測試可能會輕鬆一些。若是公司指定使用某個類型的瀏覽器，那麼只需在該瀏覽器上進行測試。若是全部的人都使用 T1 專線，可能不須要測試下載施加。(但須要注意的是，可能會有員工從家裏撥號進入系統) 有些內部應用程序，開發部門可能在系統需求中聲明不支持某些系統而只支持一些那些已設置的系統。可是，理想的狀況是，系統能在全部機器上運行，這樣就不會限制未來的發展和變更。

採起措施：根據實際狀況，採起等價劃分的方法，列出兼容性矩陣

5 安全測試

即便站點不接受信用卡支付，安全問題也是很是重要的。Web 站點收集的用戶資料只能在公司內部使用。若是用戶信息被黑客泄露，客戶在進行交易時，就不會有安全感。

5.1 目錄設置

Web 安全的第一步就是正確設置目錄。每一個目錄下應該有 index.html 或 main.html 頁面，這樣就不會顯示該目錄下的全部內容。我服務的一個公司沒有執行這條規則。我選中一幅圖片，單擊鼠標右鍵，找到該圖片所在的路徑"…com/objects/images"。而後在瀏覽器地址欄中手工輸入該路徑，發現該站點全部圖片的列表。這可能沒什麼關係。我進入下一級目錄 "…com/objects" ，點擊 jackpot。在該目錄下有不少資料，其中引發我注意的是已過時頁面。該公司每月都要更改產品價格，而且保存過時頁面。我翻看了一下這些記錄，就能夠估計他們的邊際利潤以及他們爲了爭取一個合同還有多大的降價空間。若是某個客戶在談判以前查看了這些信息，他們在談判桌上確定處於上風。

5.2 SSL

不少站點使用 SSL 進行安全傳送。你知道你進入一個 SSL 站點是由於瀏覽器出現了警告消息，並且在地址欄中的 HTTP 變成 HTTPS。若是開發部門使用了SSL，測試人員須要肯定是否有相應的替代頁面(適用於3.0 如下版本的瀏覽器，這些瀏覽器不支持SSL。當用戶進入或離開安全站點的時候，請確認有相應的提示信息。是否有鏈接時間限制？超過限制時間後出現什麼狀況？

5.3 登陸

有些站點須要用戶進行登陸，以驗證他們的身份。這樣對用戶是方便的，他們不須要每次都輸入我的資料。你須要驗證系統阻止非法的用戶名/口令登陸，而可以經過有效登陸。用戶登陸是否有次數限制? 是否限制從某些 IP 地址登陸? 若是容許登陸失敗的次數爲3，你在第三次登陸的時候輸入正確的用戶名和口令，能經過驗證嗎? 口令選擇有規則限制嗎? 是否能夠不登錄而直接瀏覽某個頁面？

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

5.4 日誌文件

在後臺，要注意驗證服務器日誌工做正常。日誌是否記全部的事務處理? 是否記錄失敗的註冊企圖? 是否記錄被盜信用卡的使用? 是否在每次事務完成的時候都進行保存? 記錄IP 地址嗎? 記錄用戶名嗎?

5.5 腳本語言

腳本語言是常見的安全隱患。每種語言的細節有所不一樣。有些腳本容許訪問根目錄。其餘只容許訪問郵件服務器，可是經驗豐富的黑客能夠將服務器用戶名和口令發送給他們本身。找出站點使用了哪些腳本語言，並研究該語言的缺陷。還要須要測試沒有通過受權，就不能在服務器端放置和編輯腳本的問題。最好的辦法是訂閱一個討論站點使用的腳本語言安全性的新聞組。

6 接口測試

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

6.1服務器接口

第一個須要測試的接口是瀏覽器與服務器的接口。測試人員提交事務，而後查看服務器記錄，並驗證在瀏覽器上看到的正好是服務器上發生的。測試人員還能夠查詢數據庫，確認事務數據已正確保存。

這種測試能夠歸到功能測試中的表單測試和數據校驗測試中

6.2 外部接口

有些 web 系統有外部接口。例如，網上商店可能要實時驗證信用卡數據以減小欺詐行爲的發生。測試的時候，要使用 web 接口發送一些事務數據，分別對有效信用卡、無效信用卡和被盜信用卡進行驗證。若是商店只使用 Visa 卡和 Mastercard 卡，能夠嘗試使用 Discover 卡的數據。(簡單的客戶端腳本可以在提交事務以前對代碼進行識別，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 表明Discover。)一般，測試人員須要確認軟件可以處理外部服務器返回的全部可能的消息。

這種狀況在遠程抄表中可能會體現到

6.3 錯誤處理

最容易被測試人員忽略的地方是接口錯誤處理。一般咱們試圖確認系統可以處理全部錯誤，但卻沒法預期系統全部可能的錯誤。嘗試在處理過程當中中斷事務，看看會發生什麼狀況？訂單是否完成？嘗試中斷用戶到服務器的網絡鏈接。嘗試中斷 web 服務器到信用卡驗證服務器的鏈接。在這些狀況下，系統可否正確處理這些錯誤？是否已對信用卡進行收費？若是用戶本身中斷事務處理，在訂單已保存而用戶沒有返回網站確認的時候，須要由客戶表明致電用戶進行訂單確認。

採起措施：在理解需求的基礎上，充分發揮想象力，儘可能比較全面的列出各類異常狀況。

7 結論

不管你在測試 internet、intranet 或者是 extranet 應用程序，web 測試相對於非 web 測試來講都是更具挑戰性的工做。用戶對 web 頁面質量有很高的指望。在不少狀況下，就像業務功能同樣，頁面用於維護和發展公共關係，因此第一印象很是重要。

理解web性能測試術語

在軟件系統日益複雜的今天，性能已經成爲軟件質量的重要衡量標準之一，這一點尤爲體如今和WEB相關的系統上。接下來介紹一些WEB性能測試中的術語，這些術語都是WEB性能測試中出現頻繁的比較高的詞彙，只有掌握這些基礎的性能知識才能夠進一步開展測試工做。這些術語主要有併發用戶，併發用戶數量，請求響應時間，事務響應時間，吞吐量，吞吐率，TPS，點擊率，資源利用率等。

併發用戶：併發通常分爲2種狀況。一種是嚴格意義上的併發，即全部的用戶在同一時刻作同一件事情或者操做，這種操做通常指作同一類型的業務。好比在信用卡審批業務中，必定數目的擁護在同一時刻對已經完成的審批業務進行提交；還有一種特例，即全部用戶進行徹底同樣的操做，例如在信用卡審批業務中，全部的用戶能夠一塊兒申請業務，或者修改同一條記錄。

另一種併發是廣義範圍的併發。這種併發與前一種併發的區別是，儘管多個用戶對系統發出了請求或者進行了操做，可是這些請求或者操做能夠是相同的，也能夠是不一樣的。對整個系統而言，仍然是有不少用戶同時對系統進行操做，所以也屬於併發的範疇。

能夠看出，後一種併發是包含前一種併發的。並且後一種併發更接近用戶的實際使用狀況，所以對於大多數的系統，只有數量不多的用戶進行「嚴格意義上的併發」。對於WEB性能測試而言，這2種併發狀況通常都須要進行測試，一般作法是先進行嚴格意義上的併發測試。嚴格意義上的用戶併發通常發生在使用比較頻繁的模塊中，儘管發生的機率不是很大，可是一旦發生性能問題，後果極可能是致命的。嚴格意義上的併發測試每每和功能測試關聯起來，由於併發功能遇到異常一般都是程序問題，這種測試也是健壯性和穩定性測試的一部分。

用戶併發數量：關於用戶併發的數量，有2種常見的錯誤觀點。一種錯誤觀點是把併發用戶數量理解爲使用系統的所有用戶的數量，理由是這些用戶可能同時使用系統；還有一種比較接近正確的觀點是把在線用戶數量理解爲併發用戶數量。實際上在線用戶也不必定會和其餘用戶發生併發，例如正在瀏覽網頁的用戶，對服務器沒有任何影響，可是，在線用戶數量是計算併發用戶數量的主要依據之一。

請求響應時間：指的是客戶端發出請求到獲得響應的整個過程的時間。在某些工具中，請求響應時間一般會被成爲"TLLB"，即"Time to last byte",意思是從發起一個請求開始，到客戶端接收到最後一個字節的響應時間所耗費的時間。請求響應時間過程的單位通常爲"秒"或者"毫秒".

事務響應時間:事務可能由一系列請求組成,事務的響應時間主要是針對用戶而言,屬於宏觀上的概念，是爲了向用戶說明業務響應時間而提出的.例如:跨行取款事務的響應時間就是由一系列的請求組成的.事務響應時間和後面的業務吞吐率都是直接衡量系統性能的參數.

吞吐量:指的是在一次性能測試過程當中網絡上傳輸的數據量的總和.吞吐量/傳輸時間,就是吞吐率.

TPS:每秒鐘系統可以處理的交易或者事務的數量.它是衡量系統處理能力的重要指標.

點擊率:每秒鐘用戶向WEB服務器提交的HTTP請求數.這個指標是WEB應用特有的一個指標:WEB應用是"請求-響應"模式,用戶發出一次申請,服務器就要處理一次,因此點擊是WEB應用可以處理的交易的最小單位.若是把每次點擊定義爲一個交易,點擊率和TPS就是一個概念.容易看出,點擊率越大,對服務器的壓力越大.點擊率只是一個性能參考指標,重要的是分析點擊時產生的影響。須要注意的是,這裏的點擊並不是指鼠標的一次單擊操做,由於在一次單擊操做中,客戶端可能向服務器發出多個HTTP請求.

資源利用率:指的是對不一樣的系統資源的使用程度,例如服務器的CPU利用率,磁盤利用率等.資源利用率是分析系統性能指標進而改善性能的主要依據,所以是WEB性能測試工做的重點.

資源利用率主要針對WEB服務器,操做系統,數據庫服務器,網絡等,是測試和分析瓶頸的主要參考.在WEB性能測試中,更根據須要採集相應的參數進行分析.

Web安全測試入門

測試工做總結
Web應用系統易出問題的緣由和測試要點

web應用系統是目前最多見的應用系統之一，例如電子商務網站，就是一種典型的web應用系統，關於測試要點，我認爲能夠有如下幾點：

當咱們在進行web應用系統的測試時，咱們能夠作這樣一個假設：若是咱們是某個電子商務網站的用戶，咱們會對這個網站有哪些指望呢？

1,有足夠的性能，不要在併發用戶不少的時候響應速度很慢；

2,有足夠好的兼容性，當咱們使用IE之外的瀏覽器的時候，網站仍舊可以正常使用；

3,有足夠的安全性。至少咱們不但願本身的用戶名和密碼被別人輕易得到；

4,連接的正確性。當咱們點擊購買一本圖書時，咱們不但願出現的是是張CD的頁面；

因而總結起來無外乎，性能，兼容性，安全性，正確性，我認爲這是咱們測試人員應該關注的要點。

這幾方面容易出問題的緣由，我想可能跟如下幾點有關吧。

1,網站用戶的數量可能在某個時間段迅速增長，其增長的速度和用戶的總數可能會超過當初設計的極限；

2,用戶使用環境的複雜性，系統就有WINDOWS,LINUX和其餘系統，瀏覽器又有IE ,FIREFOX ,NETSCAPE,OPERA等等；而有的用戶顯示器可能還僅僅支持800*600等等情況的複雜性；

3,網絡的人爲攻擊，病毒氾濫等

4,在一個web頁面存在大量的鏈接，且這些連接是在不斷更新，不免會出現錯誤；

因爲這些問題的存在，在編寫測試計劃和測試用例，搭建測試環境和執行測試時，我認爲，應該基於web應用系統的測試時的特徵，有針對性地進行測試工做。

另外，對於web應用系統來講，還能夠分爲服務器端測試和客戶端測試兩部分，畢竟web是由服務器端和客戶端組成的。

我想，在服務器端，重點進行的應該是性能測試，負載測試和安全測試吧？！

在客戶端，則要在兼容性測試上作好工夫。

其實對於web，最廣泛的性能測試應該是負載測試，經過負載測試，測試人員就能夠知道系統如何完成預期的或者超過預期的行爲。例如：某個電子商務網站設計時，考慮能同時在線的用戶爲5000人。那測試員就須要知道當同時在線5000人時，系統的響應情況，也要知道，若是在某個時間段同時在線用戶超過系統設計值，假設達到了10000人，系統的響應狀況。若是同時在線5000人時，系統響應速度很慢，以致於不多有用戶有足夠的耐心來等待完成，那麼我想這個web系統將不會被用戶接受。