B/S系統常見缺陷整理和解決方案

最近部門整理了今年全部項目測試團隊提出的BUG，篩選了幾十個做爲常規通用的缺陷，我根據這些缺陷內容，去掉和業務相關的知識，整理出了一份缺陷描述和解決方案。

其實WEB系統中常規的缺陷分類後也就那麼多，但彙總過程，有同事建議分類寫得更通用點，但我想了下，寫了後你們可能更看不懂，原本常犯的錯誤也就這麼多，分類好比按照安全問題，性能問題，併發問題，可能描述更專業，但開發、測試團隊的人看到可能太官方和本身無關，本身也不會引發重視了。因此個人分類和問題描述可能更口水話一點，但應該能讓每一個人都很快看得懂。

下面寫下我整理的一部分，重要程度和犯錯頻率不分前後順序：

1、不相信客戶端的數據

缺陷描述：前臺惡意僞造數據或頁面的某些值未加載完成，用戶發起一個請求但用了加載中的值，或請求的值自己就是惡意僞造的，致使後臺拋出詳細異常或致使sql注入，XSS等。

建議：無論前臺數據是惡意僞造仍是因爲網速慢頁面值未加載完成，但用戶用該不「常規」數據請求，後臺都應該一一校驗，好比JS前段驗證只是爲了必定程度減小後後請求壓力，後臺代碼應該再次校驗客戶端的任何數據，SQL參數應該參數化等。

2、頁面未設置友好錯誤

缺陷描述：頁面因爲未對500,404等HTTP錯誤設置友好頁面，致使前臺拋出了細節的錯誤狀況

建議：配置500,404等HTTP錯誤友好頁面

3、ajax加載完成先後對頁面事件的控制

缺陷描述：ajax請求先後對頁面的其餘新請求未進行限制，致使前一個ajax未處理完成，後續又在執行依賴前一個ajax返回數據的請求

建議：若是前臺頁面存在依賴關係的新請求（包括ajax），應在新請求時判斷前一個請求是否完成，若是未完成，則等待或提示。

一個重要的ajax請求前應該設置某些按鈕不可用，ajax請求完成後再把按鈕設置爲可用。這樣該重要ajax請求完畢後才能點擊其餘操做

4、後臺平行、垂直權限驗證

缺陷描述：後臺未對該請求判斷該用戶是否有權限操做本請求的數據，而只是判斷了是否有權限操做這個連接或根本沒有判斷是否有權限操做該連接，該問題常會致使查看全部人訂單或查看管理員數據

建議：權限控制除了控制當前用戶權限是否有權限操做本請求地址，還須要判斷是否有權限操做這條數據

5、一筆訂單屢次退款四捨五入問題

缺陷描述：單獨做爲一項，緣由是支付退款是很是重要的環節。任何涉及支付退款的均可能有該問題。一個訂單分屢次退款，因爲四捨五入的問題，會致使所有退款加起來會大於支付價格，好比大於0.01元

好比99.5元的訂單，四捨五入精確到分，第一次退款33.17元，第二次退款33.17元，第三次退款33.17元，總退款：99.51元。

建議：我認爲有兩種解決方案：

一、支付按照四捨五入取大計算，退款按照取小計算，好比0.009元也算0.00元。這樣無論分多少次退款，極端狀況下，可能所有退完了，還會剩餘0.02元更多點，適合極端狀況一個訂單分屢次把全部費用退完，但供應商或平臺最後可能還賺幾分錢。但這個和業務有關係，須要確認。
二、退款每次按照四捨五入退款，但若是一個訂單最後一筆退款則再也不按照四捨五入退款，而是把支付金額減去已完成的全部退款金額，剩餘的錢做爲最後一次所有退，這樣保證用戶和供應商或平臺都不會多退或多收的狀況。

6、第三方框架問題

缺陷描述：第三方框架不熟悉或自身問題，致使安全或性能或其餘問題

建議：廣泛性問題，這個儘可能保證用新版本的第三方框架，或在測試環境多測試後再上線，隨時關注第三方框架的官方網站

7、瀏覽器後退問題

缺陷描述：該問題單獨做爲一類，是由於WEB系統很是典型的問題，瀏覽器後退致使訂單能夠再次退款，再次新增..數據之類的問題

建議：兩個層面致使的問題，第一個是前臺頁面緩存，第二個是後臺沒有對重複數據作判斷。解決思路：
一、對重要操做的頁面設置禁止客戶端緩存，這樣瀏覽器不能後退或後退的頁面已過時。
二、即便瀏覽器可後退，或經過請求回放手工製造請求等惡意重複提交，後臺也應該判斷，尤爲是修改某操做，好比訂單退款，致使一個訂單退款屢次；新增操做根據實際狀況作判斷，好比新增訂單再後臺再新增訂單。後臺對任何請求無論是重複提交仍是新提交，都應該校驗是否能夠執行該操做。

