總結，總結，新的一年開始總結下以前
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的標籤會出現哪些問題？輸入<；html>； 會出現什麼問題呢？
安全測試方面：
給出一些特別的關鍵字，比如 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站點無法工作。如：相關性、子網流量超載、糟糕的設備驅動程序、硬件故障、包括錯誤文件的通配符、無意間鎖住了關鍵的表。
轉載於:https://www.cnblogs.com/yigedapangzhi/p/10208312.html