最近部门整理了今年所有项目测试团队提出的BUG，筛选了几十个作为常规通用的缺陷，我根据这些缺陷内容，去掉和业务相关的知识，整理出了一份缺陷描述和解决方案。

  其实WEB系统中常规的缺陷分类后也就那么多，但汇总过程，有同事建议分类写得更通用点，但我想了下，写了后大家可能更看不懂，本来常犯的错误也就这么多，分类比如按照安全问题，性能问题，并发问题，可能描述更专业，但开发、测试团队的人看到可能太官方和自己无关，自己也不会引起重视了。所以我的分类和问题描述可能更口水话一点，但应该能让每个人都很快看得懂。

  下面写下我整理的一部分，重要程度和犯错频率不分先后顺序：

  一、不相信客户端的数据

  缺陷描述：前台恶意伪造数据或页面的某些值未加载完成，用户发起一个请求但用了加载中的值，或请求的值本身就是恶意伪造的，导致后台抛出详细异常或导致sql注入，XSS等。

  建议：不管前台数据是恶意伪造还是由于网速慢页面值未加载完成，但用户用该不“常规”数据请求，后台都应该一一校验，比如JS前段验证只是为了一定程度减少后后请求压力，后台代码应该再次校验客户端的任何数据，SQL参数应该参数化等。

  二、页面未设置友好错误

  缺陷描述：页面由于未对500,404等HTTP错误设置友好页面，导致前台抛出了细节的错误情况

  建议：配置500,404等HTTP错误友好页面

  三、ajax加载完成前后对页面事件的控制

  缺陷描述：ajax请求前后对页面的其他新请求未进行限制，导致前一个ajax未处理完成，后续又在执行依赖前一个ajax返回数据的请求

  建议：如果前台页面存在依赖关系的新请求（包括ajax），应在新请求时判断前一个请求是否完成，如果未完成，则等待或提示。

  一个重要的ajax请求前应该设置某些按钮不可用，ajax请求完成后再把按钮设置为可用。这样该重要ajax请求完毕后才能点击其他操作

  四、后台平行、垂直权限验证

  缺陷描述：后台未对该请求判断该用户是否有权限操作本请求的数据js禁止页面后退，而只是判断了是否有权限操作这个链接或根本没有判断是否有权限操作该链接，该问题常会导致查看所有人订单或查看管理员数据

  建议：权限控制除了控制当前用户权限是否有权限操作本请求地址，还需要判断是否有权限操作这条数据

  五、一笔订单多次退款四舍五入问题

  缺陷描述：单独作为一项，原因是支付退款是非常重要的环节。任何涉及支付退款的都可能有该问题。一个订单分多次退款，由于四舍五入的问题，会导致全部退款加起来会大于支付价格，比如大于0.01元

  比如99.5元的订单，四舍五入精确到分，第一次退款33.17元，第二次退款33.17元，第三次退款33.17元，总退款：99.51元。

  建议：我认为有两种解决方案：

  1、支付按照四舍五入取大计算，退款按照取小计算，比如0.009元也算0.00元。这样不管分多少次退款，极端情况下，可能全部退完了，还会剩余0.02元更多点，适合极端情况一个订单分多次把所有费用退完，但供应商或平台最后可能还赚几分钱。但这个和业务有关系，需要确认。

  2、退款每次按照四舍五入退款，但如果一个订单最后一笔退款则不再按照四舍五入退款，而是把支付金额减去已完成的所有退款金额，剩余的钱作为最后一次全部退，这样保证用户和供应商或平台都不会多退或多收的情况。

  六、第三方框架问题

  缺陷描述：第三方框架不熟悉或自身问题，导致安全或性能或其他问题

  建议：普遍性问题，这个尽量保证用新版本的第三方框架，或在测试环境多测试后再上线，随时关注第三方框架的官方网站

  七、浏览器后退问题

  缺陷描述：该问题单独作为一类，是因为WEB系统非常典型的问题，浏览器后退导致订单可以再次退款，再次新增..数据之类的问题

  建议：两个层面导致的问题，第一个是前台页面缓存，第二个是后台没有对重复数据做判断。解决思路：

  1、对重要操作的页面设置禁止客户端缓存，这样浏览器不能后退或后退的页面已过期。

  2、即使浏览器可后退，或通过请求回放手工制造请求等恶意重复提交，后台也应该判断，尤其是修改某操作，比如订单退款js禁止页面后退，导致一个订单退款多次；新增操作根据实际情况做判断，比如新增订单再后台再新增订单。后台对任何请求不管是重复提交还是新提交，都应该校验是否可以执行该操作。

  八、服务端并发验证问题

  缺陷描述：并发问题是任何系统需要考虑的问题，也是可能导致系统存在逻辑错误的地方

  建议：重要业务修改，需要保证业务逻辑层面的事务，如果涉及多台后端应用服务器就更复杂了。比如单机用锁代码块能保证单机不出问题，但随机多机请求又可能出现问题，比如恶意用户用一个联通网络和电信网络同时对一个订单退款，如果单机锁代码块，可能导致联通网络请求A服务器，电信网络请求B服务器，A,B都成功导致退款2次。除了单机锁解决，可解决的思路：

  1、重要修改业务，并行操作依赖一个单独的服务器或服务，该服务判断是否有第一次操作并加标记，另外一个请求再通过该服务器或服务判断是否可以继续操作，因此锁操作只需要在该服务器或服务严格判断锁即可，不会导致并发问题。但成本相对较高。

  2、如果业务都是操作同一个数据库，那对数据库表增加一个状态字段，比如正在修改状态，多个事务同时请求，第一个请求修改该字段并where该字段为前一个状态字段，第二个请求修改该字段同样执行该sql。但第二个sql修改返回条数为0，因为被第一个sql修改成功了，where前一个状态不成立，所以范围影响行数为0。因此第二个事务请求就可以返回：有其他请求正在修改该订单，不能同时修改。这个解决思路成本较低。

  上面主要说修改业务，如果新增业务，那多并发可以不很细致处理，因为可以把它当成不同时间段的多次请求新增数据，根据业务需求再做处理。

  ......