頁面分辨率

產品的網頁通常保證在1024*768的分辨率下顯示正常，但是常常忽略在其他分辨率下的顯示情況（如： 800*600 ）。
如果頁面設計明確只考慮1024*768的需求，則只在1024*768下驗證各個產品頁面的顯示正確無誤。
預防方法：
集成程序後的頁面需要分別在兩種顯示分別率下驗證顯示的正確性。

頁面提示語與提示框

通常情況下，產品人員並不會將產品需求細化到某句話應該如何提示用戶，所以不同的程序員會根據自己的語言特點來提示用戶，這就造成了不同程序員提示的語言風格完全不一樣，造成產品友好度下降。

鏈接的有效性及正確性。
圖片的鏈接，這個會被開發人員忽略掉。
圖片的顯示位置通常會顯示不同像素大小和比例的圖，所以需要明確定義大圖片如何縮減成為小圖片的策略，以及小圖片如何拉伸顯示為大的圖片。（如：139說客中的發圖片後的展開以及頭像的縮率圖等）

預防方法：
提供的需求中明確圖片是否需要鏈接以及鏈接的位置。
需求中明確圖片顯示策略，是等比縮放顯示，還是原大小顯示，還是自適應顯示，並且制定相應策略的統一處理模塊。

頁面title

開發過程中關註點集中在功能，造成細節的忽視或遺漏，Web Title 經常忘記設置。
由於需求的頻繁變更，在頁面內容作出變動後，一定要記得Web Title作出相應的改動。
預防方法：
不要將title寫死在html中，多用setTitle()方法設置Web Title或寫在配置文件中。

頁面簡單的性能測試

可能由於網頁要下載帶有大量圖片或其他東東導致整個頁面下載變慢。
有時候由於超時會造成的白頁現象。
預防方法：
減少大東東的下載，尤其是在主頁或一些重要頁面。
在做前端測試時，如果發現頁面下載緩慢可以用HttpWatch等工具輔助看下到底是哪些東西影響了頁面的展現速度。

由於現在瀏覽器的泛濫，需要對主流的瀏覽器進行測試，如360，ie6、7，FF，google瀏覽器、TT等。
開發的同學可能在ff下開發的比較多，往往在ie上會出現一些問題。
預防方法：
設計組需要制定頁面設計規範和Js設計規範，保證主流瀏覽器的頁面顯示兼容性和Js設計兼容性。
通常情況下要保證IE 6/IE 7和FireFox 3瀏覽器下的兼容性，需要保證頁面不變型，Js執行均正確。

快捷鍵與焦點

頁面中支持tab按鍵切換的要檢驗使用的正確性和合理性

對類似表單提交處按鈕的回車鍵支持

打開首頁後焦點的初始位置（如，當打開sina mail後焦點不會自動落入email的輸入框，用戶體驗不好；而網易的郵箱則會自動將焦點落入到email的輸入框）

預防方法：
需求設計過程中需要考慮tab和回車鍵的使用合理性。
程序設計或者頁面設計出一個tab鍵使用的通用設計或者規範。
設計前期就考慮到初始焦點的落入位置，提高用戶體驗性

瀏覽器操作

IE 有一個特性：就是允許前進和後退到某一個頁面，在某些特殊情況下，用戶進行前進和後退，有可能造成數據不完整的提交，或者其他的顯示問題（如，當你正在進行一筆交易時）
用戶可能打開不同的IE使用相同的用戶登錄後進行操作，程序處理的時候要考慮到數據的一致性和同步問題。
多個IE使用不同用戶，則cookie操作不會出現用戶信息混亂的問題。
預防方法：
制定一些標準的策略來處理IE的前進和後退操作，作為整個兒項目的共享，防止用戶返回特定的數據提交頁面和瀏覽頁面，並進行重復操作。

同一個用戶使用多個瀏覽器進行登陸操作給出相應的提示。

表單——字符

原來測試的時候，有這樣的規定1個漢字=1個英文字符，和通常的1個漢字=2個英文字符不同
註冊頁面在設置密碼的時候支持右鍵菜單，能夠將中文字符復制到輸入框中並設置成功，之前測試客戶端註冊的時候遇到過類似這樣的問題，導致登陸的時候無法登陸；
預防方法：
統一下英文字符、漢字、數字、標點等的長度，形成一個統一設計與開發的規範
應該避免將中文字符復制到輸入框中並設置成功。

表單——長字符

輸入框輸入很長連續的數字或英文，並且不折行，則提交數據後，有可能會把頁面拉的很長。
如果要將文字後面的一些文字處理為省略號的時候，需要註意不要將中文截成半個字符。
預防方法：
提交公共處理字符的程序，解決上述問題，來進行公用

表單——重復提交

用戶提交數據頁面，用戶有可能連續多次點擊提交按鈕，造成數據的重復提交。
預防方法：

用戶點擊“提交”後，將按鈕變為Disable狀態

表單——特殊字符

