最近部门整理了今年所有项目测试团队提出的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。