總結，總結，新的一年開始總結下以前

　　1.關於web登入的操作

　　快捷鍵的使用是否正常：

　　1. TAB 鍵的使用是否正確

　　2.上下左右鍵是否正確

　　3.介面如果支援 ESC鍵 看是否正常的工作

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

　　佈局美感

　　介面的佈局是否符合人的審美的標準

　　輸入框的功能：

　　輸入合法的使用者名稱和密碼可以成功進入

　　輸入合法的使用者名稱和不合法密碼不可以進入，並給出合理的提示

　　輸入不合法的使用者名稱和正確密碼不可以進入，並給出合理的提示

　　輸入不合法的使用者名稱和不正確的密碼不可以進入，並給出合理的提示

　　不合法的使用者名稱有：不正確的使用者名稱，，使用了字元大於使用者名稱的限制

　　正常使用者名稱不允許的特殊字元 空的使用者名稱，系統（作業系統和應用系統）的保留字元

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

　　正常密碼不允許的特殊字元，系統（作業系統和應用系統）的保留字元　

　　介面的連結：

　　對於介面有連結的介面，要測試介面上的所有的連結都正常或者給出合理的提示

　　補充

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

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

　　驗證使用者名稱前有空格是否可以進入，一般情況可以。

　　驗證使用者名稱是否區分大小寫。（有的軟體是區分大小寫的）

　　驗證必填項為空，是否允許進入。

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

    　2.搜尋功能測試用例設計

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

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

 

　　測試步驟描述

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

　　測試場景一：

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

　　測試場景二：

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

　　測試場景三：

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

　　測試場景四：

步驟編號	具體描述
1	進入搜尋（高階搜尋）頁面
2	逐一輸入文字域條件，模糊查詢值，點選“搜尋”，查詢結果正確
3	逐一輸入文字域條件，完全匹配值，點選“搜尋”，查詢結果正確
4	逐一輸入文字域條件，中文值，點選“搜尋”，查詢結果正確
5	逐一輸入文字域條件，字母大、小寫值，點選“搜尋”，查詢結果正確
6	逐一輸入文字域條件，數字型別值，點選“搜尋”，查詢結果正確
7	逐一輸入文字域條件，全形、半形值，點選“搜尋”，查詢結果正確
8	組合各個文字域查詢條件，點選“搜尋”，查詢結果正確
9	退出

 

　　3.翻頁功能測試用例

　　翻頁功能我們常碰到的一般有以下幾個功能：

　　1、首頁、上一頁、下一頁、尾頁。
　　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到每頁指定條數的記錄
  　　　　   2、上一頁可點選，顯示上一頁的記錄
  　　 　　  3、下一頁可點選，從後一頁的記錄
  　　 　　  4、尾頁可點選，顯示最後頁的記錄
   　　　　  5、列表的資料按照指定的排序列正確排序

　　　　　 6、當前頁數為所在頁

　　step 6:列表的記錄數>指定的每頁顯示條數，在尾頁
　　expect: 1、首頁可點選，顯示1到每頁指定條數的記錄
     　　　    2、上一頁可點選，顯示上一頁的記錄
    　　 　　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，顯示第一頁的資料

　　

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

　　

　　4.輸入框的測試

　　最近在測試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， 這樣的關鍵字如果不被處理就直接用到資料庫查詢中去，後果可想而知。

　　　

　　5.Web測試的常用的檢查點

　　1，頁面連線檢查每一個連線是否都有對應的頁面，並且頁面之間切換正確。（這裡也可以用Xune工具）
　
　　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，回車檢查在輸入結束後直接按回車鍵，看系統如何處理，是否會報錯。

　　效能測試：

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

　　另外，有些頁面有超時的限制，如果響應速度太慢，使用者可能還沒來得及瀏覽內容，就需要重新登陸了。而且，連線速度太慢，還可能引起資料丟失，使使用者得不到真實的頁面。

　　2.負載測試負載測試是為了測量Web 系統在某一負載級別上的效能，以保證Web 系統在需求範圍內能正常工作。負載級別可以是某個時刻同時訪問Web 系統的使用者數量，也可以是線上資料處理的數量。例如：Web 應用系統能允許多少個使用者同時線上？如果超過了這個數量，會出現什麼現象？Web 應用系統能否處理大量使用者對同一個頁面的請求？

　　6.使用者及許可權管理功能常規測試方法：

　　

　　1)  賦予一個人員相應的許可權後，在介面上看此人員是否具有此許可權，並以此人員身份登陸，驗證許可權設定是否正確（能否超出所給予的許可權）；

　　2)  刪除或修改已經登陸系統並正在進行操作的人員的許可權，程式能否正確處理；