所有鍵盤輸入的特殊字符，均可以正常保存。
需要特別處理英文單引號、雙引號等引起程序錯誤的問題。
需要處理“<”、“/”和“”等容易保存出錯的字符。
對特殊代碼的處理，如<iframe src=www.baidu.com></iframe>
<script>alert(“deba”)</script>（見下圖）
預防方法：
開發公共處理特殊字符的模塊，在系統中進行規範應用

表單——判斷

數字框只能輸入數字的內容。
日期框需要判斷日期是否合以及考慮閏年的情況和每個月30、31天不一樣的情況。
文本框需要判斷字段長是否限制了。
對於空格的處理，如果系統想trim掉字符串最開頭和最後的空格，則需要整個兒系統都使用此策略，否則會造成數據傳遞不一致的問題。（如，搜索時前後加空格的處理）
需要前臺頁面使用js來判斷輸入的合法性，同時後臺邏輯也要添加判斷輸入合法性的判斷。（有時候雖然前端做了限制，但垃圾數據還是會進入後臺，所以兩端都要做限制）

安全方面——url

在URL中不要把密碼等敏感的用戶信息明文的顯示在url中
即使要傳遞密碼參數也不要使用pwd、passpord這樣的參數名稱來進行傳遞，防止被截獲
要在傳遞參數的操作中使用NoCache參數，防止將url參數進行緩存
預防方法：

建立標準的數據傳輸和命名規範，並制作一些網頁開發模板或者規範供參考

安全方面——sql註入

不要把數據庫或者程序的任何報錯信息顯示在頁面上。
最好程序能夠將select update delete 這些關鍵字都過濾掉，不讓用戶提交包含這些數據的信息。
數據庫中設計到操作權限的表名和字段名用很通俗易懂的名字
輸入框盡量過濾掉“<>”這樣的字符，防止javascript攻擊
預防方法：
出錯的時候使用錯誤處理頁面，建立標準的過濾關鍵字程序，統一數據庫設計命名規範，建立防js攻擊的標準函數
PS：之前凡客vancl就出現過這樣的情況，報錯頁把server的信息全部顯示了出來，可惜當時沒截下圖

cookies

Cookie沒有設定過期時間。
IE不支持Cookie的時候沒有任何提示信息。
Cookie中的敏感信息沒有進行加密。
預防方法：
明確cookie生存期，並對生成的cookie進行檢查，建立標準的檢查瀏覽器對cookie支持的程序函數

數據庫測試

Web 應用系統中，一般情況下，可能發生兩種錯誤，分別是數據一致性錯誤和輸出錯誤。
數據一致性錯誤主要是由於用戶提交的表單信息不正確而造成的。
輸出錯誤主要是由於網絡速度或程序設計問題等引起的。（如，web聊天室，可能因為網絡不好，當與server斷開後程序會自動重連幾次，無效後會給用戶一個提示信息）
預防方法：
對表單的提交進行統一嚴格的處理，遵循一定的規範
對於一些異常或未知的錯誤給出有好的提示信息，並能進行快速處理

簡單的並發測試

比如同一臺測試機打開2個IE，前後定位在同一頁面，然後執行特定操作，比如刪除已刪除的數據，系統是給出找不到對象呢？還是友好提示或者直接報錯呢 ？

各種資源的鏈接釋放

有的時候，系統莫名訪問不了，則有可能是數據庫連接沒有釋放
壓力測試的時候，連接釋放如果效率不高，則有可能出現大量連接超時失敗
預防方法：
系統資源的釋放過程，最好通過代碼review的方式來互相監督

系統上線的log配置

上線以後，要關閉無用大量調試log信息，不要打開過多的log
預防方法：
系統管理員對所有打開log級別進行確認，並群發相關人

server配置

如果需要在一個連接同時獲取多個資源，則需要打開apache或者resin的Keepalive參數為On，來提高系統的處理能力，減少多次建立連接所消耗的資源。如果大量的處理只是一次性連接，則不要打開Keepalive設置。
在實際工作中，需要將keepalive分別設置On或者Off來驗證哪個設置的性能更好。
PS：像一些中間價什麽的可能小小的參數配置不合理就會引發大大的問題?

其他

短信的下發一定要有數量的限制，防止對人造成騷擾和不安全的因素。
針對域名的使用，最好使用配置文件的方式來指定域名，不要在程序或者數據庫中寫死域名。
未登錄用戶的訪問問題：未登錄情況下訪問頁面時，如果不能被訪問，應該提示登錄，並在url中帶上backurl，以便登錄後能直接跳轉到該頁面

memcache

1、為什麽 memcached 沒有我的數據庫快？這是我們測試的時候經常會遇到的問題。看看下面的解釋吧。
在一對一的比較中， memcached 可能沒有你的 SQL 查詢快。然而，這並不是它的目標。 memcached 的目標是可伸縮性。隨著連接和請求的增加， memcached 將會表現出比單獨的數據庫解決方案更好的性能。在決定 memcached 不適合你的應用之前，請將你的代碼放在高並發的環境中測試。
註：的確，數據量不夠大的時候體現不出memcache的性能。例如你獲取大量回復數超過10條的notes，get from db和get from memcache就會差很多很多~~~~；如果是小於10條的notes則不會差太多。

走馬觀花之bug預防