项目测试中跟“钱”相关的各种坑

分类	经验	影响
交易	一笔交易支付时候的“单例”性，在一笔支付没有完成时，不能发起第二笔支付。 支付结果不仅要做主动轮循，建议同时做回调。	某东点击支付按钮时，快速连击，导致两笔支付产生。
退款	业务逻辑是否有漏洞，是否有攻击方法。	某东发生过促销活动时1张“满600减300”的稀缺优惠券通过退款循环多次使用。选择订单中金额最低的商品退货，会发现优惠券被退回。然后继续购买，再继续选择最便宜的商品退款......
关联方	在一个业务或者模块做修改后，有调用关系的关联模块要考虑是否受影响，模块之间的相互关系，业务之间的数据流转需要梳理清楚。	某东，在一个模块修改测试上线后，由于另一个关联的业务不知道此修改，导致2小时内损失8W元
日期查询	查询的时间的范围测试，查询结果是否符合查询条件，查询的条件，最近一天，一周，一月都是如何定义的。	查询一个月的记录时候，按照月份减一，日期不变或者加一的方式，在处理正常月份可能没有问题，在处理2月的时候就会有问题。
金额	金额的计算使用专用的数值计算包（API），使用编程语言自带的数值计算有可能会带来计算误差，从而造成损失。	某东支付平台，在跟农行的对接中产生了精度丢失，比如19.91，在提交给银行时，只有19.90，结果用户可以少支付1分钱，虽然很少，但在月度对账时发现已经造成6w的资损。原因大概是支付平台使用的是“分”为计算单位，银行系统以“元”为计算单位，单位转换时造成精度损失。
金额篡改	金额的计算应该由后端统一完成，避免前端数据被篡改而后端未做校验以及前后端浮点数处理不一致出现问题。	某东前期出现过订单金额被拦截修改成1分钱支付成功的漏洞。
浮点数	金额不要用浮点数，统一使用bigdecimal之类的方法。计算的精度和尾数处理在模块间、前后端上（四舍五入、去尾等）要统一。	活动，订单金额和某个优惠活动门槛（小数，如99.99）正好和相等时，两个浮点数比较大小会导致订单不能参加活动。 折扣，原价56.67*75% 可能导致精度问题或订单总金额对不上，差个一两分钱。 减免，6.8-0.9=5.8， 金额对不上，会引发用户的不满。