　　3)  重新註冊系統變更登陸身份後再登入，看程式是否能正確執行，具有許可權是否正確；

　　4)  在有工作組或角色管理的情況下，刪除包含使用者的工作組或角色，程式能否正確處理；

　　5)  不同許可權使用者登入同一個系統，許可權範圍是否正確；

　　6)  覆蓋系統所有許可權設定；

　　7)  能否新增資訊為空的使用者(其中包括空使用者名稱及空口令、空使用者名稱非空口令、非空使用者名稱及空口令)  ；

　　8)  能否新增長使用者名稱及長口令，如果允許，新使用者能否正確登入；

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

　　10)  登入使用者能否修改自己的許可權；

　　11)  新增使用者（有標識或編號）:標識相同，使用者名稱不同；標識相同，使用者名稱相同；標識不同，使用者名稱相同；標識不同，使用者名稱不同；

　　12)  登入使用者能否修改本人（或其他人）的資訊，刪除本人（或其他人）；

　　13)  修改使用者的資訊（包括許可權，口令，基本資訊等），對其他模組的影響；

　　14)  修改使用者資訊：修改後的使用者資訊和已經存在的使用者資訊相同；修改後的使用者資訊和已經存在的使用者資訊不同；

　　15)  不給使用者授權，是否允許登入；

　　15)  改某些設定時，是否會影響具有上級許可權及相同許可權人員的設定；

　　16)  系統管理員修改了某些資料，以其他人員身份登入時資料是否改變；

　　17)  使用者能否同時屬於多個組，各個組的許可權能否交叉；刪除後重新新增的使用者是否具有以前的許可權；更改使用者各項屬性（包括許可權）看對許可權是否有影響；

　　7. 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。對於需求規格說明書中規定的解析度，測試必須保證測試通過，但對於其他解析度，原則上也應該儘量保證，但由於這個在需求規格說明書中沒有加以約束，所以在一定程度上，開發往往會拒絕進行調整。對於需求規格說明書中沒有規定解析度的專案，測試應該在完成主流解析度的相容性測試的前提下，儘可能進行一些非主流解析度的相容性測試，在一定程度上保證大部分。

　　8.Web測試-sql注入：

　　因為要對網站安全性進行測試，所以，學習了一些sql注入的知識。
　　在網上看一些sql注入的東東，於是想到了對網站的輸入框進行一些測試，本來是想在輸入框中輸入<script>alter("abc")<script>,但是輸入框有字元限制，只好輸入<script>,結果網站出大問題了，呵呵，終於又出現了個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。

　　

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

  　  通常書寫Test Case時需要考慮的檢查點.

　　對於螢幕顯示來說包括：

　　檢查顯示的佈局；

　　檢查域和按鈕的順序；

　　檢查域的尺寸；

　　檢查字型的大小和風格；

　　檢查文字的含義；

　　檢查拼寫錯誤；

　　檢查遮蔽域；

　　檢查只讀域；

　　檢查圖片；

　　檢查按鈕的狀態；

　　檢查按鈕的尺寸；

　　檢查按鈕的圖示和名字；

　　檢查是否有重複的圖示；

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

　　檢查TAB鍵的次序；

　　對於域來說包括：

　　檢查可編輯性；

　　檢查域間的移動；

　　檢查分界條件；

　　檢查有效分界符；

　　檢查無效分界符；

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

　　檢查僅一個分界符輸入；

　　檢查多餘空格的擷取；

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

　　對於數字域來說包括：

　　檢查正數值；

　　檢查負數值；

　　檢查零值；

　　檢查小數點；

　　檢查特殊字元加數字；

　　檢查字母加數字；

　　檢查ASCII值；

　　檢查重複值；

　　檢查空值；

　　對於字元域來說包括：

　　檢查僅有字母；

　　檢查僅有數字；

　　檢查字母數字；

　　檢查允許的特殊字元；

　　檢查禁止的特殊字元；

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

　　檢查ASCII值；

　　對於字母域來說包括：

　　檢查字母；

　　檢查數字值；

　　檢查字母數字值；

　　檢查特殊字元；

　　檢查ASCII值；

　　對於時間域來說包括：

　　檢查字元?和/；

　　檢查其他特殊字元；

　　檢查字母數字值；

　　檢查正確的格式；

　　檢查錯誤的格式；

　　檢查錯誤的日期數字；

　　檢查正確的日期數字；

　　檢查日曆表；

　　10.讓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站點無法工作。如：相關性、子網流量超載、糟糕的裝置驅動程式、硬體故障、包括錯誤檔案的萬用字元、無意間鎖住了關鍵的表。