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。