8、服務端併發驗證問題

缺陷描述：併發問題是任何系統須要考慮的問題，也是可能致使系統存在邏輯錯誤的地方

建議：重要業務修改，須要保證業務邏輯層面的事務，若是涉及多臺後端應用服務器就更復雜了。好比單機用鎖代碼塊能保證單機不出問題，但隨機多機請求又可能出現問題，好比惡意用戶用一個聯通網絡和電信網絡同時對一個訂單退款，若是單機鎖代碼塊，可能致使聯通網絡請求A服務器，電信網絡請求B服務器，A,B都成功緻使退款2次。除了單機鎖解決，可解決的思路：
一、重要修改業務，並行操做依賴一個單獨的服務器或服務，該服務判斷是否有第一次操做並加標記，另一個請求再經過該服務器或服務判斷是否能夠繼續操做，所以鎖操做只須要在該服務器或服務嚴格判斷鎖便可，不會致使併發問題。但成本相對較高。
二、若是業務都是操做同一個數據庫，那對數據庫表增長一個狀態字段，好比正在修改狀態，多個事務同時請求，第一個請求修改該字段並where該字段爲前一個狀態字段，第二個請求修改該字段一樣執行該sql。但第二個sql修改返回條數爲0，由於被第一個sql修改爲功了，where前一個狀態不成立，因此範圍影響行數爲0。所以第二個事務請求就能夠返回：有其餘請求正在修改該訂單，不能同時修改。這個解決思路成本較低。
上面主要說修改業務，若是新增業務，那多併發能夠不很細緻處理，由於能夠把它當成不一樣時間段的屢次請求新增數據，根據業務需求再作處理。

9、臨界判斷問題

缺陷描述：若是字符串split或indexof或判斷數組長度等，常常致使遺漏最後一個或第一個數據

建議：首先字符串或數據集合第一個或最後一個數據須要先清理數據，好比1,2,3，最後一個,須要清理，清理完數據後再處理。處理數據也須要注意好比Length,size()的大小和數組對象從0開始計算的關係等問題。

10、對象批量update問題

缺陷描述：這個問題是後臺代碼的問題，有時候表數據太大，爲了省事，直接update（表），但表裏實際有的是敏感信息，好比密碼，手機號，身份證等，這些數據以前是作了特殊處理的，好比有*號等，批量更新後可能致使字段被空字符串替換，或覆蓋爲明文了。

建議：儘可能不批量update對象，update什麼字段修改什麼

11、業務理解和處理問題

缺陷描述：因爲對業務理解或溝通不清楚致使前段展示或業務邏輯不許確的問題

建議：重要業務邏輯須要多溝通確認，上線前多測試複雜業務邏輯。對業務邏輯不肯定的地方，要用白名單，好比在什麼狀況才怎麼處理，而不是黑名單或沒有名單，直接就處理了

12、JS兼容問題

缺陷描述：JS兼容問題是WEB開發最常遇到的問題

建議：根據業務要求是否兼容什麼瀏覽器，上線前針對瀏覽器作測試，或好比如今阿里有瀏覽器兼容性自動化測試工具，能夠業務測試完成後自動化測試JS和CSS兼容性問題。

十3、浮點數計算問題

缺陷描述：後臺代碼計算數據最常常遇到的問題

建議：浮點數計算數據會有精度問題，JAVA裏float，double計算改成bigdecimal計算

十4、數據庫不規整數據致使前臺異常

缺陷描述：尤爲在測試環境或老項目裏，數據庫裏有字段不規整，致使前臺異常或展示錯誤

建議：保證數據插入時數據就是按照要求放入數據庫，數據展示也有容錯機制，若是數據字段不正確就用默認數據或留空，保證頁面能正常請求和返回

十5、內存緩存對象設計問題

缺陷描述：作系統常常會用內存緩存數據，內存緩存什麼對象可能影響後續的業務邏輯

建議：頁面緩存數據應該儘可能精細，比系統爲了限制同一個用戶同時退款，可能在內存緩存了這個用戶是否在退款和以及退款金額，但內存沒有記錄這個用戶的什麼訂單在退款，致使其餘訂單這個期間也不能退款了。
內存緩存對象也須要建模，讓內存對象字段儘可能細化，保證知足各類應用場景。

 

上面15個是我根據2015年部門測試團隊BUG狀況，整理的一些通性和業務無關的缺陷描述和建議，確定不全，並且這些問題的建議也可能不許確，僅限參考，如轉載，請註明來自：http://lawson.cnblogs.com。