最近部門整理了今年所有項目測試團隊提出的BUG，篩選了幾十個作為常規通用的缺陷，我根據這些缺陷內容，去掉和業務相關的知識，整理出了一份缺陷描述和解決方案。
其實WEB系統中常規的缺陷分類后也就那么多，但匯總過程，有同事建議分類寫得更通用點，但我想了下，寫了后大家可能更看不懂，本來常犯的錯誤也就這么多，分類比如按照安全問題，性能問題，並發問題，可能描述更專業，但開發、測試團隊的人看到可能太官方和自己無關，自己也不會引起重視了。所以我的分類和問題描述可能更口水話一點，但應該能讓每個人都很快看得懂。
下面寫下我整理的一部分，重要程度和犯錯頻率不分先后順序：
一、不相信客戶端的數據
缺陷描述：前台惡意偽造數據或頁面的某些值未加載完成，用戶發起一個請求但用了加載中的值，或請求的值本身就是惡意偽造的，導致后台拋出詳細異常或導致sql注入，XSS等。
建議：不管前台數據是惡意偽造還是由於網速慢頁面值未加載完成，但用戶用該不“常規”數據請求，后台都應該一一校驗，比如JS前段驗證只是為了一定程度減少后后請求壓力，后台代碼應該再次校驗客戶端的任何數據，SQL參數應該參數化等。
二、頁面未設置友好錯誤
缺陷描述：頁面由於未對500,404等HTTP錯誤設置友好頁面，導致前台拋出了細節的錯誤情況
建議：配置500,404等HTTP錯誤友好頁面
三、ajax加載完成前后對頁面事件的控制
缺陷描述：ajax請求前后對頁面的其他新請求未進行限制，導致前一個ajax未處理完成，后續又在執行依賴前一個ajax返回數據的請求
建議：如果前台頁面存在依賴關系的新請求（包括ajax），應在新請求時判斷前一個請求是否完成，如果未完成，則等待或提示。
一個重要的ajax請求前應該設置某些按鈕不可用，ajax請求完成后再把按鈕設置為可用。這樣該重要ajax請求完畢后才能點擊其他操作
四、后台平行、垂直權限驗證
缺陷描述：后台未對該請求判斷該用戶是否有權限操作本請求的數據，而只是判斷了是否有權限操作這個鏈接或根本沒有判斷是否有權限操作該鏈接，該問題常會導致查看所有人訂單或查看管理員數據
建議：權限控制除了控制當前用戶權限是否有權限操作本請求地址，還需要判斷是否有權限操作這條數據
五、一筆訂單多次退款四舍五入問題
缺陷描述：單獨作為一項，原因是支付退款是非常重要的環節。任何涉及支付退款的都可能有該問題。一個訂單分多次退款，由於四舍五入的問題，會導致全部退款加起來會大於支付價格，比如大於0.01元
比如99.5元的訂單，四舍五入精確到分，第一次退款33.17元，第二次退款33.17元，第三次退款33.17元，總退款：99.51元。
建議：我認為有兩種解決方案：
1、支付按照四舍五入取大計算，退款按照取小計算，比如0.009元也算0.00元。這樣不管分多少次退款，極端情況下，可能全部退完了，還會剩余0.02元更多點，適合極端情況一個訂單分多次把所有費用退完，但供應商或平台最后可能還賺幾分錢。但這個和業務有關系，需要確認。
2、退款每次按照四舍五入退款，但如果一個訂單最后一筆退款則不再按照四舍五入退款，而是把支付金額減去已完成的所有退款金額，剩余的錢作為最后一次全部退，這樣保證用戶和供應商或平台都不會多退或多收的情況。
六、第三方框架問題
缺陷描述：第三方框架不熟悉或自身問題，導致安全或性能或其他問題
建議：普遍性問題，這個盡量保證用新版本的第三方框架，或在測試環境多測試后再上線，隨時關注第三方框架的官方網站
七、瀏覽器后退問題
缺陷描述：該問題單獨作為一類，是因為WEB系統非常典型的問題，瀏覽器后退導致訂單可以再次退款，再次新增..數據之類的問題
建議：兩個層面導致的問題，第一個是前台頁面緩存，第二個是后台沒有對重復數據做判斷。解決思路：
1、對重要操作的頁面設置禁止客戶端緩存，這樣瀏覽器不能后退或后退的頁面已過期。
2、即使瀏覽器可后退，或通過請求回放手工制造請求等惡意重復提交，后台也應該判斷，尤其是修改某操作，比如訂單退款，導致一個訂單退款多次；新增操作根據實際情況做判斷，比如新增訂單再后台再新增訂單。后台對任何請求不管是重復提交還是新提交，都應該校驗是否可以執行該操作。
八、服務端並發驗證問題
缺陷描述：並發問題是任何系統需要考慮的問題，也是可能導致系統存在邏輯錯誤的地方
建議：重要業務修改，需要保證業務邏輯層面的事務，如果涉及多台后端應用服務器就更復雜了。比如單機用鎖代碼塊能保證單機不出問題，但隨機多機請求又可能出現問題，比如惡意用戶用一個聯通網絡和電信網絡同時對一個訂單退款，如果單機鎖代碼塊，可能導致聯通網絡請求A服務器，電信網絡請求B服務器，A,B都成功導致退款2次。除了單機鎖解決，可解決的思路：
1、重要修改業務，並行操作依賴一個單獨的服務器或服務，該服務判斷是否有第一次操作並加標記，另外一個請求再通過該服務器或服務判斷是否可以繼續操作，因此鎖操作只需要在該服務器或服務嚴格判斷鎖即可，不會導致並發問題。但成本相對較高。
2、如果業務都是操作同一個數據庫，那對數據庫表增加一個狀態字段，比如正在修改狀態，多個事務同時請求，第一個請求修改該字段並where該字段為前一個狀態字段，第二個請求修改該字段同樣執行該sql。但第二個sql修改返回條數為0，因為被第一個sql修改成功了，where前一個狀態不成立，所以范圍影響行數為0。因此第二個事務請求就可以返回：有其他請求正在修改該訂單，不能同時修改。這個解決思路成本較低。
上面主要說修改業務，如果新增業務，那多並發可以不很細致處理，因為可以把它當成不同時間段的多次請求新增數據，根據業務需求再做處理。
九、臨界判斷問題
缺陷描述：如果字符串split或indexof或判斷數組長度等，經常導致遺漏最后一個或第一個數據
建議：首先字符串或數據集合第一個或最后一個數據需要先清理數據，比如1,2,3，最后一個,需要清理，清理完數據后再處理。處理數據也需要注意比如Length,size()的大小和數組對象從0開始計算的關系等問題。
十、對象批量update問題
缺陷描述：這個問題是后台代碼的問題，有時候表數據太大，為了省事，直接update（表），但表里實際有的是敏感信息，比如密碼，手機號，身份證等，這些數據之前是做了特殊處理的，比如有*號等，批量更新后可能導致字段被空字符串替換，或覆蓋為明文了。
建議：盡量不批量update對象，update什么字段修改什么
十一、業務理解和處理問題
缺陷描述：由於對業務理解或溝通不清楚導致前段展現或業務邏輯不准確的問題
建議：重要業務邏輯需要多溝通確認，上線前多測試復雜業務邏輯。對業務邏輯不確定的地方，要用白名單，比如在什么情況才怎么處理，而不是黑名單或沒有名單，直接就處理了
十二、JS兼容問題
缺陷描述：JS兼容問題是WEB開發最常遇到的問題
建議：根據業務要求是否兼容什么瀏覽器，上線前針對瀏覽器做測試，或比如現在阿里有瀏覽器兼容性自動化測試工具，可以業務測試完成后自動化測試JS和CSS兼容性問題。
十三、浮點數計算問題
缺陷描述：后台代碼計算數據最經常遇到的問題
建議：浮點數計算數據會有精度問題，JAVA里float，double計算改為bigdecimal計算
十四、數據庫不規整數據導致前台異常
缺陷描述：尤其在測試環境或老項目里，數據庫里有字段不規整，導致前台異常或展現錯誤
建議：保證數據插入時數據就是按照要求放入數據庫，數據展現也有容錯機制，如果數據字段不正確就用默認數據或留空，保證頁面能正常請求和返回
十五、內存緩存對象設計問題
缺陷描述：做系統經常會用內存緩存數據，內存緩存什么對象可能影響后續的業務邏輯
建議：頁面緩存數據應該盡量精細，比系統為了限制同一個用戶同時退款，可能在內存緩存了這個用戶是否在退款和以及退款金額，但內存沒有記錄這個用戶的什么訂單在退款，導致其他訂單這個期間也不能退款了。
內存緩存對象也需要建模，讓內存對象字段盡量細化，保證滿足各種應用場景。
上面15個是我根據2015年部門測試團隊BUG情況，整理的一些通性和業務無關的缺陷描述和建議，肯定不全，而且這些問題的建議也可能不准確，僅限參考，如轉載，請注明來自：http://lawson.cnblogs.com。