蜻蜓點水之bug預防

說明：本文內容爲小強老師在卓望139公司任職期間作的內部培訓分享，版權屬於小強老師，咱們歡迎你們拿來作免費分享，但鄙視拿來作商業培訓！

頁面分辨率

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

頁面提示語與提示框

一般狀況下，產品人員並不會將產品需求細化到某句話應該如何提示用戶，因此不一樣的程序員會根據本身的語言特色來提示用戶，這就形成了不一樣程序員提示的語言風格徹底不同，形成產品友好度降低。
對於提示框的大小以及樣式比較混亂，有的是windows的彈框提示，有的則是浮層提示（如：139說客上有的浮層太大）。
平臺接口返回的錯誤碼有時沒有轉化成前端用戶語言
預防方法：
 產品人員和開發人員一塊兒制定儘量大而全的提示語言規範，而且做爲規範說明提供給開發人員進行使用。

頁面連接

連接的有效性及正確性。
圖片的連接，這個會被開發人員忽略掉。
圖片的顯示位置一般會顯示不一樣像素大小和比例的圖，因此須要明肯定義大圖片如何縮減成爲小圖片的策略，以及小圖片如何拉伸顯示爲大的圖片。（如：139說客中的發圖片後的展開以及頭像的縮率圖等）

預防方法：
提供的需求中明確圖片是否須要連接以及連接的位置。
需求中明確圖片顯示策略，是等比縮放顯示，仍是原大小顯示，仍是自適應顯示，而且制定相應策略的統一處理模塊。
能夠利用輔助工具，如Xenu來檢查連接有效性。(簡單演示)

頁面title

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

頁面簡單的性能測試

可能因爲網頁要下載帶有大量圖片或其餘東東致使整個頁面下載變慢。
有時候因爲超時會形成的白頁現象。
預防方法：
減小大東東的下載，尤爲是在主頁或一些重要頁面。
在作前端測試時，若是發現頁面下載緩慢能夠用HttpWatch等工具輔助看下究竟是哪些東西影響了頁面的展示速度。
儘可能少使用圖片，或者使用優化處理過的圖片。
超時的處理：設置合理的等待時間，或者給一個友好的界面提示；另外，讀取不到平臺數據時的提示信息是否也考慮加入？如金豆未讀取到的提示信息是NAN

兼容性測試——瀏覽器

因爲如今瀏覽器的泛濫，須要對主流的瀏覽器進行測試，如360，ie六、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

一、爲何 memcached 沒有個人數據庫快？這是咱們測試的時候常常會遇到的問題。看看下面的解釋吧。 在一對一的比較中， memcached 可能沒有你的 SQL 查詢快。然而，這並非它的目標。 memcached 的目標是可伸縮性。隨着鏈接和請求的增長， memcached 將會表現出比單獨的數據庫解決方案更好的性能。在決定 memcached 不適合你的應用以前，請將你的代碼放在高併發的環境中測試。 注：的確，數據量不夠大的時候體現不出memcache的性能。例如你獲取大量回複數超過10條的notes，get from db和get from memcache就會差不少不少~~~~；若是是小於10條的notes則不會差太多。